From owner-ipng@sunroof.eng.sun.com Wed Nov 1 01:59:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA19v0323652 for ipng-dist; Wed, 1 Nov 2000 01:57:00 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA19upj23645 for ; Wed, 1 Nov 2000 01:56:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA19403 for ; Wed, 1 Nov 2000 01:56:50 -0800 (PST) Received: from shaku.v6.linux.or.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA24070 for ; Wed, 1 Nov 2000 01:56:49 -0800 (PST) Received: from shaku.sfc.wide.ad.jp ([::1]) by shaku.v6.linux.or.jp (8.11.0/3.7W) with ESMTP id eA19tan27136 for ; Wed, 1 Nov 2000 18:55:36 +0900 Date: Wed, 01 Nov 2000 18:55:36 +0900 Message-ID: From: usagi-core To: ipng@sunroof.eng.sun.com Subject: [ANN] 1st release of USAGI IPv6 environment User-Agent: Wanderlust/1.1.1 (Purple Rain) EMIKO/1.13.12 (Euglena sociabilis) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) APEL/10.2 MULE XEmacs/21.1 (patch 9) (Canyonlands) (i686-pc-linux) Organization: USAGI Project Reply-To: usagi-core MIME-Version: 1.0 (generated by EMIKO 1.13.12 - "Euglena sociabilis") Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We are glad to announce the 1st release of USAGI Project. The "USAGI" means UniverSAl playGround for Ipv6. It is the IPv6 development project for Linux operating systems mainly. As many other operating systems and routers, the Linux kernel has its original IPv6 implementation. However, the development was done long time ago and the implementation is not up-to-dated. Many important features such as IPsec and NDP are missing or miss-implemented. Considering the situation, we have started USAGI Project with WIDE Project, KAME Project and TAHI Project in August 2000. The USAGI Project is managed by volunteers and aims to provide better IPv6 environment on Linux freely. We try to improve Linux kernel, IPv6 related libraries and IPv6 applications. Please visit http://www.linux-ipv6.org/ for further details. Today, November 1st, we are glad to announce 1st official release from USAGI Project. At the release, we include the following three packages. - Linux Kernel-2.4.0-test9-usagi-20001101a Based on Linux Kernel-2.4.0-test9, we have improved and implemented + better source address selection, + ICMPv6 Node Information Queries, + SNMP statistics per device, + IPv6 khttpd, + joining all-node multicast address on network devices and + many bug fixes. - glibc-2.1.3-usagi-20001101a Based on glibc-2.1.3, we have improved + supporting sin6_scope_id, + adding AI_ADDRCONFIG flag, + some RFC2292 functions, + adding getifaddrs API and + some bug fixes. - iputils-ss000418-usagi-20001101a Based on iputils-ss000418, we have improved + supporting sin6_scope_id, + ICMPv6 Node Information Queries and + supporting Autoconfigure. You can get above source codes from the following URL. ftp://ftp.linux-ipv6.org/pub/usagi/stable/patch/ USAGI Project will release snapshot codes on each two weeks and after implementing some features, we will release stable codes. We will announce latest information regarding releasing codes via web page. Please check our web site. We also provide the binary packages for some distributions. Some of the binary packages have diffrent code version with original USAGI code because of packaging policy. You can get the packages from following sites. Debian GNU/Linux 2.2 (potato) ftp://ftp.linux-ipv6.org/pub/usagi/stable/package/debian/ Kondara MNU/Linux (Jirai) ftp://ftp.linux-ipv6.org/pub/usagi/stable/package/kondara/ RedHat Linux 7.0 ftp://ftp.linux-ipv6.org/pub/usagi/stable/package/redhat/ TurboLinux 6.0 (or later) (for Japanese version) ftp://ftp.linux-ipv6.org/pub/usagi/stable/package/turbo/ By the way, we manage the mailing list for USAGI users. If you have questions or advices, please join the mailing list. For more ditails, please see http://www.linux-ipv6.org/ml/ . Thanks. Related Web sites. WIDE Project http://www.wide.ad.jp/ KAME Project http://www.kame.net/ TAHI Project http://www.tahi.org/ -- USAGI Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 2 08:39:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA2GcGM25191 for ipng-dist; Thu, 2 Nov 2000 08:38:16 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA2Gc4j25184; Thu, 2 Nov 2000 08:38:04 -0800 (PST) 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,v1.7) with ESMTP id IAA14147; Thu, 2 Nov 2000 08:38:04 -0800 (PST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24557; Thu, 2 Nov 2000 08:38:02 -0800 (PST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id LAA03556; Thu, 2 Nov 2000 11:37:26 -0500 (EST) Message-Id: <200011021637.LAA03556@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Simon Leinen cc: Brad Huntting , "f.johan.beisser" , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, cmj@3Com.com Subject: Re: (ngtrans) An IPv4 anycast address for 6to4<->6bone gateways In-reply-to: Your message of "02 Nov 2000 11:02:27 +0100." Date: Thu, 02 Nov 2000 11:37:26 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Each new anycast address means additional routing entries in the > default-free zone. Personally I'm not sure whether the ability to > have a standard IPv4 address for the 6to4/6bone gateways is enough to > justify this (the current Web page is a good alternative). I don't think that the cost of a single extra entry in the routing table is so great, especially since it could do a lot to make IPv6 deployment easier. And as compared to the web page, the anycast approach has the advantages that it requires little or no manual configuration (it can be the default) and that it can automatically adapt to changing network conditions. 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 Nov 2 12:12:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA2KAdY25487 for ipng-dist; Thu, 2 Nov 2000 12:10:39 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA2KAZj25480 for ; Thu, 2 Nov 2000 12:10:35 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id eA2K9nK27047 for ipng@sunroof.eng.sun.com; Thu, 2 Nov 2000 12:09:49 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA2A6rj24906; Thu, 2 Nov 2000 02:06:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA25134; Thu, 2 Nov 2000 02:06:52 -0800 (PST) Received: from babar.switch.ch (babar.switch.ch [130.59.4.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA14411; Thu, 2 Nov 2000 02:06:51 -0800 (PST) Received: (from leinen@localhost) by babar.switch.ch (8.9.3+Sun/8.9.3) id LAA26326; Thu, 2 Nov 2000 11:02:28 +0100 (MET) X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: Brad Huntting Cc: "f.johan.beisser" , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, cmj@3Com.com Subject: Re: (ngtrans) An IPv4 anycast address for 6to4<->6bone gateways References: <200010272146.PAA17119@hunkular.glarp.com> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: Brad Huntting's message of "Fri, 27 Oct 2000 15:46:25 -0600" Date: 02 Nov 2000 11:02:27 +0100 Message-ID: Lines: 26 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "bh" == Brad Huntting writes: > 6to4 gateways would advertise to the their IPv4 peers that they have > a route for "a.b.c.d". And for their IPv6 peers (the 6bone) they > can advertise a route for 2002::/16. > Does anyone see a problem with this? I dont suppose there's already > a block of IPv4 address space set aside for anycast? I think nobody has really been using IPv4 anycast on a global (inter-provider) scale. The IETF dnsop working group is conducting an experiment on global anycast, with the possible application of name servers for important zones such as the root, see draft-ietf-dnsop-ohta-shared-root-server-00.txt (http://www.switch.ch/lan/dns/references.html#aroot for a pointer). Each new anycast address means additional routing entries in the default-free zone. Personally I'm not sure whether the ability to have a standard IPv4 address for the 6to4/6bone gateways is enough to justify this (the current Web page is a good alternative). One might be tempted by the idea that making global IPv4 routing more difficult would be a good thing to promote the deployment of IPv6, but this could also backfire. Regards, -- Simon. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 2 15:02:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA2N16j25718 for ipng-dist; Thu, 2 Nov 2000 15:01:06 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA2N0vj25711 for ; Thu, 2 Nov 2000 15:00:58 -0800 (PST) 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,v1.7) with ESMTP id PAA08227 for ; Thu, 2 Nov 2000 15:00:58 -0800 (PST) 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 QAA27980 for ; Thu, 2 Nov 2000 16:00:57 -0700 (MST) 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 PAA05899; Thu, 2 Nov 2000 15:00:55 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eA2N0sY10075; Thu, 2 Nov 2000 15:00:54 -0800 X-Virus-Scanned: Thu, 2 Nov 2000 15:00:54 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpd4pYNxg; Thu, 02 Nov 2000 15:00:39 PST Message-Id: <4.3.2.7.2.20001102145718.020a3558@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Nov 2000 14:58:59 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Request for Agenda Items for San Diego IPng Sessions Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We have requested two meeting sessions and are starting to work on the agenda for the San Diego IETF meeting. Please send us requests for agenda items. Thanks, Bob Hinden / Steve Deering IPng 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 Fri Nov 3 17:07:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA415v127015 for ipng-dist; Fri, 3 Nov 2000 17:05:57 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA415mj27008 for ; Fri, 3 Nov 2000 17:05:48 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA04233 for ; Fri, 3 Nov 2000 17:05:48 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06853 for ; Fri, 3 Nov 2000 17:05:48 -0800 (PST) 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 RAA21251; Fri, 3 Nov 2000 17:05:48 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eA415kn12812; Fri, 3 Nov 2000 17:05:46 -0800 X-Virus-Scanned: Fri, 3 Nov 2000 17:05:46 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdBuShuY; Fri, 03 Nov 2000 17:05:41 PST Message-ID: <3A036088.DE8D294D@iprg.nokia.com> Date: Fri, 03 Nov 2000 17:04:08 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP Mailing List , IPng Working Group Subject: How Mobile IPv6 should handle home network renumbering Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello everyone, I'm forwarding to these lists some text supplied by Ken Powell for updating relevant sections of the Mobile IPv6 draft. I find that Ken's proposed modifications are quite reasonable and answer many outstanding open issues. In subsequent messages, I will elaborate on some details about _when_ a home agent should send new prefix information to the mobile node. However, I thought it would be easiest to reproduce Ken's original message in its entirety, so as not to disrupt a very coherent presentation. Regards, Charlie P. PS. It's taken me a week to study the material in Ken's message, as well as related messages from other people. Sorry for the additional delay. -------- Original Message -------- Date: Fri, 3 Nov 2000 13:05:40 -0800 (PST) From: Charles Perkins To: charliep@iprg.nokia.com From: Powell, Ken Sent: Friday, October 27, 2000 5:05 PM To: 'charliep@iprq.nokia.com' Cc: 'dbj@cs.cmu.edu'; Bound, Jim Subject: Mobile IPv6 contributions Hi Charlie, A few weeks ago you asked if I could provide any text for the Mobile IPv6 Spec regarding the issues we discussed. I apologize for the delay, but hope the following may still be relevant to your planned changes. The areas covered are: 1) How the home agent constructs an aggregate list of prefixes advertised by other routers on the home network. 2) What triggers a home agent to send router advertisements to a mobile node, and what prefixes should be included in each advertisement. I primarily added aggregate list references and periodic transmission of all prefixes to the existing text. I believe you also mentioned using binding updates as a mechanism to rate- limit Router Advertisements, so I added that too. 3) When and how to send a router solicitation from a mobile node to the home agent. 4) How to receive a router solicitation from a mobile node to the home agent. One other thought, my text uses a new configuration variable to control the timing of periodic router advertisements to mobile nodes called MobileRtrAdvInterval. Such a variable could reasonably default to a relatively long period of time, like an hour or more, but otherwise work much like MaxRtrAdvInterval in the ND spec. I wasn't sure how to introduce this. I hope this text is helpful. Feel free to use, rewrite, cut, as it makes sense. You're also welcome to forward this off to the ipng or mobilip mailing lists if you like. Let me know if you have any questions/concerns. Ken Item 1 (perhaps add into section 9.7) ===================================== A mobile node on a remote network should autoconfigure the same set of home addresses it would autoconfigure if it were attached to the home network. To support this, the home agent monitors prefixes advertised by other routers on the home subnet and passes the aggregate list of home subnet prefixes on to the mobile node in Router Advertisements. The home agent SHOULD construct the aggregate list of home subnet prefixes as follows: o Copy prefix information defined in the home agent's AdvPrefixList on the home subnet's interfaces to the aggregate list. Also apply any changes made to the AdvPrefixList on the home agent to the aggregate list. o Check valid prefixes received in Router Advertisements from the home network for consistency with the home agent's AdvPrefixList per section 6.2.7 of RFC 2461 (ND). Do not update the aggregate list with any information from received prefixes that fail this check. o Add valid prefixes received in Router Advertisements from the home network that are not yet in the aggregate list to the aggregate list along with the value of their L and A flags. Clear the R flag and zero the interface id portion of the prefix field to prevent mobile nodes from treating another router's interface address as belonging to the home agent. Treat the lifetimes of these prefixes as "deprecating". o Do not perform consistency checks on valid prefixes received in Router Advertisements on the home network that do not exist in the home agent's AdvPrefixList. Instead, if the prefixes already exist in the aggregate list, update the prefix lifetime fields in the aggregate list according to the rules specified for hosts in section 6.3.4 of RFC 2461 (ND) and section 5.5.3 of RFC 2462 (stateless adderconf). o If the L or A flag is set on valid prefixes received in a Router Advertisement, and that prefix already exists in the aggregate list, set the corresponding flag in the aggregate list. Ignore the received L or A flag if it is clear. o Ignore the R flag and interface id portion of any prefix received in a Router Advertisement. o Delete prefixes from the aggregate list when their valid lifetimes expire. (***Did the group agree to keep advertising these prefixes for a period of time with a zero lifetime? **) Item 2 (perhaps replace similar text in section 9.7) ==================================================== A home agent serving a mobile node SHOULD construct and tunnel to the mobile node a new Router Advertisement when any of the following conditions occur: o A valid or preferred lifetime of a prefix in the aggregate list of prefixes is suddenly reduced to less than HomeRtrAdvInterval. o The state of the flags for a prefix in the aggregate list changes. o A new prefix is created in the aggregate list. The home agent constructs a new Router Advertisement message containing no options other than the Prefix Information options describing the prefixes for which one of the conditions above has occurred since the last Router Advertisement tunneled to and acknowledged by the mobile node. In addition, the home agent MUST send a router advertisement with all prefixes in the aggregate list to the mobile node at least once per HomeRtrAdvInterval and upon receipt of a valid Router Solicitation from the mobile node. The home agent MAY (SHOULD?) rate limit the frequency at which it sends Router Advertisements to the mobile node by delaying transmission until receipt of a Binding Update option from the mobile node. When multiple conditions occur at or near the same time, the home agent SHOULD attempt to combine them into a single Router Advertisement message to the mobile node. Item 3 ====== 10.x Sending Router Solicitations to a Home Agent A mobile node that uses stateless address auto configuration on its home subnet could miss significant home subnet configuration changes while disconnected. Such a mobile node MAY request updated prefix information when it detects a possibility that its current home subnet address information is inaccurate by sending a Router Solicitation to the home agent. The mobile node must construct such a Router Solicitation packet as follows: - The Source Address in the packet's IPv6 header MUST be set to the mobile node's primary care-of address. - The packet MUST be protected by IPsec [13, 11, 12] to guard against malicious Router Solicitations. The IPsec protection MUST provide sender authentication, data integrity protection, and replay protection, covering the Router Solicitation. - The packet MUST include a Home Address destination option, giving the mobile node's home address for its current binding. - The packet MUST include a Binding Update destination option as described in section 10.6 if a current binding does not yet exist. Otherwise, it MAY include a Binding Update destination option. - The Router Solicitation's source link-layer address option MUST be omitted. Item 4 ====== 6.x Receiving Router Solicitations from Mobile Nodes Section xx describes how a mobile node on a remote network may send a Router Solicitation to a home agent to request all current address prefix information on the home subnet. The Router Solicitation may include a Binding Update destination option. The processing requirements described here for the Router Solicitation assume the Binding Update destination option was processed first. The home agent MAY return a single packet containing both the resulting Binding Acknowledgment destination option and a Router Advertisement. When a home agent receives a Router Solicitation from a mobile node on a remote network, it MUST validate it according to the following tests: - A home registration binding cache entry exists for the mobile node. - The Source Address of the IP packet carrying the Router Solicitation is the same as the primary care-of address for the mobile node. - The Home Address destination option contains the same address as the home address specified in the binding cache entry for the mobile node. - The packet is protected by IPsec [13, 11, 12] to guard against malicious Router Advertisements. The IPsec protection provides sender authentication, data integrity protection, and replay protection, covering the Router Advertisement. Any received tunneled Router Solicitation not meeting all of these tests MUST be silently discarded. If a received tunneled Router Solicitation is not discarded according to the tests listed above, the home agent MUST generate and tunnel to the mobile node as described in section 6.7 a set of Router Advertisement(s) which combined contain all entries in the aggregate list of prefixes for the mobile node's home network. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 5 07:17:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA5FFhF27822 for ipng-dist; Sun, 5 Nov 2000 07:15:43 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA5FFTj27815 for ; Sun, 5 Nov 2000 07:15:30 -0800 (PST) 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,v1.7) with ESMTP id HAA07238; Sun, 5 Nov 2000 07:15:28 -0800 (PST) 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 HAA13178; Sun, 5 Nov 2000 07:15:23 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id AAA08535; Mon, 6 Nov 2000 00:00:53 +0900 (JST) Date: Mon, 06 Nov 2000 00:15:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: erik.nordmark@eng.sun.com Cc: matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: [advanced API] possible infinite loop in cmsg data examination User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 48 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm not sure if this list is the right place, but I have a tiny comment about the defintion and the typical usage of CMSG_NXTHDR(). draft-ietf-ipngwg-2292bis-01.txt describes CMSG_NXTHDR with the following definition and the example: while ((cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) != NULL) { if (cmsgptr->cmsg_level == ... && cmsgptr->cmsg_type == ... ) { u_char *ptr; ptr = CMSG_DATA(cmsgptr); /* process data pointed to by ptr */ } } where #define CMSG_NXTHDR(mhdr, cmsg) \ (((cmsg) == NULL) ? CMSG_FIRSTHDR(mhdr) : \ (((u_char *)(cmsg) + ALIGN_H((cmsg)->cmsg_len) \ + ALIGN_D(sizeof(struct cmsghdr)) > \ (u_char *)((mhdr)->msg_control) + (mhdr)->msg_controllen) ? \ (struct cmsghdr *)NULL : \ (struct cmsghdr *)((u_char *)(cmsg) + ALIGN_H((cmsg)->cmsg_len)))) I think this combination is a bit dangerous, since the while loop will not stop if the cmsg_len member of a cmsg data is 0. In fact, a BSD derived system has this type of while loop in its kernel with the (logically) same definition of CMSG_NXTHDR. As a result, a user program can make the kernel hang by sending forged ancillary data. So, I'd suggest to add some warning in the example about the possibility of the infinite loop or to rewrite the example itself like this: while ((cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) != NULL) { if (cmsgptr->cmsg_len == 0) break; /* and return some error if necessary */ if (cmsgptr->cmsg_level == ... && cmsgptr->cmsg_type == ... ) { u_char *ptr; ptr = CMSG_DATA(cmsgptr); /* process data pointed to by ptr */ } } 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 Sun Nov 5 07:41:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA5Fds127849 for ipng-dist; Sun, 5 Nov 2000 07:39:54 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA5Fdjj27842 for ; Sun, 5 Nov 2000 07:39:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA02017; Sun, 5 Nov 2000 07:39:44 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18041; Sun, 5 Nov 2000 07:39:43 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id AAA08604; Mon, 6 Nov 2000 00:25:20 +0900 (JST) Date: Mon, 06 Nov 2000 00:39:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: erik.nordmark@eng.sun.com Cc: matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: [advanced API] how to get the destination address for IPV6_RECVPATHMTU User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I need a clarification about the IPV6_PATHMTU ancillary data item defined in draft-ietf-ipngwg-rfc2292bis-01.txt. The draft does not (explicitly) mention how the application knows the corresponding destination address for the returned MTU value. Which is correct? 1. this option has its meaning for a connected socket only. The destination is the foreign address of the socket. 2. the destination address should be specified in the msg_name member returned by the corresponding recvmsg() call. 3. the current spec is buggy. The ancillary data should contain the socket address structure for the destination. 4. others In any case, I think some text about this point should be added in the next revision of the spec. Thanks, 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 Sun Nov 5 12:00:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA5JxG327935 for ipng-dist; Sun, 5 Nov 2000 11:59:16 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA5Jx6j27928 for ; Sun, 5 Nov 2000 11:59:07 -0800 (PST) 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,v1.7) with ESMTP id LAA14073; Sun, 5 Nov 2000 11:59:05 -0800 (PST) Received: from host.ott.igs.net (host.ott.igs.net [216.58.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16815; Sun, 5 Nov 2000 11:59:05 -0800 (PST) Received: from [216.58.7.62] (ttyK30.ott.igs.net [216.58.7.62]) by host.ott.igs.net (8.9.3/8.9.2) with ESMTP id OAA89914; Sun, 5 Nov 2000 14:58:46 -0500 (EST) (envelope-from kgk@igs.net) Mime-Version: 1.0 X-Sender: kgk@host.igs.net Message-Id: In-Reply-To: <4.3.2.7.2.20001006135159.02426b38@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20001006135159.02426b38@mailhost.iprg.nokia.com> Date: Sun, 5 Nov 2000 15:05:12 -0500 To: Bob Hinden , Erik.Nordmark@eng.sun.com, narten@raleigh.ibm.com From: Keith Knightson Subject: Re: Request to Advance "IP Version 6 Addressing Architecture" Cc: scoya@ietf.org, deering@cisco.com, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Gentlemen, I notice that many of previously assigned values for other address schemes have been removed and replaced by "unassigned". I am not sure I fully understand the distinction between reserved and unassigned. It would seem to me that in neither case is it safe to use one of the values for any purpose whatsoever, since a reserved value might subsequently become unreserved, and an unassigned value might subsequently become assigned. In either case, any intermediate use will lead to a potential encoding clash. I see that the IPX class has been replaced by unassigned, also some other previous classes like geographic and provider-based have also been removed. This seems to imply that these schemes are not seen as being used in the foreseeable future, and even their use as previously specified might lead to an encoding clash at some later date. Presumably these values could be used for some other completely different scheme in the future, unrelated to their previous incarnation. Is my interpretation and conclusion correct? On the other hand, I could see how these values might say reserved rather than unassigned. If a value is reserved is interpreted as never will be assigned, then it would be safe to use in its original context. But if this were the case why not leave them in as before? Regards Keith At 1:57 PM -0700 06/10/2000, Bob Hinden wrote: >Erik, Thomas, > >The chairs of the IP Next Generation working group, on behalf of the >working group, request that the following document be published as >an Draft Standard: > > Title : IP Version 6 Addressing Architecture > Author(s) : B. Hinden, S. Deering > Filename : draft-ietf-ipngwg-addr-arch-v3-02.txt > Pages : 25 > Date : 05-Oct-00 > >A working group last call for this document was completed on April >10, 2000 and the document was discussed at the Adelaide IETF >meeting. The -02 version of the draft resolves issues raised during >the working group last call and subsequent discussion. > >This document will obsolete RFC2373. Changes from RFC2373 are >listed in Appendix B. > >Bob Hinden / Steve Deering >IPng Working Group Co-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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 6 02:16:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA6AEhN28152 for ipng-dist; Mon, 6 Nov 2000 02:14:43 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA6AEYj28145 for ; Mon, 6 Nov 2000 02:14:34 -0800 (PST) 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,v1.7) with ESMTP id CAA00730; Mon, 6 Nov 2000 02:14:33 -0800 (PST) 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 DAA20987; Mon, 6 Nov 2000 03:14:32 -0700 (MST) 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 CAA23322; Mon, 6 Nov 2000 02:14:30 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eA6AEQT22416; Mon, 6 Nov 2000 02:14:26 -0800 X-Virus-Scanned: Mon, 6 Nov 2000 02:14:26 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from UNKNOWN (139.92.151.236, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdjtDdF8; Mon, 06 Nov 2000 02:14:21 PST Message-Id: <4.3.2.7.2.20001106015411.01fa01b0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Nov 2000 02:12:33 -0800 To: Keith Knightson From: Bob Hinden Subject: Re: Request to Advance "IP Version 6 Addressing Architecture" Cc: Bob Hinden , Erik.Nordmark@eng.sun.com, narten@raleigh.ibm.com, scoya@ietf.org, deering@cisco.com, ipng@sunroof.eng.sun.com In-Reply-To: References: <4.3.2.7.2.20001006135159.02426b38@mailhost.iprg.nokia.com> <4.3.2.7.2.20001006135159.02426b38@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, >I am not sure I fully understand the distinction between reserved and >unassigned. It would seem to me that in neither case is it safe to use one >of the values for any purpose whatsoever, since a reserved value might >subsequently become unreserved, and an unassigned value might subsequently >become assigned. In either case, any intermediate use will lead to a >potential encoding clash. Correct. >I see that the IPX class has been replaced by unassigned, also some other >previous classes like geographic and provider-based have also been removed. The geographic and provider-based were removed sometime ago when the current document (RFC2373) was published and was replaced by the Aggregatable Global Unicast Addresses format. The IPX block was removed in the current draft after checking that there no intended usage planned. >This seems to imply that these schemes are not seen as being used in the >foreseeable future, and even their use as previously specified might lead >to an encoding clash at some later date. Presumably these values could be >used for some other completely different scheme in the future, unrelated >to their previous incarnation. > >Is my interpretation and conclusion correct? The currently published document, RFC2373, in the IETF standard definition of the IPv6 address blocks. When the current draft is published as an RFC it will obsolete RFC2373. Any use of the address blocks outside of the current assignments are likely to conflict with future assignments and would be outside of IETF defined usage. >On the other hand, I could see how these values might say reserved rather >than unassigned. If a value is reserved is interpreted as never will be >assigned, then it would be safe to use in its original context. But if >this were the case why not leave them in as before? Reserved means that the block is intended for a particular usage or should not be used. Unassigned means that it is open for future definition and usage. The IPX block was changed from reserved to unassigned because it was no longer going to be used for IPX and is now available for future definition. Hope this helps. Regards, 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 Mon Nov 6 10:18:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA6IFQA28565 for ipng-dist; Mon, 6 Nov 2000 10:15:26 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA6IFLj28558 for ; Mon, 6 Nov 2000 10:15:22 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id eA6IEVh28476 for ipng@sunroof.eng.sun.com; Mon, 6 Nov 2000 10:14:31 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA67Dsj28070 for ; Sun, 5 Nov 2000 23:13:54 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA06511 for ; Sun, 5 Nov 2000 23:13:56 -0800 (PST) Received: from indiainfo.com ([203.199.69.94]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA20862 for ; Sun, 5 Nov 2000 23:13:53 -0800 (PST) Received: from [203.197.138.194] (account ) by indiainfo.com (CommuniGate Pro WebUser 3.4b1) with HTTP id 5813805; Mon, 06 Nov 2000 12:41:31 +0530 From: "Niveda Monyvannan" Subject: Telnet extensions for IPv6 To: 6bone@isi.edu, users@ipv6.org, ipng@sunroof.eng.sun.com X-Mailer: CommuniGate Pro Web Mailer v.3.4b1 Date: Mon, 06 Nov 2000 12:41:31 +0530 Message-ID: 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 Hello, where can i find the spec/draft for telnet extensions for supporting IPv6 Regards, Niveda ---------------------------------------- http://mail.indiainfo.com First you had 10MB of free mail space. Now you can send mails in your own language !!! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 6 13:37:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA6LY3Y28700 for ipng-dist; Mon, 6 Nov 2000 13:34:03 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA6LXpj28693 for ; Mon, 6 Nov 2000 13:33:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA16924 for ; Mon, 6 Nov 2000 13:33:48 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08841 for ; Mon, 6 Nov 2000 13:33:42 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id PAA03221; Mon, 6 Nov 2000 15:33:24 -0600 (CST) Message-Id: <200011062133.PAA03221@gungnir.fnal.gov> To: Niveda Monyvannan Cc: 6bone@isi.edu, users@ipv6.org, ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Telnet extensions for IPv6 In-reply-to: Your message of Mon, 06 Nov 2000 12:41:31 +0530. Date: Mon, 06 Nov 2000 15:33:24 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > where can i find the spec/draft for telnet extensions for > supporting IPv6 Not to be flippant, but "What extensions?" The telnet protocol doesn't need any extensions, once your TCP understands how to do the pseudo-header checksum when IPv6 is the network layer. Ah, if you mean extensions to a particular telnet *program*, that's up to the author or vendor of the program, not the IETF. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 6 13:45:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA6Lhq228726 for ipng-dist; Mon, 6 Nov 2000 13:43:52 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA6Lhcj28719 for ; Mon, 6 Nov 2000 13:43:38 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA03924 for ; Mon, 6 Nov 2000 13:43:36 -0800 (PST) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13056 for ; Mon, 6 Nov 2000 13:43:36 -0800 (PST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA31064; Mon, 6 Nov 2000 16:43:28 -0500 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA25662; Mon, 6 Nov 2000 16:43:30 -0500 Received: from rotala.raleigh.ibm.com (IDENT:narten@localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id QAA17885; Mon, 6 Nov 2000 16:40:38 -0500 Message-Id: <200011062140.QAA17885@rotala.raleigh.ibm.com> To: Alex Conta cc: ipng@sunroof.eng.sun.com Subject: draft-ietf-ion-ipv6-ind-04.txt Date: Mon, 06 Nov 2000 16:40:38 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, In discussing this document (which the WG requested be advanced as PS), the IESG had the following question: If a node has anonymous address (per draft-ietf-ipngwg-addrconf-privacy-03.txt), are those IPv6 addresses also included in IND responses? The document should make this clear. 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 Nov 7 00:55:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA78o3s29108 for ipng-dist; Tue, 7 Nov 2000 00:50:03 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA78nij29100 for ; Tue, 7 Nov 2000 00:49:45 -0800 (PST) Received: from lillen (gbl-dhcp-203-193.France.Sun.COM [129.157.203.193]) by jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id eA78ng2321724; Tue, 7 Nov 2000 00:49:43 -0800 (PST) Date: Mon, 6 Nov 2000 13:11:07 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: erik.nordmark@eng.sun.com, matt@3am-software.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 > I need a clarification about the IPV6_PATHMTU ancillary data item > defined in draft-ietf-ipngwg-rfc2292bis-01.txt. The draft does not > (explicitly) mention how the application knows the corresponding > destination address for the returned MTU value. Which is correct? > > 1. this option has its meaning for a connected socket only. The > destination is the foreign address of the socket. > 2. the destination address should be specified in the msg_name member > returned by the corresponding recvmsg() call. > 3. the current spec is buggy. The ancillary data should contain the > socket address structure for the destination. > 4. others The spec is clearly incomplete in this area. I do think we want this to work for unconnected datagram sockets i.e. 1 is not an option. Does the implementors have any preferences between #2 and #3? Doing #3 would require defining a data structure containing an MTU field plus a socketaddr_in6. 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 Tue Nov 7 00:55:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA78o0j29107 for ipng-dist; Tue, 7 Nov 2000 00:50:00 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA78nfj29092 for ; Tue, 7 Nov 2000 00:49:41 -0800 (PST) Received: from lillen (gbl-dhcp-203-193.France.Sun.COM [129.157.203.193]) by jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id eA78nd2321716; Tue, 7 Nov 2000 00:49:39 -0800 (PST) Date: Mon, 6 Nov 2000 13:06:19 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [advanced API] possible infinite loop in cmsg data examination To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: erik.nordmark@eng.sun.com, matt@3am-software.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 > So, I'd suggest to add some warning in the example about the > possibility of the infinite loop or to rewrite the example itself like > this: > > while ((cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) != NULL) { > if (cmsgptr->cmsg_len == 0) > break; /* and return some error if necessary */ I'll add this check to the two examples in the document. 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 Tue Nov 7 03:01:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA7AxZk29290 for ipng-dist; Tue, 7 Nov 2000 02:59:35 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA7AxQj29283 for ; Tue, 7 Nov 2000 02:59:27 -0800 (PST) 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,v1.7) with ESMTP id CAA27337; Tue, 7 Nov 2000 02:59:23 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13859; Tue, 7 Nov 2000 02:59:20 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eA7AxEb14647; Tue, 7 Nov 2000 11:59:14 +0100 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 LAA22903; Tue, 7 Nov 2000 11:59:10 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id MAA47016; Tue, 7 Nov 2000 12:00:33 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011071100.MAA47016@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU In-reply-to: Your message of Mon, 06 Nov 2000 13:11:07 PST. Date: Tue, 07 Nov 2000 12:00:33 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The spec is clearly incomplete in this area. I do think we want this to work for unconnected datagram sockets i.e. 1 is not an option. => but 1 (connected sockets) should work of course. Does the implementors have any preferences between #2 and #3? Doing #3 would require defining a data structure containing an MTU field plus a socketaddr_in6. => by problem with #3 is the path MTU is a property of the path, not of an address, ie. with a routing header the path MTU can be different. I know this is not implemented like that (ie. pMTU are cached by destination address and if someone plays with a routing header one can spuriously change the pMTU :-) but it should then we have to keep the distinction... Thanks Francis.Dupont@enst-bretagne.fr PS: rfc2292bis is more than expired today... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 7 05:12:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA7DB8q29332 for ipng-dist; Tue, 7 Nov 2000 05:11:08 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA7DAxj29325 for ; Tue, 7 Nov 2000 05:10:59 -0800 (PST) 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,v1.7) with ESMTP id FAA20188 for ; Tue, 7 Nov 2000 05:10:58 -0800 (PST) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA06095 for ; Tue, 7 Nov 2000 05:10:58 -0800 (PST) Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id eA7DHXq28660; Tue, 7 Nov 2000 08:17:33 -0500 (EST) X-Accept-Language: fr,en,es Message-Id: <5.0.0.25.0.20001107081110.025b18f0@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 07 Nov 2000 08:14:01 -0500 To: Bob Hinden , ipng@sunroof.eng.sun.com From: Marc Blanchet Subject: pushing 2073 to historic Cc: deering@cisco.com In-Reply-To: <4.3.2.7.2.20001106015411.01fa01b0@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20001006135159.02426b38@mailhost.iprg.nokia.com> <4.3.2.7.2.20001006135159.02426b38@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, would it be relevant to now push RFC 2073 to historic at the same time as the new RFC replacing RFC2374? From RFC 2374: This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast Address Format". RFC 2073 will become historic. The Aggregatable Global Unicast Address Format is an improvement over RFC 2073 in a Marc. Marc Blanchet Viagénie inc. tel: 418-656-9254 http://www.viagenie.qc.ca ---------------------------------------------------------- Normos (http://www.normos.org): Internet standards portal: IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 7 10:09:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA7I8Eu29555 for ipng-dist; Tue, 7 Nov 2000 10:08:14 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA7I81j29548 for ; Tue, 7 Nov 2000 10:08:01 -0800 (PST) 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,v1.7) with ESMTP id KAA10883; Tue, 7 Nov 2000 10:07:55 -0800 (PST) Received: from roll.mentat.com ([192.88.122.129]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03130; Tue, 7 Nov 2000 10:07:53 -0800 (PST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA23358; Tue, 7 Nov 2000 10:09:52 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA10603; Tue, 7 Nov 2000 10:09:52 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id KAA22048; Tue, 7 Nov 2000 10:10:01 -0800 (PST) Date: Tue, 7 Nov 2000 10:10:01 -0800 (PST) From: Tim Hartrick Message-Id: <200011071810.KAA22048@feller.mentat.com> To: Erik.Nordmark@eng.sun.com Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > The spec is clearly incomplete in this area. > I do think we want this to work for unconnected datagram sockets i.e. 1 is > not an option. > > Does the implementors have any preferences between #2 and #3? > Doing #3 would require defining a data structure containing an MTU field > plus a socketaddr_in6. > I would prefer #3. 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 Tue Nov 7 14:17:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA7MEha00035 for ipng-dist; Tue, 7 Nov 2000 14:14:43 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA7MEYj00028 for ; Tue, 7 Nov 2000 14:14:34 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA13736 for ; Tue, 7 Nov 2000 14:14:34 -0800 (PST) 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 PAA09505 for ; Tue, 7 Nov 2000 15:14:30 -0700 (MST) 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 OAA17092; Tue, 7 Nov 2000 14:14:29 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eA7MEQc08196; Tue, 7 Nov 2000 14:14:26 -0800 X-Virus-Scanned: Tue, 7 Nov 2000 14:14:26 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from UNKNOWN (139.92.151.248, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdGtl3qf; Tue, 07 Nov 2000 14:14:20 PST Message-Id: <4.3.2.7.2.20001107141115.022646b8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Nov 2000 14:12:35 -0800 To: Marc Blanchet From: Bob Hinden Subject: Re: pushing 2073 to historic Cc: Bob Hinden , ipng@sunroof.eng.sun.com, deering@cisco.com In-Reply-To: <5.0.0.25.0.20001107081110.025b18f0@mail.viagenie.qc.ca> References: <4.3.2.7.2.20001106015411.01fa01b0@mailhost.iprg.nokia.com> <4.3.2.7.2.20001006135159.02426b38@mailhost.iprg.nokia.com> <4.3.2.7.2.20001006135159.02426b38@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Marc, > would it be relevant to now push RFC 2073 to historic at the same > time as the new RFC replacing RFC2374? Thanks for pointing this out. I agree it should be historic and have started talking to the Internet AD's to see how to proceed. Bob > From RFC 2374: > > This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast > Address Format". RFC 2073 will become historic. The Aggregatable > Global Unicast Address Format is an improvement over RFC 2073 in a -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 7 22:45:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA86iON00476 for ipng-dist; Tue, 7 Nov 2000 22:44:24 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA86iFj00469 for ; Tue, 7 Nov 2000 22:44:15 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA11801 for ; Tue, 7 Nov 2000 22:44:15 -0800 (PST) Received: from givenchy (mailhost.6wind.com [212.234.238.114]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA21136 for ; Tue, 7 Nov 2000 22:44:13 -0800 (PST) Received: from intranet.6wind.com (intranet.6wind.com [10.0.0.113]) by givenchy (Postfix) with ESMTP id 2A8829B3 for ; Wed, 8 Nov 2000 07:47:40 +0100 (CET) Received: from 6wind.com (unknown [10.16.0.123]) by intranet.6wind.com (Postfix) with ESMTP id 3A20CDBA7 for ; Wed, 8 Nov 2000 07:44:49 -0600 (CST) Message-ID: <3A08F72B.AEDBEB18@6wind.com> Date: Wed, 08 Nov 2000 07:48:11 +0100 From: Alain Ritoux X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Cc: ipng@sunroof.eng.sun.com Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU References: <200011071810.KAA22048@feller.mentat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi everybody, I hace been reading various messages about the advanced API 2292-bis draft, but I can't find it on the ipng web page, and the IETF draft search engine doesn't seem to know about it. Does any one know where I can find it ? Thanks. Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 8 03:01:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA8B00A00625 for ipng-dist; Wed, 8 Nov 2000 03:00:00 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA8Axnj00618 for ; Wed, 8 Nov 2000 02:59:50 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA03813 for ; Wed, 8 Nov 2000 02:59:49 -0800 (PST) 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 CAA11459 for ; Wed, 8 Nov 2000 02:59:48 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21370; Wed, 8 Nov 2000 05:59:45 -0500 (EST) Message-Id: <200011081059.FAA21370@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-rfc2292bis-02.txt Date: Wed, 08 Nov 2000 05:59:45 -0500 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 IPNG Working Group of the IETF. Title : Advanced Sockets API for IPv6 Author(s) : R. Stevens, M. Thomas, E. Nordmark Filename : draft-ietf-ipngwg-rfc2292bis-02.txt Pages : 74 Date : 07-Nov-00 A separate specification [RFC-2553] contain changes to the sockets API to support IP version 6. Those changes are for TCP and UDP-based applications and will support most end-user applications in use today: Telnet and FTP clients and servers, HTTP clients and servers, and the like. But another class of applications exists that will also be run under IPv6. We call these 'advanced' applications and today this includes programs such as Ping, Traceroute, routing daemons, multicast routing daemons, router discovery daemons, and the like. The API feature typically used by these programs that make them 'advanced' is a raw socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge of the packet header formats used by these protocols. To provide portability for applications that use raw sockets under IPv6, some standardization is needed for the advanced API features. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface) and IPv6 extension headers that are not addressed in [RFC-2553]: The Routing header (source routing), Hop-by-Hop options, and Destination options. This document provides API access to these features too. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-02.txt 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-rfc2292bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001107084840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2292bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001107084840.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 Nov 8 08:35:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA8GXw500851 for ipng-dist; Wed, 8 Nov 2000 08:33:58 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA8GXnj00844 for ; Wed, 8 Nov 2000 08:33:49 -0800 (PST) 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,v1.7) with ESMTP id IAA26420; Wed, 8 Nov 2000 08:33:48 -0800 (PST) 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 IAA24366; Wed, 8 Nov 2000 08:33:41 -0800 (PST) Received: from localhost ([3ffe:501:4857:1002:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id BAA22412; Thu, 9 Nov 2000 01:18:59 +0900 (JST) Date: Thu, 09 Nov 2000 01:32:54 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: Erik Nordmark , matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU In-Reply-To: In your message of "Tue, 07 Nov 2000 12:00:33 +0100" <200011071100.MAA47016@givry.rennes.enst-bretagne.fr> References: <200011071100.MAA47016@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 07 Nov 2000 12:00:33 +0100, >>>>> Francis Dupont said: > Does the implementors have any preferences between #2 and #3? > Doing #3 would require defining a data structure containing an MTU field > plus a socketaddr_in6. > => by problem with #3 is the path MTU is a property of the path, not > of an address, ie. with a routing header the path MTU can be different. > I know this is not implemented like that (ie. pMTU are cached by destination > address and if someone plays with a routing header one can spuriously > change the pMTU :-) but it should then we have to keep the distinction... I personally like #3, because it seems the most flexible one (e.g. to contain the real "path" including all intermediate nodes - although I'm not sure if this kind of stuff is worth implementing despite of its complexity). But this will affect existing implementations, so I won't insist on this idea. I vote for #3 if pre-implementors of this option do not object. (We've not implemented this option yet.) > PS: rfc2292bis is more than expired today... Yes, but we've finally seen the latest one. 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 Nov 8 09:59:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA8Hvpr00931 for ipng-dist; Wed, 8 Nov 2000 09:57:51 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA8Hvgj00924 for ; Wed, 8 Nov 2000 09:57:42 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA01711 for ; Wed, 8 Nov 2000 09:57:42 -0800 (PST) Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA25531 for ; Wed, 8 Nov 2000 09:57:40 -0800 (PST) Received: from rp.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.9.3/jtpda-5.3.2) with ESMTP id SAA09235 ; Wed, 8 Nov 2000 18:30:21 +0100 Received: from rp.lip6.fr (otos.lip6.fr [132.227.61.47]) by rp.lip6.fr (8.8.8/jtpda-5.2) with ESMTP id SAA12289 ; Wed, 8 Nov 2000 18:30:19 +0100 (MET) Message-ID: <3A098DAB.52FD42BD@rp.lip6.fr> Date: Wed, 08 Nov 2000 18:30:19 +0100 From: Vida Rolland Organization: Laboratoire Lip6 X-Mailer: Mozilla 4.75 [fr] (WinNT; U) X-Accept-Language: fr MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com, ssm-interest@external.cisco.com, Supratik Bhattacharyya Subject: MLDv3 - Internet Draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All, The revised IPng Working Group Charter published on the 5th of October on the mailing list of the IPng WG contained a call for contribution on "Extending MLD to include functionality of IGMPv3". Here is the abstract of an Internet Draft proposal, called "Multicast Listener Discovery Version 3 (MLDv3) for IPv6" () ************* Abstract: This document specifies Version 3 of the Multicast Listener Discovery protocol, MLDv3. MLD is the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. MLDv3 is derived from version 3 of IPv4's Internet Group Management Protocol, IGMPv3. Compared to the previous version, MLDv3 adds support for "source filtering", that is, the ability for a node to report interest in listening to packets *only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to links where there are no interested listeners. When compared to IGMPv3, one important difference to note is that MLDv3 uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types. ************ The full text of the draft can be found at: http://www-rp.lip6.fr/~vida/draft-vida-mld-v3-00.txt We welcome any comments or suggestions on the text. Best regards, Rolland Vida, LIP6, Paris, France. ----------------------------------------------------------------------- "Not everything that can be counted counts, and not everything that counts can be counted. " - Albert Einstein Rolland Vida Universite Paris VI "Pierre et Marie Curie" tel: +33 (0)144 277 126 Laboratoire LIP6 - CNRS, C669 fax: +33 (0)144 277 495 8, Rue de Capitaine Scott, 75015, Paris mailto:vida@rp.lip6.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 Wed Nov 8 18:32:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA92UmN01485 for ipng-dist; Wed, 8 Nov 2000 18:30:48 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA92Ubj01478 for ; Wed, 8 Nov 2000 18:30:37 -0800 (PST) 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,v1.7) with ESMTP id SAA16408 for ; Wed, 8 Nov 2000 18:30:37 -0800 (PST) Received: from starfruit.itojun.org (kame202.kame.net [203.178.141.202]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA03333 for ; Wed, 8 Nov 2000 19:30:35 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id C56CC7E1D for ; Thu, 9 Nov 2000 11:29:52 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: deprecated address handling for inbound TCP 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: Jun-ichiro itojun Hagino Date: Thu, 09 Nov 2000 11:29:52 +0900 Message-Id: <20001109022952.C56CC7E1D@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm investgating how deprecated address should be treated, and have one question (I need a tiny clarification). RFC2462 talks about how to handle deprecated address, in multiple places. 5.5.4 looks to be the most definitive one. It basically says, in the first couple of lines: 1. use of deprecated addr with existing communication is okay - "SHOULD continue to be used" 2. use of deprecated address for new communication: (2a) "SHOULD NOT be used if no alternate address with sufficient scope is available" (2b) nothing mentioned otherwise - implies that it is permitted to use deprecated address. we can optionally disallow the use of deprecated address, in (2b) case. if we think about some scenarios with the above condition, it will be like below. for me "new inbound TCP SYN" case (3rd bullet below) is not very clear, and I may need a clarification. if our intent is to make the deprecated address (or the /48 prefix associated with it) to go away, it may be better to always reject the new TCP connection attempt. however, RFC2462 5.5.4 does not seem to do that. so I'm a little bit confused. - I have an existing TCP connection with local address bound to a deprecated address. can I send a TCP packet to the peer? yes, based on condition 1. - User application issued TCP connection request. The kernel need to establish a new connection. Can I use a deprecated address as the local address? if we have alternate address, no, based on (2a). if we have no alternate address, it falls into (2b). - if (2b) behavior is allowed, yes (default). - if (2b) behavior is disallowed, no. - I got a new TCP connection request from outside, with my deprecated address as the destination. am I allowed to accept this connetion? since we have no control over the address on our side, this falls into (2b). - if (2b) behavior is allowed, yes. - if (2b) behavior is disallowed, no. note that we cannot issue TCP RST in this case (if we issue TCP RST we will need to use deprecated address as the source) - UDP issues needs more thinking - how we should handle connected/ non-connected UDP sockets? - ICMPv6 echo/whatever? the behavior would affect site renumbering scnearios a little bit. itojun --- RFC2462 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. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 8 20:00:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA93wDY01546 for ipng-dist; Wed, 8 Nov 2000 19:58:13 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA93w4j01539 for ; Wed, 8 Nov 2000 19:58:04 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA09418 for ; Wed, 8 Nov 2000 19:58:03 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA17894 for ; Wed, 8 Nov 2000 19:58:02 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 08 Nov 2000 19:57:18 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Wed, 8 Nov 2000 19:58:00 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9BAD@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "'Jun-ichiro itojun Hagino'" Cc: ipng@sunroof.eng.sun.com Subject: RE: deprecated address handling for inbound TCP Date: Wed, 8 Nov 2000 19:57:48 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think the rule is: if an application or upper-layer protocol specifies the address, then you can use a deprecated address. So if an application explicitly binds to a deprecated address, then you use it. If an existing TCP connection is using a deprecated address, then you continue to use it. If you receive TCP SYN sent to a deprecated address, then you can send a SYN ACK and establish a TCP connection. If you receive an Echo Request, then you can send an Echo Reply. Etc. If the IPv6 layer is in the position of selecting a source address (because an address was not specified by the application or upper-layer), then you avoid using a deprecated address. See draft-ietf-ipngwg-default-addr-select-01. > - I have an existing TCP connection with local address bound to > a deprecated address. can I send a TCP packet to the peer? Yes. > - User application issued TCP connection request. The > kernel need to > establish a new connection. Can I use a deprecated > address as the > local address? You avoid using a deprecated address, but in some circumstances you do choose a deprecated address. > - I got a new TCP connection request from outside, with > my deprecated > address as the destination. am I allowed to accept > this connetion? Yes. 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 Nov 9 00:17:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA98EEl01620 for ipng-dist; Thu, 9 Nov 2000 00:14:14 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA98E3j01612 for ; Thu, 9 Nov 2000 00:14:03 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA17606 for ; Thu, 9 Nov 2000 00:14:04 -0800 (PST) Received: from starfruit.itojun.org (kame202.kame.net [203.178.141.202]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA16532 for ; Thu, 9 Nov 2000 00:13:48 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 587207E1D for ; Thu, 9 Nov 2000 17:13:09 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Thu, 09 Nov 2000 11:29:52 +0900. <20001109022952.C56CC7E1D@starfruit.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: deprecated address handling for inbound TCP From: Jun-ichiro itojun Hagino Date: Thu, 09 Nov 2000 17:13:09 +0900 Message-Id: <20001109081309.587207E1D@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - I got a new TCP connection request from outside, with my deprecated > address as the destination. am I allowed to accept this connetion? > since we have no control over the address on our side, this > falls into (2b). > - if (2b) behavior is allowed, yes. > - if (2b) behavior is disallowed, no. note that we cannot > issue TCP RST in this case (if we issue TCP RST we will > need to use deprecated address as the source) jinmei suggested that it may be better to send TCP RST with deprecated source, as it will help clients to try the next available address (on getaddrinfo chain, or something). i tend to agree. 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 Nov 9 00:32:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA98UpM01647 for ipng-dist; Thu, 9 Nov 2000 00:30:51 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA98Uhj01640 for ; Thu, 9 Nov 2000 00:30:43 -0800 (PST) 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,v1.7) with ESMTP id AAA06066 for ; Thu, 9 Nov 2000 00:30:43 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA07009 for ; Thu, 9 Nov 2000 00:30:42 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 09 Nov 2000 00:29:58 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Thu, 9 Nov 2000 00:30:41 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80130C8F2@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "'Jun-ichiro itojun Hagino'" Cc: ipng@sunroof.eng.sun.com Subject: RE: deprecated address handling for inbound TCP Date: Thu, 9 Nov 2000 00:30:28 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > jinmei suggested that it may be better to send TCP RST > with deprecated > source, as it will help clients to try the next > available address > (on getaddrinfo chain, or something). i tend to agree. I disagree. The deprecated address shouldn't be in DNS, so the application that is trying to connect to your deprecated address probably is *not* stepping through getaddrinfo results. Instead it is probably some kind of distributed application, and it got your address a day ago (from getpeername or getaddrinfo) and saved it in various data structures. Now it is trying to connect to you again. 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 Nov 9 01:02:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA98wHh01678 for ipng-dist; Thu, 9 Nov 2000 00:58:17 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA98vnj01671 for ; Thu, 9 Nov 2000 00:57:49 -0800 (PST) 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,v1.7) with ESMTP id AAA20920 for ; Thu, 9 Nov 2000 00:57:39 -0800 (PST) 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 AAA18075 for ; Thu, 9 Nov 2000 00:57:37 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id RAA28469; Thu, 9 Nov 2000 17:57:30 +0900 (JST) To: Richard Draves cc: ipng@sunroof.eng.sun.com In-reply-to: richdr's message of Thu, 09 Nov 2000 00:30:28 PST. <7695E2F6903F7A41961F8CF888D87EA80130C8F2@red-msg-06.redmond.corp.microsoft.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: deprecated address handling for inbound TCP From: itojun@iijlab.net Date: Thu, 09 Nov 2000 17:57:30 +0900 Message-ID: <28467.973760250@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I disagree. The deprecated address shouldn't be in DNS, so the application >that is trying to connect to your deprecated address probably is *not* >stepping through getaddrinfo results. Instead it is probably some kind of >distributed application, and it got your address a day ago (from getpeername >or getaddrinfo) and saved it in various data structures. Now it is trying to >connect to you again. yah, but there are faulty DNS servers caches result longer than it should. if we accept the connection, we will use deprecated address for longer period of time, and we end up cannot terminate contract with ISP-OLD. 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 Nov 9 01:07:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA995vr01725 for ipng-dist; Thu, 9 Nov 2000 01:05:57 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA995kj01718 for ; Thu, 9 Nov 2000 01:05:46 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA03213 for ; Thu, 9 Nov 2000 01:05:46 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id BAA21874 for ; Thu, 9 Nov 2000 01:05:45 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 09 Nov 2000 01:05:01 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Thu, 9 Nov 2000 01:05:44 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80130C8F6@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "'itojun@iijlab.net'" Cc: ipng@sunroof.eng.sun.com Subject: RE: deprecated address handling for inbound TCP Date: Thu, 9 Nov 2000 01:05:28 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > yah, but there are faulty DNS servers caches result longer than > it should. if we accept the connection, we will use deprecated > address for longer period of time, and we end up cannot > terminate > contract with ISP-OLD. If the DNS cache is faulty, it might not have the new address in it. So if you fail the connect to the old address, you won't get any connection at all. 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 Nov 9 02:08:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA9A7VX01797 for ipng-dist; Thu, 9 Nov 2000 02:07:31 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA9A7Jj01790 for ; Thu, 9 Nov 2000 02:07:19 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA07932 for ; Thu, 9 Nov 2000 02:07:13 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25382 for ; Thu, 9 Nov 2000 02:07:12 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id TAA29263; Thu, 9 Nov 2000 19:07:08 +0900 (JST) To: Richard Draves cc: ipng@sunroof.eng.sun.com In-reply-to: richdr's message of Thu, 09 Nov 2000 01:05:28 PST. <7695E2F6903F7A41961F8CF888D87EA80130C8F6@red-msg-06.redmond.corp.microsoft.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: deprecated address handling for inbound TCP From: itojun@iijlab.net Date: Thu, 09 Nov 2000 19:07:08 +0900 Message-ID: <29261.973764428@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> yah, but there are faulty DNS servers caches result longer than >> it should. if we accept the connection, we will use deprecated >> address for longer period of time, and we end up cannot >> terminate >> contract with ISP-OLD. >If the DNS cache is faulty, it might not have the new address in it. So if >you fail the connect to the old address, you won't get any connection at >all. oops, we are talking about different thing. you are talking about default behavior, where we allow packets with deprecated address to be generated. I was talking about non-default behavior where deprecated address is forbidden. sorry for confusion and not being clear enough. itojun --- 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. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 9 02:27:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA9AQCm01824 for ipng-dist; Thu, 9 Nov 2000 02:26:12 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA9AQ3j01817 for ; Thu, 9 Nov 2000 02:26:03 -0800 (PST) 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,v1.7) with ESMTP id CAA15677 for ; Thu, 9 Nov 2000 02:26:02 -0800 (PST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA10698 for ; Thu, 9 Nov 2000 03:26:00 -0700 (MST) Received: from esebh11nok.ntc.nokia.com (esebh11nok.ntc.nokia.com [131.228.10.108]) by mgw-x3.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id eA9APxB09677 for ; Thu, 9 Nov 2000 12:25:59 +0200 (EET) Received: from loki.research.nokia.com ([172.21.33.76]) by esebh11nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id WMCMGG98; Thu, 9 Nov 2000 12:25:58 +0200 Received: from hews0169nrc (hed040-232.research.nokia.com [172.21.40.232]) by loki.research.nokia.com (8.9.3/8.9.3) with SMTP id MAA18814 for ; Thu, 9 Nov 2000 12:25:57 +0200 (EET) X-Authentication-Warning: loki.research.nokia.com: Host hed040-232.research.nokia.com [172.21.40.232] claimed to be hews0169nrc From: "Markku Savela" To: Subject: draft-ietf-ipngwg-rfc2292bis-02.txt Date: Thu, 9 Nov 2000 12:25:56 +0200 Message-ID: <000001c04a37$72b7aab0$e82815ac@hews0169nrc.research.nokia.com> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm currently looking how the ideas presented in draft-ietf-ipngwg-rfc2292bis-02.txt would map into our IPv6 implementation for EPOC, and I have some questions (suggestions?). Concerning packet specific data and "4.2. UDP and Raw Socket Implications" I may have missed it, but the text appears to leave it somewhat unclear as to which packet the data actually belong, say we have a sequence recv() UDP packet #1, Queued UDP packet #2 is waiting recvmsg() Which UDP packet the recvmsg data applies? I would lean to saying #2, because then the kernel doesn't need to keep extra buffers around, and it can just build the data as required directly from the packet. How are current implementations actually doing it? My interpretation would mean that to reliably get the correct data about the packet, application must always first do recvmsg() and then recv() when a socket signals that data can be read. Secondly, I don't like the options: setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on, sizeof(on)); setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on)); setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &on, sizeof(on)); setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on)); setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDRDSTOPTS, &on, sizeof(on)); I would prefer a more generic solution, for example, following the idea of the ICMP6_FILTER struct ipv6_filter extfilter; setsockopt(fd, IPPROTO_IPV6, IPV6_FILTER, &extfilter); I would leave it up to application to recognize between destination options before routing header and after. It only would need to ask both routing headers and destination options in the filter, and it can see from the recvmsg data, whether options were before or after routing header, or both. This does not mean that the specification could not have the nice access and building methods for the headers, as described in later sections for options and routing headers. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 9 03:22:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA9BKtG01882 for ipng-dist; Thu, 9 Nov 2000 03:20:55 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA9BKjj01875 for ; Thu, 9 Nov 2000 03:20:46 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA15681 for ; Thu, 9 Nov 2000 03:20:45 -0800 (PST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA28609 for ; Thu, 9 Nov 2000 03:20:43 -0800 (PST) Received: from esebh11nok.ntc.nokia.com (esebh11nok.ntc.nokia.com [131.228.10.108]) by mgw-x3.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id eA9BKdB13689 for ; Thu, 9 Nov 2000 13:20:39 +0200 (EET) Received: from loki.research.nokia.com ([172.21.33.76]) by esebh11nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id WMCMGLKP; Thu, 9 Nov 2000 13:20:39 +0200 Received: from hews0169nrc (hed040-232.research.nokia.com [172.21.40.232]) by loki.research.nokia.com (8.9.3/8.9.3) with SMTP id NAA19295 for ; Thu, 9 Nov 2000 13:20:38 +0200 (EET) X-Authentication-Warning: loki.research.nokia.com: Host hed040-232.research.nokia.com [172.21.40.232] claimed to be hews0169nrc From: "Markku Savela" To: Subject: RE: draft-ietf-ipngwg-rfc2292bis-02.txt Date: Thu, 9 Nov 2000 13:20:37 +0200 Message-ID: <000101c04a3f$167b5370$e82815ac@hews0169nrc.research.nokia.com> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <000001c04a37$72b7aab0$e82815ac@hews0169nrc.research.nokia.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: EXT Markku Savela > which packet the data actually belong, say we have a sequence > > recv() UDP packet #1, > Queued UDP packet #2 is waiting > recvmsg() Oops, I guess you can ignore this part. I didn't realize that recvmsg also returns the packet... (shows how little I have done advanced programming with unixes :-). However, EPOC Socket API does not have recvmsg equivalent, and I still have the problem I presented with whatever solution I invent (ioctl?) for retrieving the packet data. But, that will be local issue of no generic insterest. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 9 07:06:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA9F54B02056 for ipng-dist; Thu, 9 Nov 2000 07:05:04 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA9F4sj02049 for ; Thu, 9 Nov 2000 07:04:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA10117 for ; Thu, 9 Nov 2000 07:04:54 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12492 for ; Thu, 9 Nov 2000 07:04:50 -0800 (PST) Received: from zed.isi.edu (root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA17827; Thu, 9 Nov 2000 07:04:49 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.9.3/8.8.6) id HAA14458; Thu, 9 Nov 2000 07:04:49 -0800 Message-Id: <200011091504.HAA14458@zed.isi.edu> Subject: Re: deprecated address handling for inbound TCP To: richdr@microsoft.com (Richard Draves) Date: Thu, 9 Nov 2000 07:04:49 -0800 (PST) Cc: itojun@iijlab.net ('Jun-ichiro itojun Hagino'), ipng@sunroof.eng.sun.com In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA80130C8F2@red-msg-06.redmond.corp.microsoft.com> from "Richard Draves" at Nov 09, 2000 12:30:28 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % % > jinmei suggested that it may be better to send TCP RST % > with deprecated % > source, as it will help clients to try the next % > available address % > (on getaddrinfo chain, or something). i tend to agree. % % I disagree. The deprecated address shouldn't be in DNS, so the application % that is trying to connect to your deprecated address probably is *not* % stepping through getaddrinfo results. Instead it is probably some kind of % distributed application, and it got your address a day ago (from getpeername % or getaddrinfo) and saved it in various data structures. Now it is trying to % connect to you again. Why shouldn't an address be in the DNS? And how can you tell that an address, deprecated for your particular instance, has not been re-issued and is valid for some other system? --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 Thu Nov 9 07:09:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA9F8JC02077 for ipng-dist; Thu, 9 Nov 2000 07:08:19 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA9F8Aj02070 for ; Thu, 9 Nov 2000 07:08:10 -0800 (PST) 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,v1.7) with ESMTP id HAA23794 for ; Thu, 9 Nov 2000 07:08:11 -0800 (PST) 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 HAA13638 for ; Thu, 9 Nov 2000 07:08:09 -0800 (PST) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA14946; Thu, 9 Nov 2000 15:08:07 GMT Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA26952; Thu, 9 Nov 2000 15:08:05 GMT Message-ID: <3A0ABDBA.E7D4B7C1@hursley.ibm.com> Date: Thu, 09 Nov 2000 09:07:38 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ramanan CC: ipng Subject: Re: IPv6 address formats (rfc1884) References: <3A0A9A68.A8C7B360@india.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have switched this to the IPNG working group list where it belongs. (To join the list see http://www.ietf.org/html.charters/ipngwg-charter.html) RFC 1884 is obsolete and replaced by RFC 2373, which itself is being updated by the draft at http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-02.txt However this does not really affect your question. We have had some trouble in defining precise ABNF to include exactly the formats we want and exclude those which make no sense. The ABNF we had was defective, so it has been removed from the latest draft. If you can design ABNF that is complete and correct it would be a valuable contribution. My opinion on your examples below: Ramanan wrote: > > I want some clarification on ip(v6) address representation. > > How do we treat the following addresses? Are they valid or > otherwise? > > 1:2:3:4:5:6::7:8 Invalid. "::" is supposed to represent a string of zeros; in this case it could only be a null string. But I could imagine writing a parser that would accept this and treat it as equivalent to 1:2:3:4:5:6:7:8 That might be a good example of defensive programming. > ::1:2:3:4:5:6:7:8 Same. > > 0:0:0:0:0:0:1.2.3.4 Valid syntax. Equivalent to ::1.2.3.4 > 0::0:0:0:0:0:1.2.3.4 Invalid (same reason as above) > > 0:0:0:0:0:ffff:1.2.3.4 Valid syntax. There is an almost identical example in the draft. > 0::0:0:0:0:ffff:1.2.3.4 Invalid (same reason as above) Of course, valid syntax does not mean that the address is valid, but that was not your question. Brian > > The rfc does not state if these are allowed. > > This clarification is important as some user scripts might > generate such ip addresses. > > An analogy I found is that most unix versions treat > /home/./ftp > same as > /home/ftp > > please getback to me suggestions? > > Ramanan -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.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 Thu Nov 9 10:13:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA9IBPg02233 for ipng-dist; Thu, 9 Nov 2000 10:11:25 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA9IBGj02226 for ; Thu, 9 Nov 2000 10:11:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA05340 for ; Thu, 9 Nov 2000 10:11:16 -0800 (PST) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27937 for ; Thu, 9 Nov 2000 10:11:16 -0800 (PST) Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id eA9IIIq63402 for ; Thu, 9 Nov 2000 13:18:18 -0500 (EST) X-Accept-Language: fr,en,es Message-Id: <5.0.0.25.0.20001109131032.02bfb408@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 09 Nov 2000 13:14:07 -0500 To: ipng@sunroof.eng.sun.com From: Marc Blanchet Subject: dns standard hole In-Reply-To: <4.3.2.7.2.20000922115556.0210b5b8@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, for dns, right now (unless I'm wrong), we have: - RFC 1886, (AAAA records) - draft-...-dns-lookups (A6 records) then, bind and resolvers are preferring A6 records before AAAA. Some time apps timeout because of no A6 record but the 2nd query for the AAAA record take too much time as a whole. deploying ipv6 without a standard for A6 records is not great. I've looked at my ipng mail folder and haven't found a last call on A6 draft. Any time soon? Regards, Marc. Marc Blanchet Viagénie inc. tel: 418-656-9254 http://www.viagenie.qc.ca ---------------------------------------------------------- Normos (http://www.normos.org): Internet standards portal: IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 9 10:39:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eA9Ic4R02298 for ipng-dist; Thu, 9 Nov 2000 10:38:04 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eA9Ibtj02291 for ; Thu, 9 Nov 2000 10:37:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA05814 for ; Thu, 9 Nov 2000 10:37:55 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27375 for ; Thu, 9 Nov 2000 10:37:54 -0800 (PST) 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 KAA07150; Thu, 9 Nov 2000 10:37:54 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eA9IbqR25863; Thu, 9 Nov 2000 10:37:52 -0800 X-Virus-Scanned: Thu, 9 Nov 2000 10:37:52 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from Ihinden-5.iprg.nokia.com (205.226.22.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdiM0FP6; Thu, 09 Nov 2000 10:37:43 PST Message-Id: <4.3.2.7.2.20001109103339.021a7598@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Nov 2000 10:35:47 -0800 To: Marc Blanchet From: Bob Hinden Subject: Re: dns standard hole Cc: ipng@sunroof.eng.sun.com In-Reply-To: <5.0.0.25.0.20001109131032.02bfb408@mail.viagenie.qc.ca> References: <4.3.2.7.2.20000922115556.0210b5b8@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Marc, Take a look at: RFC2874 "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", July 2000. Bob At 01:14 PM 11/9/2000 -0500, Marc Blanchet wrote: >Hi, for dns, right now (unless I'm wrong), we have: >- RFC 1886, (AAAA records) >- draft-...-dns-lookups (A6 records) > >then, bind and resolvers are preferring A6 records before AAAA. Some time >apps timeout because of no A6 record but the 2nd query for the AAAA record >take too much time as a whole. > >deploying ipv6 without a standard for A6 records is not great. > >I've looked at my ipng mail folder and haven't found a last call on A6 >draft. Any time soon? > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 9 20:11:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAA4AHE02669 for ipng-dist; Thu, 9 Nov 2000 20:10:17 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAA4A8j02662 for ; Thu, 9 Nov 2000 20:10:08 -0800 (PST) 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,v1.7) with ESMTP id UAA06664 for ; Thu, 9 Nov 2000 20:10:08 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08535 for ; Thu, 9 Nov 2000 20:10:08 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id C380C4FE6; Thu, 9 Nov 2000 23:10:07 -0500 (EST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 83AC25118; Thu, 9 Nov 2000 23:10:07 -0500 (EST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id XAA0000698851; Thu, 9 Nov 2000 23:09:48 -0500 (EST) From: Jim Bound Message-Id: <200011100409.XAA0000698851@anw.zk3.dec.com> To: Richard Draves Cc: ipng@sunroof.eng.sun.com Subject: Re: deprecated address handling for inbound TCP In-reply-to: Your message of "Wed, 08 Nov 2000 19:57:48 PST." <7695E2F6903F7A41961F8CF888D87EA81C9BAD@red-msg-06.redmond.corp.microsoft.com> Date: Thu, 09 Nov 2000 23:09:46 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, I can think of mission critical applications where no new send operations would be permitted at all by an implementation as a choice when an address has become deprecated. I believe some customers will want this behavior. I think it wise if implementors have knobs to not permit any communications with a deprecated address except for existing connections. I think what addrconf has stated is fine and clear. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 9 21:11:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAA59Zb02698 for ipng-dist; Thu, 9 Nov 2000 21:09:35 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAA59Oj02691 for ; Thu, 9 Nov 2000 21:09:24 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA12287 for ; Thu, 9 Nov 2000 21:09:23 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA03425 for ; Thu, 9 Nov 2000 21:09:23 -0800 (PST) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 09 Nov 2000 21:09:20 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Thu, 9 Nov 2000 21:09:19 -0800 Message-ID: From: Brian Zill To: "'Bill Manning'" Cc: ipng@sunroof.eng.sun.com Subject: RE: deprecated address handling for inbound TCP Date: Thu, 9 Nov 2000 21:09:15 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Why shouldn't an address be in the DNS? In the renumbering scenario they were discussing, you'd switch your DNS entries from the old address to the new address at the start of the transition period. So the old (deprecated) address wouldn't be in the DNS. > And how can you tell that an address, deprecated for your > particular instance, has not been re-issued and is valid > for some other system? Because the old prefix wouldn't be released back for reassignment until the end of transition period. > --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 Thu Nov 9 22:23:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAA6LmN02737 for ipng-dist; Thu, 9 Nov 2000 22:21:48 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAA6Lej02730 for ; Thu, 9 Nov 2000 22:21:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA06935 for ; Thu, 9 Nov 2000 22:21:39 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA00598 for ; Thu, 9 Nov 2000 22:21:38 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 09 Nov 2000 22:20:51 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Thu, 9 Nov 2000 21:55:04 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8011AC2B0@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: Bill Manning Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: RE: deprecated address handling for inbound TCP Date: Thu, 9 Nov 2000 21:54:09 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Why shouldn't an address be in the DNS? And how can you tell > that an address, deprecated for your particular instance, has > not been re-issued and is valid for some other system? The usual reason for putting a node's address in the DNS is so that someone else can look it up and use the address to contact the node. Deprecated addresses are not supposed to be used for new communication. So it seems counterproductive to put deprecated addresses in the DNS. I don't understand your comment about reissuing an address. A unicast address should only be assigned to one node (or more strictly, interface). If an address that was assigned to node X is now assigned to node Y, then of course a DNS lookup of X's name should not return the address. 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 Nov 9 22:47:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAA6jlt02775 for ipng-dist; Thu, 9 Nov 2000 22:45:47 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAA6jbj02768 for ; Thu, 9 Nov 2000 22:45:37 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA13559 for ; Thu, 9 Nov 2000 22:45:36 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA25253 for ; Thu, 9 Nov 2000 22:45:35 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id PAA11423; Fri, 10 Nov 2000 15:44:55 +0900 (JST) To: Richard Draves cc: Bill Manning , ipng@sunroof.eng.sun.com In-reply-to: richdr's message of Thu, 09 Nov 2000 21:54:09 PST. <7695E2F6903F7A41961F8CF888D87EA8011AC2B0@red-msg-06.redmond.corp.microsoft.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: deprecated address handling for inbound TCP From: itojun@iijlab.net Date: Fri, 10 Nov 2000 15:44:55 +0900 Message-ID: <11421.973838695@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Why shouldn't an address be in the DNS? And how can you tell >> that an address, deprecated for your particular instance, has >> not been re-issued and is valid for some other system? >The usual reason for putting a node's address in the DNS is so that someone >else can look it up and use the address to contact the node. Deprecated >addresses are not supposed to be used for new communication. So it seems >counterproductive to put deprecated addresses in the DNS. i believe we need some guideline RFC for renumber operation. we have been analyzing renumbering scenario (we had a dedicated offsite meeting for renumber this week) and our current scenario for renumber is like this. we used router renumber protocol for testing:-) jinmei@kame did a heroic job during the test. the diagram was by sakane@kame. itojun old prefix ...======================================(7)==>(8) new prefix (1)===(2)======================================...> old AAAA/A6 ...---------------------------(5)-->(6) new AAAA/A6 (3)---(4)--------------------------...> (1) advertise the new prefix (2) confirm that the new prefix is operating stable enough (3) advertise new address onto DNS (4) confirm that the new prefix is advertised stable enough (5) remove DNS entries for old prefix (6) confirm that old DNS entries are gone (7) set preferred lifetime = 0 for old prefix (deprecated) (8) set valid lifetime = 0 for old prefix (addresses gone) we need to confirm that no traffic exists with old prefix, before terminating the old prefix. there's no trivial way. some of the events could be reordered or overwrapped, but you need to be careful doing that. for example, T6 can be after T7, but if you do that, you will invite connetion to deprecated address so it will be very pretty. timing invariants: if we set DNS entry TTL to T, and each event to Tn, T4 - T3 >= T T6 - T5 >= T -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 10 00:04:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAA82eP02836 for ipng-dist; Fri, 10 Nov 2000 00:02:40 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAA82Vj02829 for ; Fri, 10 Nov 2000 00:02:32 -0800 (PST) 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,v1.7) with ESMTP id AAA26840 for ; Fri, 10 Nov 2000 00:02:32 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.12.73.37]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA03389 for ; Fri, 10 Nov 2000 01:02:23 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id eAA7rPe02111; Fri, 10 Nov 2000 14:53:25 +0700 (ICT) From: Robert Elz To: Bill Manning cc: richdr@microsoft.com (Richard Draves), itojun@iijlab.net ('Jun-ichiro itojun Hagino'), ipng@sunroof.eng.sun.com Subject: Re: deprecated address handling for inbound TCP In-reply-to: Your message of "Thu, 09 Nov 2000 07:04:49 PST." <200011091504.HAA14458@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Nov 2000 14:53:25 +0700 Message-ID: <2109.973842805@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 9 Nov 2000 07:04:49 -0800 (PST) From: Bill Manning Message-ID: <200011091504.HAA14458@zed.isi.edu> | Why shouldn't an address be in the DNS? And how can you tell | that an address, deprecated for your particular instance, has | not been re-issued and is valid for some other system? Bill, you're attempting to be overly pedantic - you know that isn't what Rich meant, but in this case, you actually goofed as well... A deprecated address is still assigned, it can't be re-issued yet, rather it is in the last stages of its validity to its previous assignee - but not yet revoked. So, deprecated addresses shouldn't be in the DNS - the time line should be to receive notification of an address change, start populating new addresses through the affected systems, update the DNS for those systems as their new addresses become available so the new ones are used instead of the old ones, then once that is done, mark the old addresses as deprecated for however long is possible to allow existing connections to continue to work, then finally, remove support for them altogether. Once that has happened the addresses can be returned, and then re-issued to someone else (but by that stage, they're no longer deprecated). 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 Nov 10 02:32:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAAAVNx02904 for ipng-dist; Fri, 10 Nov 2000 02:31:23 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAAAVDj02897 for ; Fri, 10 Nov 2000 02:31:13 -0800 (PST) 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,v1.7) with ESMTP id CAA03518 for ; Fri, 10 Nov 2000 02:31:11 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.12.73.37]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03970 for ; Fri, 10 Nov 2000 02:31:08 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id eAAAOee02711; Fri, 10 Nov 2000 17:24:44 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: Richard Draves , Bill Manning , ipng@sunroof.eng.sun.com Subject: Re: deprecated address handling for inbound TCP In-reply-to: Your message of "Fri, 10 Nov 2000 15:44:55 +0900." <11421.973838695@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Nov 2000 17:24:40 +0700 Message-ID: <2709.973851880@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 10 Nov 2000 15:44:55 +0900 From: itojun@iijlab.net Message-ID: <11421.973838695@coconut.itojun.org> | i believe we need some guideline RFC for renumber operation. Yes, I have been threatening to write a draft on that for some time now, but haven't managed to find the time to do it... | we have been analyzing renumbering scenario (we had a dedicated | offsite meeting for renumber this week) and our current scenario for | renumber is like this. we used router renumber protocol for testing:-) | jinmei@kame did a heroic job during the test. the diagram was by | sakane@kame. You have included a bunch of (necessary) intermediate steps I dropped from my earlier message, but aside from that, your analysis is just about the same as what I have been thinking... 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 Nov 10 03:39:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAABbrX02936 for ipng-dist; Fri, 10 Nov 2000 03:37:53 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAABbij02929 for ; Fri, 10 Nov 2000 03:37:44 -0800 (PST) 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,v1.7) with ESMTP id DAA15839 for ; Fri, 10 Nov 2000 03:37:43 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA22611 for ; Fri, 10 Nov 2000 04:37:41 -0700 (MST) Received: from zed.isi.edu (root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA14288; Fri, 10 Nov 2000 03:37:27 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.9.3/8.8.6) id CAA01954; Fri, 10 Nov 2000 02:37:25 -0800 Message-Id: <200011101037.CAA01954@zed.isi.edu> Subject: Re: deprecated address handling for inbound TCP To: bzill@microsoft.com (Brian Zill) Date: Fri, 10 Nov 2000 02:37:25 -0800 (PST) Cc: bmanning@ISI.EDU ('Bill Manning'), ipng@sunroof.eng.sun.com In-Reply-To: from "Brian Zill" at Nov 09, 2000 09:09:15 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % % > Why shouldn't an address be in the DNS? % % In the renumbering scenario they were discussing, you'd switch your DNS % entries from the old address to the new address at the start of the % transition period. So the old (deprecated) address wouldn't be in the DNS. Switching the address should not require a DNS update. There are -lots- of DNS entries that exist although there is no active session for the pairing. DHCP pools for example. % > And how can you tell that an address, deprecated for your % > particular instance, has not been re-issued and is valid % > for some other system? % % Because the old prefix wouldn't be released back for reassignment until the % end of transition period. And how long is that transition period? In the case of a persistant TCP session, that could be a long time. --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 Nov 10 09:28:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAAHQIU03135 for ipng-dist; Fri, 10 Nov 2000 09:26:18 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAAHQ8j03128 for ; Fri, 10 Nov 2000 09:26:09 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA03025 for ; Fri, 10 Nov 2000 09:26:08 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14093 for ; Fri, 10 Nov 2000 09:26:06 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAAHPnb15831; Fri, 10 Nov 2000 18:25:49 +0100 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 SAA17252; Fri, 10 Nov 2000 18:25:47 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA61498; Fri, 10 Nov 2000 18:27:30 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011101727.SAA61498@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Charles E. Perkins" cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Cc: ipng@sunroof.eng.sun.com Subject: Re: [MOBILE-IP] Placement for Binding Update and Home Address options In-reply-to: Your message of Thu, 09 Nov 2000 10:14:35 PST. <3A0AE98B.46A6DD3E@iprg.nokia.com> Date: Fri, 10 Nov 2000 18:27:30 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Bottom line _proposal_: Mandatory placements: - Home Address option between Routing and Fragment Headers - Binding Update after ESP. => I agree, home address and tunnel encapsulation limit between routing and fragment, all other destination options (binding XXX) after ESP. Comments? => this makes three placements for a destination option header, two were already too many. The whole destination option header concept should be redone, for instance my proposal is: - kill the placement between hop-by-hop and routing headers (not used, just make implementations more complex) - keep the placement between routing and fragment headers for type 60 - get a new type from IANA for placement after ESP (IPCOMP in fact) This will give in the future simplest/cleanest implementations, the price is incompatibility for mobile IPv6 implementations (which should be incompatible in some cases with any proposal :-). Thanks Francis.Dupont@enst-bretagne.fr PS: I have added the IPng WG mailing list because this is in its scope. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 10 09:40:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAAHcTQ03154 for ipng-dist; Fri, 10 Nov 2000 09:38:29 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAAHcKj03147 for ; Fri, 10 Nov 2000 09:38:21 -0800 (PST) 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,v1.7) with ESMTP id JAA04031 for ; Fri, 10 Nov 2000 09:38:20 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21065 for ; Fri, 10 Nov 2000 09:38:10 -0800 (PST) Received: from zed.isi.edu (root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA20192; Fri, 10 Nov 2000 09:38:09 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.9.3/8.8.6) id IAA02304; Fri, 10 Nov 2000 08:38:07 -0800 Message-Id: <200011101638.IAA02304@zed.isi.edu> Subject: Re: deprecated address handling for inbound TCP To: kre@munnari.OZ.AU (Robert Elz) Date: Fri, 10 Nov 2000 08:38:07 -0800 (PST) Cc: bmanning@ISI.EDU (Bill Manning), richdr@microsoft.com (Richard Draves), itojun@iijlab.net ('Jun-ichiro itojun Hagino'), ipng@sunroof.eng.sun.com In-Reply-To: <2109.973842805@brandenburg.cs.mu.OZ.AU> from "Robert Elz" at Nov 10, 2000 02:53:25 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % From: Bill Manning % % | Why shouldn't an address be in the DNS? And how can you tell % | that an address, deprecated for your particular instance, has % | not been re-issued and is valid for some other system? % % Bill, you're attempting to be overly pedantic - you know that isn't % what Rich meant, but in this case, you actually goofed as well... % % A deprecated address is still assigned, it can't be re-issued yet, % rather it is in the last stages of its validity to its previous % assignee - but not yet revoked. % % So, deprecated addresses shouldn't be in the DNS - the time line should % be to receive notification of an address change, start populating new % addresses through the affected systems, update the DNS for those systems % as their new addresses become available so the new ones are used instead % of the old ones, then once that is done, mark the old addresses as deprecated % for however long is possible to allow existing connections to continue % to work, then finally, remove support for them altogether. Once that % has happened the addresses can be returned, and then re-issued to someone % else (but by that stage, they're no longer deprecated). % % kre Ok, I goofed. By what process are addresses marked as "deprecated for however long is possible to allow existing connections to continue to work, then finally, remove support for them altogether"? I still don't see why there is the strong requirement to tie an addresses validity to its instantiation in the DNS. --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 Nov 10 12:03:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAAK1Jv03333 for ipng-dist; Fri, 10 Nov 2000 12:01:19 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAAK1Aj03325 for ; Fri, 10 Nov 2000 12:01:10 -0800 (PST) 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,v1.7) with ESMTP id MAA06296 for ; Fri, 10 Nov 2000 12:01:09 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA27648 for ; Fri, 10 Nov 2000 12:01:08 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 10 Nov 2000 12:00:23 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Fri, 10 Nov 2000 12:01:07 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80130C8FD@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "'Bill Manning'" , kre@munnari.OZ.AU Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: RE: deprecated address handling for inbound TCP Date: Fri, 10 Nov 2000 12:00:53 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Ok, I goofed. By what process are addresses marked as > "deprecated > for however long is possible to allow existing connections > to continue to work, then finally, remove support for them > altogether"? I still don't see why there is the > strong requirement > to tie an addresses validity to its instantiation in the DNS. It's not a "strong" requirement. It's not a good idea and shouldn't be the normal mode of operation. If there is a deprecated address in the DNS, nothing major will break. (Unless someone implements itojun's proposal and fails incoming TCP connections to that address, but I think that's a bad idea.) 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 Fri Nov 10 14:56:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAAMsH903515 for ipng-dist; Fri, 10 Nov 2000 14:54:17 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAAMs6j03508 for ; Fri, 10 Nov 2000 14:54:06 -0800 (PST) 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,v1.7) with ESMTP id OAA04593 for ; Fri, 10 Nov 2000 14:54:06 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27134 for ; Fri, 10 Nov 2000 14:54:05 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id QAA16861; Fri, 10 Nov 2000 16:53:55 -0600 (CST) Message-Id: <200011102253.QAA16861@gungnir.fnal.gov> To: Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: deprecated address handling for inbound TCP In-reply-to: Your message of Thu, 09 Nov 2000 17:13:09 +0900. <20001109081309.587207E1D@starfruit.itojun.org> Date: Fri, 10 Nov 2000 16:53:55 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jinmei suggested that it may be better to send TCP RST with deprecated source, as it will help clients to try the next available address (on getaddrinfo chain, or something). i tend to agree. So do I, if you can somehow be confident that your old RRSET of addresses has propagated. (Or if you have preferred addresses that were already in the older RRSET.) That's quite a bit for the hosts to know, though. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 10 15:01:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAAN0Wn03538 for ipng-dist; Fri, 10 Nov 2000 15:00:32 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAAN0Lj03531 for ; Fri, 10 Nov 2000 15:00:21 -0800 (PST) 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,v1.7) with ESMTP id PAA25534 for ; Fri, 10 Nov 2000 15:00:21 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA25507 for ; Fri, 10 Nov 2000 16:00:18 -0700 (MST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id RAA16901; Fri, 10 Nov 2000 17:00:16 -0600 (CST) Message-Id: <200011102300.RAA16901@gungnir.fnal.gov> To: Bill Manning Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: deprecated address handling for inbound TCP In-reply-to: Your message of Thu, 09 Nov 2000 07:04:49 PST. <200011091504.HAA14458@zed.isi.edu> Date: Fri, 10 Nov 2000 17:00:16 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Why shouldn't an address be in the DNS? And how can you tell > that an address, deprecated for your particular instance, has > not been re-issued and is valid for some other system? If it's merely deprecated, that would be a grievous error. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 10 22:15:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAB6EKM04057 for ipng-dist; Fri, 10 Nov 2000 22:14:20 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAB6EAj04049 for ; Fri, 10 Nov 2000 22:14:10 -0800 (PST) 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,v1.7) with ESMTP id WAA27051 for ; Fri, 10 Nov 2000 22:14:09 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.12.73.37]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA03877 for ; Fri, 10 Nov 2000 23:14:00 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id eAB6DhN01570; Sat, 11 Nov 2000 13:13:45 +0700 (ICT) From: Robert Elz To: Bill Manning cc: richdr@microsoft.com (Richard Draves), itojun@iijlab.net ('Jun-ichiro itojun Hagino'), ipng@sunroof.eng.sun.com Subject: Re: deprecated address handling for inbound TCP In-reply-to: Your message of "Fri, 10 Nov 2000 08:38:07 PST." <200011101638.IAA02304@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 11 Nov 2000 13:13:43 +0700 Message-ID: <1568.973923223@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 10 Nov 2000 08:38:07 -0800 (PST) From: Bill Manning Message-ID: <200011101638.IAA02304@zed.isi.edu> | Ok, I goofed. By what process are addresses marked as "deprecated | for however long is possible to allow existing connections | to continue to work, then finally, remove support for them | altogether"? Currently this seems to be human intervention - ie: some person decides how long the transition period needs to be (and I know we have people on this list you believe the value should normally be "never less than several months" and others who would like "24 hours and this address is dead"). There's nothing different here than exists in IPv4 address transitions really - except better automated methods for getting the changes distributed around the local net, and a better formalism for allowing hosts to understand what is the current status of any particular address. The question that led to this little side discussion was related to the precise semantics of one of those states. On that question - would there be any support for adding some kind of deprecated timer (maybe distributed in RAs) - to allow a switch over point between when incoming connections to a deprecated address are still accepted, and when they start being reset ? 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 Nov 11 09:19:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eABHHg104315 for ipng-dist; Sat, 11 Nov 2000 09:17:42 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eABHHXj04308 for ; Sat, 11 Nov 2000 09:17:33 -0800 (PST) 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,v1.7) with ESMTP id JAA23141 for ; Sat, 11 Nov 2000 09:17:33 -0800 (PST) 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 KAA12415 for ; Sat, 11 Nov 2000 10:17:31 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA06639 for ; Sun, 12 Nov 2000 02:03:18 +0900 (JST) Date: Sat, 11 Nov 2000 21:48:29 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: default router selection based on network topology User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 52 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a question about how to configure "multi-router in a singe link" environments. Consider the following topology: segment1 | routerA routerB--->(backbone) | | +----segment2-----+ and assume that host in segment2 usually communicate with nodes in the backbone side, but sometimes communicate with hosts in segment1. In other words, routerB is the "primary" router for hosts in segment2. Now I have a question. Should routerA advertise RA messages on segment2? If A advertises RAs, it will have to issue many redirects, because traffic from hosts in segment2 usually go to the backbone (based on the assumption above). However, if A does not advertises RAs, communication between segment1 and segment2 would fail when routerB died. So, what should we do? 1. routerA should not advertise RAs on segment2. We should just give up communication between segment 1 and 2 if routerB dies. 2. routerA should advertise RAs. We should put up with redirects. 3. hosts in segment2 should participate in the routing protocol running on the segment to know the better router. Of course, the answer could depend on the precise situation (e.g. number of hosts in segment2, the ratio of traffic to the backbone, etc.) But if there has been a generic opinion on this, I'd like to know it. I also thought about a possibility to intorude a new RA option (e.g. containing a router's preference value) to tell the hosts the better router in the segment. Is this kind of approach worth considering? (I recalled a discussion on a new RA option that tells hosts the better router for particular prefixes around December 1998, and reread the discussion, but I'm not sure if it was exact the same issue.) Thanks, 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 Sun Nov 12 00:58:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAC8uTL04550 for ipng-dist; Sun, 12 Nov 2000 00:56:29 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAC8twj04543 for ; Sun, 12 Nov 2000 00:55:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA12316 for ; Sun, 12 Nov 2000 00:55:44 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.12.73.37]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19339 for ; Sun, 12 Nov 2000 00:55:38 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id eAC8uNq01898; Sun, 12 Nov 2000 15:56:26 +0700 (ICT) From: Robert Elz To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: default router selection based on network topology In-reply-to: Your message of "Sat, 11 Nov 2000 21:48:29 +0900." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 Nov 2000 15:56:23 +0700 Message-ID: <1896.974019383@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 11 Nov 2000 21:48:29 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Message-ID: | Now I have a question. Should routerA advertise RA messages on | segment2? Yes, without a doubt, this has always been a part of the IP model. Router preferences have been something of an issue over time - the difficulty being that it is very hard to assign a linear metric set to any more than 2 routers (and even to 2, not always) in general. 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 Nov 12 01:16:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAC9DqI04575 for ipng-dist; Sun, 12 Nov 2000 01:13:52 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAC9Dfj04568 for ; Sun, 12 Nov 2000 01:13:41 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA13210 for ; Sun, 12 Nov 2000 01:13:40 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA01254 for ; Sun, 12 Nov 2000 01:13:38 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id SAA07458; Sun, 12 Nov 2000 18:10:51 +0900 (JST) To: Robert Elz cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com In-reply-to: kre's message of Sun, 12 Nov 2000 15:56:23 +0700. <1896.974019383@brandenburg.cs.mu.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: default router selection based on network topology From: itojun@iijlab.net Date: Sun, 12 Nov 2000 18:10:50 +0900 Message-ID: <7456.974020250@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | Now I have a question. Should routerA advertise RA messages on > | segment2? >Yes, without a doubt, this has always been a part of the IP model. >Router preferences have been something of an issue over time - the >difficulty being that it is very hard to assign a linear metric >set to any more than 2 routers (and even to 2, not always) in general. from RFC2461 5.1 (conceptual data structures) I feel that the authors assumed that: - autoconfigured hosts are at the very edge of the site only - if we put a host onto a link with more than 2 routers, they will not automatically be configured, and do something tricky (like running routing daemon on hosts in receive-only mode). router | ==+=======+== <--- no autoconfigured hosts here | | router router | | ==+== ==+== | | host host but anyway, we need to talk about how the non-leaf case should be handled in terms of host autoconfiguration. even today, we see almost no use of DHCPv4 static route option (RFC2132 5.8) - we just autoconfigure default router(s) to DHCPv4 client, that's all. 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 Sun Nov 12 17:44:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAD1gmc04848 for ipng-dist; Sun, 12 Nov 2000 17:42:48 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAD1gcj04841 for ; Sun, 12 Nov 2000 17:42:39 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA03911 for ; Sun, 12 Nov 2000 17:42:36 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA18418 for ; Sun, 12 Nov 2000 17:42:35 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id KAA10655; Mon, 13 Nov 2000 10:28:25 +0900 (JST) Date: Mon, 13 Nov 2000 09:53:49 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: default router selection based on network topology In-Reply-To: In your message of "Sun, 12 Nov 2000 18:10:50 +0900" <7456.974020250@coconut.itojun.org> References: <1896.974019383@brandenburg.cs.mu.OZ.AU> <7456.974020250@coconut.itojun.org> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 29 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id eAD1gdj04842 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 12 Nov 2000 18:10:50 +0900, >>>>> itojun@iijlab.net said: >> | Now I have a question. Should routerA advertise RA messages on >> | segment2? >> Yes, without a doubt, this has always been a part of the IP model. >> Router preferences have been something of an issue over time - the >> difficulty being that it is very hard to assign a linear metric >> set to any more than 2 routers (and even to 2, not always) in general. > from RFC2461 5.1 (conceptual data structures) I feel that the authors > assumed that: > - autoconfigured hosts are at the very edge of the site only > - if we put a host onto a link with more than 2 routers, they will not > automatically be configured, and do something tricky (like running > routing daemon on hosts in receive-only mode). >From which part of RFC2461 do you think so? I don't see such assumptions in the RFC... By the way, the wording is a bit confusing here. In my understanding, RFC2461 itself does not handle "autoconfiguration". Did you mean the (auto) router discovery mechanism defined in the neighbor discovery spec? 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 Sun Nov 12 17:46:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAD1jKP04867 for ipng-dist; Sun, 12 Nov 2000 17:45:20 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAD1jAj04860 for ; Sun, 12 Nov 2000 17:45:10 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA04017 for ; Sun, 12 Nov 2000 17:45:10 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA19061 for ; Sun, 12 Nov 2000 17:45:09 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id KAA10652; Mon, 13 Nov 2000 10:28:24 +0900 (JST) Date: Mon, 13 Nov 2000 09:49:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: default router selection based on network topology In-Reply-To: In your message of "Sun, 12 Nov 2000 15:56:23 +0700" <1896.974019383@brandenburg.cs.mu.OZ.AU> References: <1896.974019383@brandenburg.cs.mu.OZ.AU> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 23 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 12 Nov 2000 15:56:23 +0700, >>>>> Robert Elz said: > | Now I have a question. Should routerA advertise RA messages on > | segment2? > Yes, without a doubt, this has always been a part of the IP model. Hmm, I see. Then we should just let the (leaf side) router advertise RAs, and use redirects if necessary. I think it's enough. > Router preferences have been something of an issue over time - the > difficulty being that it is very hard to assign a linear metric > set to any more than 2 routers (and even to 2, not always) in general. Okay, I basically agree with you. Thanks, 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 Sun Nov 12 18:14:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAD2CnY04897 for ipng-dist; Sun, 12 Nov 2000 18:12:49 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAD2Ccj04890 for ; Sun, 12 Nov 2000 18:12:38 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA15749 for ; Sun, 12 Nov 2000 18:12:34 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28526 for ; Sun, 12 Nov 2000 18:12:33 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id LAA14181; Mon, 13 Nov 2000 11:12:29 +0900 (JST) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com In-reply-to: jinmei's message of Mon, 13 Nov 2000 09:53:49 JST. 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: default router selection based on network topology From: itojun@iijlab.net Date: Mon, 13 Nov 2000 11:12:29 +0900 Message-ID: <14179.974081549@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> from RFC2461 5.1 (conceptual data structures) I feel that the authors >> assumed that: >> - autoconfigured hosts are at the very edge of the site only >> - if we put a host onto a link with more than 2 routers, they will not >> automatically be configured, and do something tricky (like running >> routing daemon on hosts in receive-only mode). >>From which part of RFC2461 do you think so? I don't see such >assumptions in the RFC... the conceptual data structure says that there's default router list and neighbor cache, not routing table. RFC2462 configures (routing- wise) default router only to the host. so, we end up having default route on host, no other routes. if we only have default route, it fits best if hosts are on leaf network. maybe i'm guessing too much. 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 Nov 13 09:34:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eADHWjU05309 for ipng-dist; Mon, 13 Nov 2000 09:32:45 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eADHWTj05294 for ; Mon, 13 Nov 2000 09:32:29 -0800 (PST) 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,v1.7) with ESMTP id JAA11911 for ; Mon, 13 Nov 2000 09:32:28 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA28396 for ; Mon, 13 Nov 2000 10:32:27 -0700 (MST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 13 Nov 2000 09:31:40 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Mon, 13 Nov 2000 09:32:25 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9BB3@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "'JINMEI Tatuya / ????'" Cc: ipng@sunroof.eng.sun.com, Balash Akbari Subject: RE: default router selection based on network topology Date: Mon, 13 Nov 2000 09:31:47 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Consider the following topology: > > segment1 > | > routerA routerB--->(backbone) > | | > +----segment2-----+ > > and assume that host in segment2 usually communicate with nodes in the > backbone side, but sometimes communicate with hosts in segment1. In > other words, routerB is the "primary" router for hosts in segment2. > > Now I have a question. Should routerA advertise RA messages on > segment2? Balash and I will be submitting a draft on default router preferences. Two of the key challenges have already been noted: what kind of metric should be used and how are the values determined? What happens to the conceptual host model? I think we have good answers :-). But I'd prefer to avoid a big discussion until we actually have the draft finished, since the deadline is looming. 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 Nov 13 09:35:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eADHWmG05310 for ipng-dist; Mon, 13 Nov 2000 09:32:48 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eADHWUj05298 for ; Mon, 13 Nov 2000 09:32:31 -0800 (PST) Received: from lillen (gbl-dhcp-174-237.France.Sun.COM [129.157.174.237]) by jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id eADHWT6596996; Mon, 13 Nov 2000 09:32:29 -0800 (PST) Date: Mon, 13 Nov 2000 09:32:13 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: deprecated address handling for inbound TCP To: Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20001109081309.587207E1D@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > jinmei suggested that it may be better to send TCP RST with deprecated > source, as it will help clients to try the next available address > (on getaddrinfo chain, or something). i tend to agree. I think this is bad since there might be old AAAA/A6 record sets cached (due to their DNS ttl not having expired yet) that only include the old, now deprecated, address. Imagine a DNS ttl of 1 hour. T = 0: Configure new prefixes using router renumbering. Initially as deprecated. T = 5 minutes. Test new address (and old) can be reached i.e. routing works. T = 6 minutes. Update DNS to have only new addresses. T = 7 minutes. Use router renumbering to mark new address as preferred and old addresses as deprecated. T >> 1 hour 6 minutes. (Actual number depends on how long lived TCP connections and other sessions you'd like to handle. But at least the DNS ttl). Time to remove the old address using router renumbering i.e. make routing of old addresses no longer work. I don't think you want an outtage of 59 minutes in this case. 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 Nov 13 09:41:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eADHeVb05345 for ipng-dist; Mon, 13 Nov 2000 09:40:31 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eADHeKj05338 for ; Mon, 13 Nov 2000 09:40:20 -0800 (PST) Received: from lillen (gbl-dhcp-174-237.France.Sun.COM [129.157.174.237]) by jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id eADHeH6598018; Mon, 13 Nov 2000 09:40:17 -0800 (PST) Date: Mon, 13 Nov 2000 09:40:05 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: draft-ietf-ipngwg-rfc2292bis-02.txt To: Markku Savela Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <000101c04a3f$167b5370$e82815ac@hews0169nrc.research.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > However, EPOC Socket API does not have recvmsg equivalent, and I still have > the problem I presented with whatever solution I invent (ioctl?) for > retrieving the packet data. But, that will be local issue of no generic > insterest. I think inventing a mechanism which delivers ancillary data (or the equivalent thereof) together with the data is the best way to go. A getsockopt() would need to somehow indicate which packet you want the ancillary data for. Otherwise, things would be confusing e.g. in this case t=0 packet 1 from A with routing header X arrives. Queued in the socket queue. t=1 packet 2 from B with routing header Y arrives. Queued in the socket queue. t=10 application calls recv() to get data t=11 application calls getsockopt to get ancillary data (routing header) Does this retrive X or Y? t=100 application calls recv() to get data t=101 packet 3 from C with routing header Z arrives. Queued in the socket queue. t=101 application calls getsockopt to get ancillary data (routing header) Does this retrive Z? Does the getsockopt retrieve from the most recently received packet? Note that the socket API had the above problem for IPv4 using getsockopt(IP_OPTIONS) to retrieve information from UDP/IP. This was fixed by assing IP_RECVOPTS which is delivered using ancillary data. 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 Nov 13 09:47:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eADHk7605378 for ipng-dist; Mon, 13 Nov 2000 09:46:07 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eADHjuj05371 for ; Mon, 13 Nov 2000 09:45:56 -0800 (PST) Received: from lillen (gbl-dhcp-174-237.France.Sun.COM [129.157.174.237]) by jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id eADHjn6598968; Mon, 13 Nov 2000 09:45:50 -0800 (PST) Date: Mon, 13 Nov 2000 09:45:35 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: default router selection based on network topology To: itojun@iijlab.net Cc: Robert Elz , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <7456.974020250@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 > from RFC2461 5.1 (conceptual data structures) I feel that the authors > assumed that: > - autoconfigured hosts are at the very edge of the site only > - if we put a host onto a link with more than 2 routers, they will not > automatically be configured, and do something tricky (like running > routing daemon on hosts in receive-only mode). Why doesn't advertising all 3 routers (without any preferences) plus redirects solve this problem? Erik > router > | > ==+=======+== <--- no autoconfigured hosts here > | | > router router > | | > ==+== ==+== > | | > host host > > but anyway, we need to talk about how the non-leaf case should be > handled in terms of host autoconfiguration. even today, we see almost > no use of DHCPv4 static route option (RFC2132 5.8) - we just > autoconfigure default router(s) to DHCPv4 client, that's all. > > 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 Nov 13 12:29:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eADKSAR05569 for ipng-dist; Mon, 13 Nov 2000 12:28:10 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eADKRxj05562 for ; Mon, 13 Nov 2000 12:27:59 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA12265; Mon, 13 Nov 2000 12:27:57 -0800 (PST) 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 NAA03305; Mon, 13 Nov 2000 13:27:55 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id FAA02537; Tue, 14 Nov 2000 05:27:49 +0900 (JST) To: Erik Nordmark cc: ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Mon, 13 Nov 2000 09:32:13 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: deprecated address handling for inbound TCP From: itojun@iijlab.net Date: Tue, 14 Nov 2000 05:27:49 +0900 Message-ID: <2535.974147269@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> jinmei suggested that it may be better to send TCP RST with deprecated >> source, as it will help clients to try the next available address >> (on getaddrinfo chain, or something). i tend to agree. >I think this is bad since there might be old AAAA/A6 record sets cached >(due to their DNS ttl not having expired yet) that only include the >old, now deprecated, address. >Imagine a DNS ttl of 1 hour. >T = 0: Configure new prefixes using router renumbering. Initially as >deprecated. T = 5 minutes. Test new address (and old) can be reached i.e. >routing works. T = 6 minutes. Update DNS to have only new addresses. >T = 7 minutes. Use router renumbering to mark new address as preferred and old > addresses as deprecated. >T >> 1 hour 6 minutes. (Actual number depends on how long lived TCP >connections > and other sessions you'd like to handle. But at least the DNS ttl). > Time to remove the old address using router renumbering i.e. make > routing of old addresses no longer work. >I don't think you want an outtage of 59 minutes in this case. well, the above scenario looks too aggressive to me. the invariants we would like to keep are: - advertise address by DNS, only after addresses are ready - mark addresses deprecated, only after we remove them DNS and we wait till DNS TTL has passed so, the scenario will be as follows: time unit = minutes. T=0 add a new prefix. T=5 test new prefix and confirm that it is working okay. T=10 advertise address on new prefix (and old prefix) via DNS T=70 confirm that we now have clicks to www.erik.net T=75 remove addresses on old prefix from DNS T=135 mark old address deprecated (pltime = 0). T=140 confirm that there's no new connectivity to old address coming, terminate contract with old ISP. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 13 12:32:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eADKVIL05588 for ipng-dist; Mon, 13 Nov 2000 12:31:18 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eADKV8j05581 for ; Mon, 13 Nov 2000 12:31:08 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA05691; Mon, 13 Nov 2000 12:31:06 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00062; Mon, 13 Nov 2000 12:31:04 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id FAA02618; Tue, 14 Nov 2000 05:30:58 +0900 (JST) To: Erik Nordmark cc: Robert Elz , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Mon, 13 Nov 2000 09:45:35 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: default router selection based on network topology From: itojun@iijlab.net Date: Tue, 14 Nov 2000 05:30:58 +0900 Message-ID: <2616.974147458@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> from RFC2461 5.1 (conceptual data structures) I feel that the authors >> assumed that: >> - autoconfigured hosts are at the very edge of the site only >> - if we put a host onto a link with more than 2 routers, they will not >> automatically be configured, and do something tricky (like running >> routing daemon on hosts in receive-only mode). >Why doesn't advertising all 3 routers (without any preferences) plus >redirects solve this problem? if you pick a wrong router (like one of two downstream router) as the default and stick to that one, i'm afraid you will see so many redirects. if redirect traffic are okay for you, i have no objection with your plan. 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 Nov 13 17:39:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAE1cAO06039 for ipng-dist; Mon, 13 Nov 2000 17:38:10 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAE1brj06031 for ; Mon, 13 Nov 2000 17:37:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA17085 for ; Mon, 13 Nov 2000 17:37:54 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA05357 for ; Mon, 13 Nov 2000 17:37:52 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id KAA21463; Tue, 14 Nov 2000 10:23:38 +0900 (JST) Date: Tue, 14 Nov 2000 10:06:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: default router selection based on network topology In-Reply-To: In your message of "Mon, 13 Nov 2000 11:12:29 +0900" <14179.974081549@coconut.itojun.org> References: <14179.974081549@coconut.itojun.org> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 13 Nov 2000 11:12:29 +0900, >>>>> itojun@iijlab.net said: >>> from RFC2461 5.1 (conceptual data structures) I feel that the authors >>> assumed that: >>> - autoconfigured hosts are at the very edge of the site only >>> - if we put a host onto a link with more than 2 routers, they will not >>> automatically be configured, and do something tricky (like running >>> routing daemon on hosts in receive-only mode). >>> From which part of RFC2461 do you think so? I don't see such >> assumptions in the RFC... > the conceptual data structure says that there's default router list > and neighbor cache, not routing table. Destination cache is also contained in the conceptual data structures. I think it is a host version of routing table. > RFC2462 configures (routing- ^^^^^^^??? You mean 2461? > wise) default router only to the host. so, we end up having > default route on host, no other routes. Except per-destination routes in Destation Cache. > if we only have default route, > it fits best if hosts are on leaf network. I can't understand the conclusion. I think there is a logical leap... 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 Nov 13 17:39:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAE1buQ06032 for ipng-dist; Mon, 13 Nov 2000 17:37:56 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAE1blj06023 for ; Mon, 13 Nov 2000 17:37:47 -0800 (PST) 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,v1.7) with ESMTP id RAA17063 for ; Mon, 13 Nov 2000 17:37:47 -0800 (PST) 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 SAA09579 for ; Mon, 13 Nov 2000 18:37:45 -0700 (MST) Received: from localhost ([3ffe:501:4819:2000:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id KAA21466 for ; Tue, 14 Nov 2000 10:23:40 +0900 (JST) Date: Tue, 14 Nov 2000 10:18:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: IPV6_USEMTU socket option User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 19 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I'm now considering UDP applications that are sensitive to path MTU (toward the destinations). I recalled a discussion about a new socket option "IPV6_USEMTU", which allowed an application to specify an appropriate path MTU for packets sent from the application. I checked the archive of this list in April 2000, and, to my suprise, the discussion suddenly disappeared without any consensus. I think it is a good idea, and even essential for such UDP applications. What was wrong with the option? Or can we raise the option again as a clarification for rfc2292bis? Thanks, 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 Nov 13 21:52:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAE5p3v06195 for ipng-dist; Mon, 13 Nov 2000 21:51:03 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAE5osj06188 for ; Mon, 13 Nov 2000 21:50:54 -0800 (PST) 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,v1.7) with ESMTP id VAA05179; Mon, 13 Nov 2000 21:50:51 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.12.73.37]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA26709; Mon, 13 Nov 2000 22:50:36 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id eAE5oRq01859; Tue, 14 Nov 2000 12:50:41 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: Erik Nordmark , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: default router selection based on network topology In-reply-to: Your message of "Tue, 14 Nov 2000 05:30:58 +0900." <2616.974147458@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Nov 2000 12:50:27 +0700 Message-ID: <1857.974181027@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 14 Nov 2000 05:30:58 +0900 From: itojun@iijlab.net Message-ID: <2616.974147458@coconut.itojun.org> | if you pick a wrong router (like one of two downstream router) | as the default and stick to that one, i'm afraid you will see so many | redirects. You should only see many, in comparison with the traffic volume to the destination, if the traffic volume is very low. In that case, who cares? For what it is worth, the case you brought up is the easy one, that redirect handles just fine. The difficult case is... --- ppp link to the world --- world router | ||| | ||| GB (or ATM or similar) | ||| link to the world | ||| router-1 router-2 || || =========== local ethernet ============ | host In that case, rather than getting a redirect when host picks router-1 to send to the world, the packet instead goes out over the wet string instead of over the fibre (at least, that's often the way things will work). This is where some kind of router preference is needed - and it will be interesting to see what Rich Draves (et al) come up with that will solve this. If they can also cope with ... --- ppp link to the world --- world router | ||| | ||| GB (or ATM or similar) | ||| link to the world | ||| === router-1 router-2 --- ||| || || | ||| =========== local ethernet ============ | ||| | | ||| host | ||| | ||| | router-3 --------------------------------------------- || || (to internal intranet, or similar) where router-1 is the best path for host to use to get to router-3, but router-2 is the best past to use to get to the world (and then generalise this to more routers and destinations) without turning the router preferences into buried routing protocol by stealth, then I shall truly be impressed. And Rich - no need to reply, I will await the 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 Tue Nov 14 00:42:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAE8f9L06250 for ipng-dist; Tue, 14 Nov 2000 00:41:09 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAE8f0j06243 for ; Tue, 14 Nov 2000 00:41:00 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA28936 for ; Tue, 14 Nov 2000 00:41:00 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26744 for ; Tue, 14 Nov 2000 00:40:59 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAE8eHb34439; Tue, 14 Nov 2000 09:40:17 +0100 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 JAA29511; Tue, 14 Nov 2000 09:40:16 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id JAA77413; Tue, 14 Nov 2000 09:42:19 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011140842.JAA77413@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option In-reply-to: Your message of Tue, 14 Nov 2000 10:18:30 +0900. Date: Tue, 14 Nov 2000 09:42:19 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I'm now considering UDP applications that are sensitive to path MTU (toward the destinations). I recalled a discussion about a new socket option "IPV6_USEMTU", which allowed an application to specify an appropriate path MTU for packets sent from the application. I checked the archive of this list in April 2000, and, to my suprise, the discussion suddenly disappeared without any consensus. => today only IPV6_USE_MIN_MTU seems to be defined, implemented and used (for instance by BIND and racoon, the KAME IKE daemon). I don't know if IPV6_USEMTU as you define is very useful but the getsockopt() counterpart (which gives the actual path MTU) *is* useful. Perhaps the getsockopt() with a standard way to disable fragmentation is enough (it should be enough for a traceroute_pmtu6)? 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 Nov 14 01:40:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAE9chJ06335 for ipng-dist; Tue, 14 Nov 2000 01:38:43 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAE9cWj06328 for ; Tue, 14 Nov 2000 01:38:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA27175 for ; Tue, 14 Nov 2000 01:38:31 -0800 (PST) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA02273 for ; Tue, 14 Nov 2000 01:38:27 -0800 (PST) Received: from godel.logique.jussieu.fr (root@godel.logique.jussieu.fr [134.157.19.1]) by shiva.jussieu.fr (8.10.0/jtpda-5.3.3) with ESMTP id eAE9cHt33968 ; Tue, 14 Nov 2000 10:38:17 +0100 (CET) Received: from bernays.logique.jussieu.fr (bernays.logique.jussieu.fr [134.157.19.71]) by godel.logique.jussieu.fr (8.9.3/jtpda-5.3.1) with ESMTP id KAA15573 ; Tue, 14 Nov 2000 10:37:59 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200011140842.JAA77413@givry.rennes.enst-bretagne.fr> Date: Tue, 14 Nov 2000 10:43:32 +0100 (CET) From: Yves Legrandgerard To: Francis Dupont Subject: Re: IPV6_USEMTU socket option Cc: ipng@sunroof.eng.sun.com Cc: ipng@sunroof.eng.sun.com, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 14-Nov-00 Francis Dupont wrote: > In your previous mail you wrote: > > I'm now considering UDP applications that are sensitive to path MTU > (toward the destinations). I recalled a discussion about a new socket > option "IPV6_USEMTU", which allowed an application to specify an > appropriate path MTU for packets sent from the application. I checked > the archive of this list in April 2000, and, to my suprise, the > discussion suddenly disappeared without any consensus. > > => today only IPV6_USE_MIN_MTU seems to be defined, implemented and > used (for instance by BIND and racoon, the KAME IKE daemon). > I don't know if IPV6_USEMTU as you define is very useful but the > getsockopt() counterpart (which gives the actual path MTU) *is* useful. > Perhaps the getsockopt() with a standard way to disable fragmentation > is enough (it should be enough for a traceroute_pmtu6)? > I agree, we need two things: 1) a new option for getsockopt() to get the actual path MTU (there is no standard way to do that). 2) a new option for setsockopt() to disable fragmentation (until now, to do that, we have to use non standard option like: IP_HDRINCL). These two new options would be sufficient to code "traceroute_pmtu6" (in fact, only one of them is necessary: 1) or 2)) Best regards, ---------------------------------- Yves Legrandgérard E-Mail: ylg@logique.jussieu.fr Date: 14-Nov-00 Time: 10:18:20 ---------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 14 03:40:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAEBcrS06413 for ipng-dist; Tue, 14 Nov 2000 03:38:53 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAEBcij06406 for ; Tue, 14 Nov 2000 03:38:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA05770 for ; Tue, 14 Nov 2000 03:38:42 -0800 (PST) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA05076 for ; Tue, 14 Nov 2000 03:38:42 -0800 (PST) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id GAA03374; Tue, 14 Nov 2000 06:37:45 -0500 Message-Id: <200011141137.GAA03374@hygro.adsl.duke.edu> To: itojun@iijlab.net cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: default router selection based on network topology In-Reply-To: Message from itojun@iijlab.net of "Mon, 13 Nov 2000 11:12:29 +0900." <14179.974081549@coconut.itojun.org> Date: Tue, 14 Nov 2000 06:37:45 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > the conceptual data structure says that there's default router list > and neighbor cache, not routing table. The destination cache is essentially a routing table. Rather than getting built up from routing updates recieved via routing protocols, it is built up on demand by: 1) when communication with a destination first starts. If no destination cache entry for that destination exists, it gets created. Later, should a redirect for that destination arrives, it updates that entry. 2) the default router list is exactly that. A list of default routers one can pick a router from to use in those cases where one doesn't already have a working router in the destination cache. > from RFC2461 5.1 (conceptual data structures) I feel that the authors > assumed that: > - autoconfigured hosts are at the very edge of the site only No such assumption was made by this author. > - if we put a host onto a link with more than 2 routers, they will not > automatically be configured, and do something tricky (like running > routing daemon on hosts in receive-only mode). Not at all. They can configure themselves just as if they are on a leaf network. Redirects correct the situation where the "wrong" router is chosen for a particular destination. 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 Nov 14 09:42:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAEHSQu06611 for ipng-dist; Tue, 14 Nov 2000 09:28:26 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAEHSHj06604 for ; Tue, 14 Nov 2000 09:28:18 -0800 (PST) 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,v1.7) with ESMTP id JAA28088 for ; Tue, 14 Nov 2000 09:28:15 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA06713 for ; Tue, 14 Nov 2000 10:28:14 -0700 (MST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 14 Nov 2000 09:27:25 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Tue, 14 Nov 2000 09:25:11 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9BBD@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "IPng List (E-mail)" Subject: APIs for controlling source address selection Date: Tue, 14 Nov 2000 09:24:55 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk draft-ietf-ipngwg-default-addr-select raises the possibility of per-socket control over the mobility & privacy aspects of source address selection, for those applications that aren't happy with their implementation's default behavior. For example: web browser on mobile node wants to use care-of addresses for its transient HTTP connections. For example: distributed internet game wants to use public addresses for its sockets, so other players can do a getpeername() and get a permanent address for the peer. I would like to sketch out some possibilities. I think this should go into rfc2553bis. I have two possible designs for your consideration: A (simple) and B (more complex). Design A: There are two new socket options at the IPPROTO_IPV6 level. You can get/set both of them. IPV6_PREFER_CAREOF_ADDRESS Takes an int value. Boolean option - values are 0 & 1. The default value is 0, meaning source address selection prefers home addresses. If set to 1, then source address selection prefers care-of addresses. With either setting, if you have an address that is both a home address and a care-of address (you are at one of our home network locations), then it is preferred over other addresses. IPV6_PREFER_PUBLIC_ADDRESS Takes an int value. Boolean option - values are 0 & 1. The default value is 0, meaning source address selection prefers anonymous addresses. If set to 1, then source address selection prefers public addresses. Either way, note that this is a low-priority preference. For example, choosing an appropriately scoped address, and avoiding deprecated addresses, is more important. Pros: Simple Cons: Need two system calls to change both settings. Can't express some application requirements, like "must use an anonymous address" or "generate a new anonymous address just for this socket". But are those reasonable things to support? Design B: There is one new socket option at the IPPROTO_IPV6 level. You can get/set the option. IPV6_SOURCE_ADDRESS_SELECTION Takes an unsigned int value, which is an OR combination of two values, one value controls mobility and the other value controls privacy: IPV6_PREFER_CAREOF_ADDRESS 0x10 IPV6_PREFER_HOME_ADDRESS 0x00 the default is IPV6_PREFER_HOME_ADDRESS. Semantics as above. IPV6_PREFER_PUBLIC_ADDRESS 0x01 IPV6_PREFER_ANONYMOUS_ADDRESS 0x00 IPV6_MUST_HAVE_ANONYMOUS_ADDRESS 0x02 IPV6_CREATE_NEW_ANONYMOUS_ADDRESS 0x03 the default is IPV6_PREFER_ANONYMOUS_ADDRESS. The value IPV6_MUST_HAVE_ANONYMOUS_ADDRESS means that if the stack's default rules would pick a global public address, the connect() (or whatever) call should instead fail. If the stack picks a link-local or site-local scoped source address (which is not anonymous), then that's OK. For example, if an administrator has disable anonymous addresses on the machine, and the app uses IPV6_MUST_HAVE_ANONYMOUS_ADDRESS, then the app will get an error when trying to connect() to a global address. Whereas if the app uses IPV6_PREFER_ANONYMOUS_ADDRESS, it will not get an error from the connect(). The value IPV6_CREATE_NEW_ANONYMOUS_ADDRESS means that the if the stack's default rules pick a global scope address, then the stack should use the /64 prefix to generate a new anonymous source address. This new anonymous source address will be chosen for other sockets (unless explicitly specified with bind()). This option forces the stack to generate a new anonymous address for each socket, for the truly paranoid. Pros: Gives the app more flexibility. Cons: Gives the app more rope. Lets the app change both settings with one system call. More code to implement (particularly IPV6_CREATE_NEW_ANONYMOUS_ADDRESS). What do you think? Thanks, 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 Tue Nov 14 21:12:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAF5AgD07417 for ipng-dist; Tue, 14 Nov 2000 21:10:42 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAF5AWj07410 for ; Tue, 14 Nov 2000 21:10:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA14533 for ; Tue, 14 Nov 2000 21:10:31 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA09425 for ; Tue, 14 Nov 2000 21:10:31 -0800 (PST) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 14 Nov 2000 21:10:30 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Tue, 14 Nov 2000 21:10:30 -0800 Message-ID: From: Brian Zill To: ipng@sunroof.eng.sun.com Subject: Mutable fields and the Hop-by-Hop and Destination Options headers Date: Tue, 14 Nov 2000 21:10:22 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, got a question about mutable options. As described in RFC 2460, Option Type identifiers have an encoded bit (aka the mutable option bit) indicating "whether or not the Option Data of that option can change en-route to the packet's final destination". This allows new IPv6 options to be defined with contents that may be changed by either routers or intermediate destinations along the way to the final destination, without breaking IPsec authentication. RFC 2460 also specifies the recommended Extension Header Order as: IPv6|HbH|DO1|RH|FH|AH|ESP|DO2|TCP/UDP/etc where DO1 is "for options to be processed by the first destination that appears in the IPv6 Destination Address field plus subsequent destinations listed in the Routing header", and DO2 is "for options to be processed only by the final destination of the packet". The exact order is only a recommendation, but the distinction between Destination Options headers that appear before the Routing Header versus those that appear after it is the important part here. >From the above, one could reasonably conclude that mutable options should only appear in Hop-by-Hop and Destination Options 1, and not in Destination Options 2. Options that appear in DO2 have no need to be mutable since this header is never examined until after the packet has arrived at the final destination. And in fact, if they were mutable and mutated in-flight, they would break things like ESP in null-encryption authentication-only mode. Unfortunately, this requirement that mutable options not appear after the Routing Header is not explicitly stated in the spec anywhere. And it matters for how one calculates the ICV when processing AH headers (since the calculation treats mutable options as zeroed fields in all cases). If one allows mutable options to appear anywhere, then the AH ICV calculation needs to parse past the AH header through to the end of the packet, instead of being able to treat everything inside of the AH header as an opaque blob. This would needlessly complicate the AH ICV calculation for no practical reason. Therefore, I'd like to propose that the spec is clarified to limit mutable options to where they make sense, i.e. in Hop-by-Hop and Destination Options headers that appear before the Routing Header. Comments? Thanks, --Brian P.S. As an aside, it occurs to me that it might be clearer to define a new "Intermediate Destination Options" header to take the place of DO1. Then it could be declared that this new header (if present) MUST appear before the Routing Header, and that mutable options (if present) MUST appear in either this new header or a Hop-by-Hop header. Or to put it another way, mutable options wouldn't be allowed any more in a Destination Options header. This would also make the spec cleaner - it could get rid of the special case notations explaining the difference between DO1 and DO2. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 14 21:42:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAF5fRn07467 for ipng-dist; Tue, 14 Nov 2000 21:41:27 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAF5fIj07460 for ; Tue, 14 Nov 2000 21:41:18 -0800 (PST) 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,v1.7) with ESMTP id VAA06667 for ; Tue, 14 Nov 2000 21:41:17 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA16709 for ; Tue, 14 Nov 2000 22:41:17 -0700 (MST) Received: from [10.19.130.190] (deering-dsl5.cisco.com [10.19.130.190]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA22052; Tue, 14 Nov 2000 21:41:15 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: References: Date: Tue, 14 Nov 2000 21:40:38 -0800 To: Brian Zill From: Steve Deering Subject: Re: Mutable fields and the Hop-by-Hop and Destination Options headers Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:10 PM -0800 11/14/00, Brian Zill wrote: >Therefore, I'd like to propose that the spec is clarified to limit mutable >options to where they make sense, i.e. in Hop-by-Hop and Destination Options >headers that appear before the Routing Header. Alternatively, we could specify that any mutable options that appear after the AH header are treated as if they were immutable, i.e., included in the authentication computation. Such options, though mutable, would not undergo mutation, so could safely be treated as immutable by AH. >P.S. As an aside, it occurs to me that it might be clearer to define a new >"Intermediate Destination Options" header to take the place of DO1. Then it >could be declared that this new header (if present) MUST appear before the >Routing Header, and that mutable options (if present) MUST appear in either >this new header or a Hop-by-Hop header. Or to put it another way, mutable >options wouldn't be allowed any more in a Destination Options header. This >would also make the spec cleaner - it could get rid of the special case >notations explaining the difference between DO1 and DO2. Sounds reasonable, but seems to me like a significant change for a small benefit at this point. 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 Wed Nov 15 00:40:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAF8dSI07598 for ipng-dist; Wed, 15 Nov 2000 00:39:28 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAF8dJj07591 for ; Wed, 15 Nov 2000 00:39:19 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA02908 for ; Wed, 15 Nov 2000 00:39:20 -0800 (PST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22339 for ; Wed, 15 Nov 2000 00:39:19 -0800 (PST) Received: from esebh12nok.ntc.nokia.com (esebh12nok.ntc.nokia.com [131.228.10.109]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id eAF8dIP28509 for ; Wed, 15 Nov 2000 10:39:18 +0200 (EET) Received: from loki.research.nokia.com ([172.21.33.76]) by esebh12nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id WZXCYR1L; Wed, 15 Nov 2000 10:39:18 +0200 Received: from hews0169nrc (hed040-232.research.nokia.com [172.21.40.232]) by loki.research.nokia.com (8.9.3/8.9.3) with SMTP id KAA10871 for ; Wed, 15 Nov 2000 10:39:18 +0200 (EET) X-Authentication-Warning: loki.research.nokia.com: Host hed040-232.research.nokia.com [172.21.40.232] claimed to be hews0169nrc From: "Markku Savela" To: Subject: RE: Mutable fields and the Hop-by-Hop and Destination Options headers Date: Wed, 15 Nov 2000 10:39:15 +0200 Message-ID: <000001c04edf$8a617450$e82815ac@hews0169nrc.research.nokia.com> 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 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: EXT Steve Deering > Alternatively, we could specify that any mutable options that appear > after the AH header are treated as if they were immutable, i.e., > included in the authentication computation. Such options, > though mutable, > would not undergo mutation, so could safely be treated as > immutable by AH. At least I definitely prefer this approach (this is the way I have it implemented). AH (nor any other extension header) should not care what follows after it, it's just payload at that stage. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 01:02:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAF90BD07626 for ipng-dist; Wed, 15 Nov 2000 01:00:11 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAF901j07619 for ; Wed, 15 Nov 2000 01:00:02 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA21422 for ; Wed, 15 Nov 2000 01:00:02 -0800 (PST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27182 for ; Wed, 15 Nov 2000 01:00:01 -0800 (PST) Received: from esebh11nok.ntc.nokia.com (esebh11nok.ntc.nokia.com [131.228.10.108]) by mgw-x3.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id eAF8xvB11891 for ; Wed, 15 Nov 2000 10:59:57 +0200 (EET) Received: from loki.research.nokia.com ([172.21.33.76]) by esebh11nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id W6QDS8Y4; Wed, 15 Nov 2000 10:59:57 +0200 Received: from hews0169nrc (hed040-232.research.nokia.com [172.21.40.232]) by loki.research.nokia.com (8.9.3/8.9.3) with SMTP id KAA11043 for ; Wed, 15 Nov 2000 10:59:57 +0200 (EET) X-Authentication-Warning: loki.research.nokia.com: Host hed040-232.research.nokia.com [172.21.40.232] claimed to be hews0169nrc From: "Markku Savela" To: "IPng List (E-mail)" Subject: RE: APIs for controlling source address selection Date: Wed, 15 Nov 2000 10:59:55 +0200 Message-ID: <000101c04ee2$6ceb4fb0$e82815ac@hews0169nrc.research.nokia.com> 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 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA81C9BBD@red-msg-06.redmond.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: EXT Richard Draves > > I have two possible designs for your consideration: A > (simple) and B (more complex). Either one is probably easy to implement and use. I'm just wondering whether this type thing is the right direction to go with the API? It requires each application to include a user controllable method for choosing these settings. In case of web browser, it's not just the case of choosing of care address/home address for all connections. The actual need is could be to use either care or home depending on which server one is using. We already have a selector mechanism for IPSEC. It does occur to me that this selector part could be a separate component, and IPSEC just one user of it. Another use of the selectors would be to define which connections use home address and which are okay with care address. Similarly, there are probably many other things that one could control through the selectors (quality of service paramaters?). Should we describe an API section that controls some kind of selector mechanism, which would for example implicitly "fire" the specified socket options for the connections that match? Let applications just do their own stuff, and set control paramaters externally. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 01:22:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAF9JWI07686 for ipng-dist; Wed, 15 Nov 2000 01:19:32 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAF9JBj07674 for ; Wed, 15 Nov 2000 01:19:12 -0800 (PST) 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,v1.7) with ESMTP id BAA05917 for ; Wed, 15 Nov 2000 01:19:10 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA06260 for ; Wed, 15 Nov 2000 02:19:09 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAF9Iwb35861; Wed, 15 Nov 2000 10:18:58 +0100 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 KAA17914; Wed, 15 Nov 2000 10:18:58 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA83474; Wed, 15 Nov 2000 10:21:06 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011150921.KAA83474@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Zill cc: ipng@sunroof.eng.sun.com Subject: Re: Mutable fields and the Hop-by-Hop and Destination Options headers In-reply-to: Your message of Tue, 14 Nov 2000 21:10:22 PST. Date: Wed, 15 Nov 2000 10:21:06 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: As described in RFC 2460, Option Type identifiers have an encoded bit (aka the mutable option bit) indicating "whether or not the Option Data of that option can change en-route to the packet's final destination". This allows new IPv6 options to be defined with contents that may be changed by either routers or intermediate destinations along the way to the final destination, without breaking IPsec authentication. => yes but this bit is not used today (this is not a proposal to remove it, I believe it is a very useful feature). RFC 2460 also specifies the recommended Extension Header Order as: IPv6|HbH|DO1|RH|FH|AH|ESP|DO2|TCP/UDP/etc => this recommendation has three problems: - DO1 makes sense only when there is a routing header. This is not clear enough! - an IPComp (RFC 2393) header should be between ESP and DO2 - there are two kinds of DO (DO1 and DO2) which makes implementations hairy and the recommendation unclear (see first point). As the third placement (between RH and FH) for DO header seems to be very useful for home address (cf mobile IP discussion) and tunnel encapsulation limit (DO2 makes it near useless) options the whole DO placement stuff should be redone. I've proposed a solution but I *never* get an answer (even negative :-). Options that appear in DO2 have no need to be mutable since this header is never examined until after the packet has arrived at the final destination. And in fact, if they were mutable and mutated in-flight, they would break things like ESP in null-encryption authentication-only mode. => I agree that mutable options in DO2 should be forbidden (just because they don't make sense). Unfortunately, this requirement that mutable options not appear after the Routing Header is not explicitly stated in the spec anywhere. => I don't believe we need to state this now. It should be done only if/when someone proposes a mutable option which is not hop-by-hop (I don't think DO1 is still useful but there were some (rejected) proposals for mutable hop-by-hop options). And it matters for how one calculates the ICV when processing AH headers (since the calculation treats mutable options as zeroed fields in all cases). If one allows mutable options to appear anywhere, then the AH ICV calculation needs to parse past the AH header through to the end of the packet, instead of being able to treat everything inside of the AH header as an opaque blob. This would needlessly complicate the AH ICV calculation for no practical reason. => this is a different point because "after AH" is not the same thing than "before RH". You can apply your ESP argument too here... Perhaps you should support my DO header cleanup, I'll add a mutable-forbidden statement for DO2 (:-)... Therefore, I'd like to propose that the spec is clarified to limit mutable options to where they make sense, i.e. in Hop-by-Hop and Destination Options headers that appear before the Routing Header. => if nobody has an usage for DO1 I think we should phase it out and simplify your proposal in mutable implies hop-by-hop. P.S. As an aside, it occurs to me that it might be clearer to define a new "Intermediate Destination Options" header to take the place of DO1. => I agree, in DO1 and DO2 are too many choices. I believe for the new header you want a new type? Then it could be declared that this new header (if present) MUST appear before the Routing Header, and that mutable options (if present) MUST appear in either this new header or a Hop-by-Hop header. Or to put it another way, mutable options wouldn't be allowed any more in a Destination Options header. This would also make the spec cleaner - it could get rid of the special case notations explaining the difference between DO1 and DO2. => we agree at least on the necessary cleanup for DO headers. 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 Wed Nov 15 01:31:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAF9TjP07718 for ipng-dist; Wed, 15 Nov 2000 01:29:45 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAF9Taj07710 for ; Wed, 15 Nov 2000 01:29:37 -0800 (PST) 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,v1.7) with ESMTP id BAA06618 for ; Wed, 15 Nov 2000 01:29:36 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA10451 for ; Wed, 15 Nov 2000 02:29:35 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAF9TSb29170; Wed, 15 Nov 2000 10:29:28 +0100 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 KAA18285; Wed, 15 Nov 2000 10:29:27 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA83536; Wed, 15 Nov 2000 10:31:35 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011150931.KAA83536@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Steve Deering cc: Brian Zill , ipng@sunroof.eng.sun.com Subject: Re: Mutable fields and the Hop-by-Hop and Destination Options headers In-reply-to: Your message of Tue, 14 Nov 2000 21:40:38 PST. Date: Wed, 15 Nov 2000 10:31:35 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >P.S. As an aside, it occurs to me that it might be clearer to define a new >"Intermediate Destination Options" header to take the place of DO1. Then it >could be declared that this new header (if present) MUST appear before the >Routing Header, and that mutable options (if present) MUST appear in either >this new header or a Hop-by-Hop header. Or to put it another way, mutable >options wouldn't be allowed any more in a Destination Options header. This >would also make the spec cleaner - it could get rid of the special case >notations explaining the difference between DO1 and DO2. Sounds reasonable, but seems to me like a significant change for a small benefit at this point. => Steve, I think we can avoid the change. The current DO1+DO2 stuff is very hard to implement and there are many reasons to introduce a third placement for destination options: we (IPng WG) should accept that the destination option stuff must be rewritten, if possible for the IPng meeting then: - write a draft before Friday - ask for a slot to explain the issue and proposed solution(s) 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 Wed Nov 15 01:42:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAF9eta07740 for ipng-dist; Wed, 15 Nov 2000 01:40:55 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAF9ekj07733 for ; Wed, 15 Nov 2000 01:40:46 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA24288 for ; Wed, 15 Nov 2000 01:40:41 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07681 for ; Wed, 15 Nov 2000 01:40:40 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAF9ePb11581; Wed, 15 Nov 2000 10:40:25 +0100 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 KAA18649; Wed, 15 Nov 2000 10:40:25 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA83654; Wed, 15 Nov 2000 10:42:33 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011150942.KAA83654@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Markku Savela" cc: ipng@sunroof.eng.sun.com Subject: Re: Mutable fields and the Hop-by-Hop and Destination Options headers In-reply-to: Your message of Wed, 15 Nov 2000 10:39:15 +0200. <000001c04edf$8a617450$e82815ac@hews0169nrc.research.nokia.com> Date: Wed, 15 Nov 2000 10:42:33 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Alternatively, we could specify that any mutable options that appear > after the AH header are treated as if they were immutable, i.e., > included in the authentication computation. Such options, > though mutable, > would not undergo mutation, so could safely be treated as > immutable by AH. At least I definitely prefer this approach (this is the way I have it implemented). => I have done the same thing then I should agree but: AH (nor any other extension header) should not care what follows after it, it's just payload at that stage. => this cannot deal with the case where there are more than one AH header (I've seen some mails about this issue but I don't remember whether this issue was solved and (more important) how). Of course the problem is detected when the internal AH is processed... 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 Wed Nov 15 02:17:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFAGL707774 for ipng-dist; Wed, 15 Nov 2000 02:16:21 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFAGCj07767 for ; Wed, 15 Nov 2000 02:16:12 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA09780 for ; Wed, 15 Nov 2000 02:16:11 -0800 (PST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA22816 for ; Wed, 15 Nov 2000 02:16:10 -0800 (PST) Received: from esebh12nok.ntc.nokia.com (esebh12nok.ntc.nokia.com [131.228.10.109]) by mgw-x3.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id eAFADVB25212; Wed, 15 Nov 2000 12:13:32 +0200 (EET) Received: from loki.research.nokia.com ([172.21.33.76]) by esebh12nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id WZXCY5YZ; Wed, 15 Nov 2000 12:13:31 +0200 Received: from hews0169nrc (hed040-232.research.nokia.com [172.21.40.232]) by loki.research.nokia.com (8.9.3/8.9.3) with SMTP id MAA11610; Wed, 15 Nov 2000 12:13:30 +0200 (EET) X-Authentication-Warning: loki.research.nokia.com: Host hed040-232.research.nokia.com [172.21.40.232] claimed to be hews0169nrc From: "Markku Savela" To: Cc: Subject: RE: Mutable fields and the Hop-by-Hop and Destination Options headers Date: Wed, 15 Nov 2000 12:13:28 +0200 Message-ID: <000001c04eec$b3acd270$e82815ac@hews0169nrc.research.nokia.com> 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 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <200011150942.KAA83654@givry.rennes.enst-bretagne.fr> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: EXT Francis Dupont > => this cannot deal with the case where there are more than > one AH header > (I've seen some mails about this issue but I don't remember > whether this > issue was solved and (more important) how). Of course the problem is > detected when the internal AH is processed... Works quite fine(?) if you adopt the logic that assumes incremental building of multiple AH's. On receive, AH processing removes the outer AH header, before proceeding to the next header. On send, one adds AH at time, from inside-out, independently of each other (previous AH is just payload for the new one). This goes against "read-only" buffer on receive, but IPSEC ESP requires modifiable buffer (or copy) anyway, so having AH to modify (at least logically) the buffer, is not so bad. I think this was discussed on IPSEC list while back (last year?). I prefer the incremental, of course! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 03:41:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFBeO207837 for ipng-dist; Wed, 15 Nov 2000 03:40:24 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFBeDj07830 for ; Wed, 15 Nov 2000 03:40:13 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA20438 for ; Wed, 15 Nov 2000 03:40:12 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08688 for ; Wed, 15 Nov 2000 03:40:11 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00642; Wed, 15 Nov 2000 06:40:10 -0500 (EST) Message-Id: <200011151140.GAA00642@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-1394-00.txt Date: Wed, 15 Nov 2000 06:40:09 -0500 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 IPNG Working Group of the IETF. Title : Transmission of IPv6 Packets over IEEE 1394 Networks Author(s) : K. Fujisawa, A. Onoe Filename : draft-ietf-ipngwg-1394-00.txt Pages : 7 Date : 14-Nov-00 IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. This document describes the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. It also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when the messages are transmitted on an IEEE1394 network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-1394-00.txt 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-1394-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-1394-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: <20001114131048.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-1394-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-1394-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001114131048.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 Nov 15 04:02:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFC0pr07911 for ipng-dist; Wed, 15 Nov 2000 04:00:51 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFC0gj07904 for ; Wed, 15 Nov 2000 04:00:42 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA03946 for ; Wed, 15 Nov 2000 04:00:41 -0800 (PST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12862 for ; Wed, 15 Nov 2000 04:00:40 -0800 (PST) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA12756 for ; Wed, 15 Nov 2000 13:00:13 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA11573 for ; Wed, 15 Nov 2000 13:00:38 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Nov 2000 13:00:37 +0100 Message-ID: <158669A6D0F5D3119B940060086D94F55006B4@ULML202E> From: Metzler Jochen To: "Ipng (E-Mail)" Subject: Usage of IPv6 flow label Date: Wed, 15 Nov 2000 12:55:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id eAFC0hj07905 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I have some questions depending the usage of the flow label field within IPv6. Background of my questioning is that actually within 3GPP standardization the discussion appears if the flow label could be used for bearer identification if IPv6 would be chosen as transport option within the UMTS Radio Access Networks. Within RFC2460 the usage of the flow label field is not fully described and for me it is not clear if anything mentioned in the Appendix is part of the standard or only for information. Therefore I have the following questions: - Would the flow label be set by the Application? As far as I could see from the API description the flow label would be set from the application layer, can also be read by the application layer and must be chosen pseudo-randomly. Are there any further restrictions? - Can intermediate routers change the flow label? Appendix A of RFC2460 states that hosts or routers that do not support the flow label should pass the field on unchanged. Is this also true for hosts or routers that do support the flow label? What is the procedure if an router supports flow labels but has no context about a specific flow label? - Are there any ideas how to use the flow label field in the future, especially with respect to non-default QoS? - In our view IP flows are quit similar to what is called transport bearer within an UMTS RAN. Are there any objections that preclude mapping of transport bearers to IP flows? and last but not least: - Is this the right place to put my questions or are there other WGs involved into flow label processing? Cheers Jochen ------------------------------------------------------------------ Jochen Metzler Siemens AG Lise-Meitner-Straße 5, 89081 Ulm Phone: +49.(0)731.9533.390 Mobile Networks Fax : +49.(0)731.9533.336 ICM N MR UR SE 2 mailto: jochen.metzler@icn.siemens.de -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 04:30:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFCTV407942 for ipng-dist; Wed, 15 Nov 2000 04:29:31 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFCTJj07935 for ; Wed, 15 Nov 2000 04:29:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA24822 for ; Wed, 15 Nov 2000 04:29:18 -0800 (PST) Received: from starfruit.itojun.org (ny-ppp020.iij-us.net [216.98.99.20]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12574 for ; Wed, 15 Nov 2000 04:29:16 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id A57A37EF9; Wed, 15 Nov 2000 21:27:46 +0900 (JST) To: Metzler Jochen Cc: "Ipng (E-Mail)" In-reply-to: Jochen.Metzler's message of Wed, 15 Nov 2000 12:55:42 +0100. <158669A6D0F5D3119B940060086D94F55006B4@ULML202E> 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: Usage of IPv6 flow label From: Jun-ichiro itojun Hagino Date: Wed, 15 Nov 2000 21:27:46 +0900 Message-Id: <20001115122746.A57A37EF9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Hi all, >I have some questions depending the usage of the flow >label field within IPv6. Background of my questioning is >that actually within 3GPP standardization the discussion >appears if the flow label could be used for bearer >identification if IPv6 would be chosen as transport >option within the UMTS Radio Access Networks. > >Within RFC2460 the usage of the flow label field is not >fully described and for me it is not clear if anything >mentioned in the Appendix is part of the standard or >only for information. Therefore I have the following >questions: I tried to clarify some of the issues with flowlabel and its API, it is documented in draft-itojun-ipv6-flowlabel-api-00.txt. i really appreciate your feedbacks. i'll be presenting about it at San Diego IETF. >- Can intermediate routers change the flow label? > Appendix A of RFC2460 states that hosts or routers that > do not support the flow label should pass the field on > unchanged. Is this also true for hosts or routers that > do support the flow label? What is the procedure if an > router supports flow labels but has no context about a > specific flow label? seems to me, no. 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 Nov 15 04:32:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFCVSS07961 for ipng-dist; Wed, 15 Nov 2000 04:31:28 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFCVHj07954 for ; Wed, 15 Nov 2000 04:31:18 -0800 (PST) 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,v1.7) with ESMTP id EAA06125 for ; Wed, 15 Nov 2000 04:31:16 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13520 for ; Wed, 15 Nov 2000 04:31:10 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id eAFCUi712541; Wed, 15 Nov 2000 19:30:44 +0700 (ICT) From: Robert Elz To: Brian Zill cc: ipng@sunroof.eng.sun.com Subject: Re: Mutable fields and the Hop-by-Hop and Destination Options headers In-reply-to: Your message of "Tue, 14 Nov 2000 21:10:22 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Nov 2000 19:30:44 +0700 Message-ID: <12539.974291444@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 14 Nov 2000 21:10:22 -0800 From: Brian Zill Message-ID: It certainly makes no sense to have to allow specially for the possibility of mutable options, which cannot in fact mutate. I kind of like Steve's suggestion ... > Alternatively, we could specify that any mutable options that appear > after the AH header are treated as if they were immutable except we can generalise that - anything that is internal to any header (part of the payload of that header) must be able to be treated as immutable for the purposes of the header. There can never be (rationally) a need to peel back the onion and look inside the payload to attempt to interpret any particular header. The mutable/immutable stuff is needed only because we need to have the security headers apply to data that is strictly outside their scope (data from headers in which they're wrapped), and for that, allowance that things might sometimes change is unavoidable. Some of that is just handled by rules "the hop count field varies", but where data yet to be invented exists (options) the method to make clear which is mutable, and which is not is clear - but only in headers that come outside the header which cares. But... | P.S. As an aside, it occurs to me that it might be clearer to define a new | "Intermediate Destination Options" header to take the place of DO1. Please, no - the double use of the DO header is a thing of beauty. It, just by being there, makes clear the way the IPv6 header structure is to work, it makes clear that headers can appear more than once, it makes clear that the interpretation of a header depends upon where in the sequence of headers it is found, it makes clear the onion peeling parsing technique that is defined to apply to IPv6 headers, and is a very clean architectural design. Please don't mess with this just because it seems easier to fix everything in concrete (this follows this follows this...) and pretend that variations are never going to be possible. (Aside from that it would be a waste of one of the 256 header type codes for no reason whatever). 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 Nov 15 05:02:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFD0rM08013 for ipng-dist; Wed, 15 Nov 2000 05:00:53 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFD0ij08006 for ; Wed, 15 Nov 2000 05:00:44 -0800 (PST) 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,v1.7) with ESMTP id FAA09543 for ; Wed, 15 Nov 2000 05:00:43 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27541 for ; Wed, 15 Nov 2000 05:00:42 -0800 (PST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VTFR51KQ; Wed, 15 Nov 2000 14:00:42 +0100 Reply-To: From: "Thomas Eklund" To: "'Francis Dupont'" , "'Steve Deering'" Cc: "'Brian Zill'" , Subject: Regarding the Options headers Date: Wed, 15 Nov 2000 14:00:34 +0100 Message-ID: <31A473DBB655D21180850008C71E251A0294924F@mail.kebne.se> 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 In-Reply-To: <31A473DBB655D21180850008C71E251A02E4F396@mail.kebne.se> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Another comment on the extension header orders... What we need is a more deterministic approach to build the daisy chain of headers. Because we cant have the different flavours and it is very difficult as it is when we have to parse all the extension headers to get to the transport header (which is useful for layer 4 classification)... This is no problem if you do it in a sw based router where you have all the time in the world to parse your header but it becomes an issue when you implement IPv6 in asic!! Have people thought about/What do people think about changing the length field and replacing it with a (IP) header length field (the basic header + the extension headers) and have a mandatory payload length in the last extension header (transport header + payload)? (one flag that tells if the packet is decode with an ESP header where packet classification on layer 4 info is useless - of course:-) This would really make it easier to mask out the offset in the basic header towards the transport header (which simply would make up to the loss of the protocol field that we had in IPv4) without having to have too wide packet decoding (which becomes a real problem when you have to go over 300 bytes in oc-768 speeds and above) And I would also like to define a mandatory limit on the length of the IP header incl extension headers. What do people think? -- 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 Nov 15 05:38:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFDawU08057 for ipng-dist; Wed, 15 Nov 2000 05:36:58 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFDanj08050 for ; Wed, 15 Nov 2000 05:36:49 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA12549 for ; Wed, 15 Nov 2000 05:36:49 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA00251 for ; Wed, 15 Nov 2000 05:36:45 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAFDXhb11600; Wed, 15 Nov 2000 14:33:43 +0100 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 OAA27420; Wed, 15 Nov 2000 14:33:43 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id OAA84548; Wed, 15 Nov 2000 14:35:51 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011151335.OAA84548@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Robert Elz cc: Brian Zill , ipng@sunroof.eng.sun.com Subject: Re: Mutable fields and the Hop-by-Hop and Destination Options headers In-reply-to: Your message of Wed, 15 Nov 2000 19:30:44 +0700. <12539.974291444@brandenburg.cs.mu.OZ.AU> Date: Wed, 15 Nov 2000 14:35:51 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: But... | P.S. As an aside, it occurs to me that it might be clearer to define a new | "Intermediate Destination Options" header to take the place of DO1. Please, no - the double use of the DO header is a thing of beauty. => the beauty of the Hell if you try to implement it... It, just by being there, makes clear the way the IPv6 header structure is to work, it makes clear that headers can appear more than once, it makes clear that the interpretation of a header depends upon where in the sequence of headers it is found, it makes clear the onion peeling parsing technique that is defined to apply to IPv6 headers, and is a very clean architectural design. => can you explain how you express this (for instance the interpretation of a header depends upon where it is found) in an API? Please don't mess with this just because it seems easier to fix everything in concrete (this follows this follows this...) and pretend that variations are never going to be possible. => variations should be possible in reception but should not be possible in emission. I can't see a good reason to keep the complexity (with bugs in implementations and done by programmers) because we have no real use of it. The current recommendation level (SHOULD) is the good one (I agree a MUST would be too strong). (Aside from that it would be a waste of one of the 256 header type codes for no reason whatever). => near half of the space (120 codes) is still free. My concern is more the delay for a new code than the waste... 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 Wed Nov 15 05:54:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFDrZs08096 for ipng-dist; Wed, 15 Nov 2000 05:53:35 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFDrQj08089 for ; Wed, 15 Nov 2000 05:53:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA13985 for ; Wed, 15 Nov 2000 05:53:23 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA06554 for ; Wed, 15 Nov 2000 05:53:19 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAFDr1b19063; Wed, 15 Nov 2000 14:53:01 +0100 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 OAA28234; Wed, 15 Nov 2000 14:53:01 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id OAA84645; Wed, 15 Nov 2000 14:55:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011151355.OAA84645@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: thomas.eklund@xelerated.com cc: "'Steve Deering'" , "'Brian Zill'" , ipng@sunroof.eng.sun.com Subject: Re: Regarding the Options headers In-reply-to: Your message of Wed, 15 Nov 2000 14:00:34 +0100. <31A473DBB655D21180850008C71E251A0294924F@mail.kebne.se> Date: Wed, 15 Nov 2000 14:55:10 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Another comment on the extension header orders... What we need is a more deterministic approach to build the daisy chain of headers. Because we cant have the different flavours and it is very difficult as it is when we have to parse all the extension headers to get to the transport header (which is useful for layer 4 classification)... => I understand your concern but I have just replied to Robert Elz a MUST for the layout of extension header chain would be too strong then you must support any layout, including crazy/exotic. This is no problem if you do it in a sw based router where you have all the time in the world to parse your header => no, a software based router wants to be fast too and will just look at the destination address (me/them) and the next header type (zero/non-zero). but it becomes an issue when you implement IPv6 in asic!! => just don't do layer 4 classification in a router? Seriously I expect to avoid a IPv4-like situation where options are not used because they are processed slowly then not used then... Have people thought about/What do people think about changing the length field => which one? The IPv6 header length field *is* useful and there is no free space. and replacing it with a (IP) header length field (the basic header + the extension headers) and have a mandatory payload length in the last extension header (transport header + payload)? (one flag that tells if the packet is decode with an ESP header where packet classification on layer 4 info is useless - of course:-) => I think nothing good of this. It is not the job of a router to look at inside packets (ESP will save us!) This would really make it easier to mask out the offset in the basic header towards the transport header (which simply would make up to the loss of the protocol field that we had in IPv4) without having to have too wide packet decoding (which becomes a real problem when you have to go over 300 bytes in oc-768 speeds and above) => (provocation mode on) use MPLS? (provocation mode off) And I would also like to define a mandatory limit on the length of the IP header incl extension headers. => the maximum size of one extension header is 2048 ((255+1)*8) octets, this is already far more than the minimal MTU (1280) then I expect nobody will get a consensus for that. What do people think? => do the layer >= 4 classification at the edge and use DS byte, flow label, ... to mark packets. I believe this is the IntServ/DiffServ lesson: core routers should route 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 Wed Nov 15 06:01:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFE18V08115 for ipng-dist; Wed, 15 Nov 2000 06:01:08 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFE0wj08108 for ; Wed, 15 Nov 2000 06:00:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA25630 for ; Wed, 15 Nov 2000 06:00:59 -0800 (PST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13338 for ; Wed, 15 Nov 2000 06:00:58 -0800 (PST) Received: from esebh11nok.ntc.nokia.com (esebh11nok.ntc.nokia.com [131.228.10.108]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id eAFE0vP09507 for ; Wed, 15 Nov 2000 16:00:57 +0200 (EET) Received: from loki.research.nokia.com ([172.21.33.76]) by esebh11nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id W6QDTXDG; Wed, 15 Nov 2000 16:00:57 +0200 Received: from hews0169nrc (hed040-232.research.nokia.com [172.21.40.232]) by loki.research.nokia.com (8.9.3/8.9.3) with SMTP id QAA13391 for ; Wed, 15 Nov 2000 16:00:56 +0200 (EET) X-Authentication-Warning: loki.research.nokia.com: Host hed040-232.research.nokia.com [172.21.40.232] claimed to be hews0169nrc From: "Markku Savela" To: Subject: RE: Regarding the Options headers Date: Wed, 15 Nov 2000 16:00:55 +0200 Message-ID: <000001c04f0c$79722720$e82815ac@hews0169nrc.research.nokia.com> 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 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <31A473DBB655D21180850008C71E251A0294924F@mail.kebne.se> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: EXT Thomas Eklund > This is no problem if you do it in a sw based router where > you have all the > time in the world to parse your header but it becomes an > issue when you > implement IPv6 in asic!! How about going with the original spirit of the Internet, that routers have no business of snooping into packet any deeper than the IP header? Lets keep it clean, and not break the layering! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 06:49:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFElli08190 for ipng-dist; Wed, 15 Nov 2000 06:47:47 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFElcj08183 for ; Wed, 15 Nov 2000 06:47:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA18791 for ; Wed, 15 Nov 2000 06:47:39 -0800 (PST) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28858 for ; Wed, 15 Nov 2000 06:47:38 -0800 (PST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA33450; Wed, 15 Nov 2000 09:44:21 -0500 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA31424; Wed, 15 Nov 2000 09:44:22 -0500 Received: from rotala.raleigh.ibm.com (IDENT:narten@localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id JAA08525; Wed, 15 Nov 2000 09:44:08 -0500 Message-Id: <200011151444.JAA08525@rotala.raleigh.ibm.com> To: Metzler Jochen cc: "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label In-Reply-To: Message from Metzler Jochen of "Wed, 15 Nov 2000 12:55:42 +0100." <158669A6D0F5D3119B940060086D94F55006B4@ULML202E> Date: Wed, 15 Nov 2000 09:44:08 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Metzler, > Within RFC2460 the usage of the flow label field is not > fully described and for me it is not clear if anything > mentioned in the Appendix is part of the standard or > only for information. Therefore I have the following > questions: The bottom line is that as of this time, no one has proposed how they would like to use the Flow Label and led the WG to consensus on their approach. Hence, it really is unspecified in the sense that its useage/definition remains to be defined. If you have a proposal on how it could/should be used, this WG is certainly the place to make that proposal, and I would encourage you to do so. I'll note that there have been discussions in the past where arguments have been made that the flow label should not be modified by any routers (i.e., it has end-to-end semantics that need to respected) while other folks have argued that it might be good to allow it to be modified by routers (e.g., in support of something like MPLS). The door has been left open for either of those approaches. Specifically, the Flow Label is considered a mutable field from the perspective of IPsec, thus IPsec won't break if the field is modified by routers. Again, what is needed is a concrete proposal that answers the types of questions you raised. 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 Nov 15 07:29:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFFR5F08221 for ipng-dist; Wed, 15 Nov 2000 07:27:05 -0800 (PST) Received: from austsun.Central.Sun.COM (austsun.Central.Sun.COM [129.152.61.9]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFFQuj08214 for ; Wed, 15 Nov 2000 07:26:56 -0800 (PST) Received: from Sun.COM (hogwart [129.152.60.185]) by austsun.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA13823; Wed, 15 Nov 2000 08:57:47 -0600 (CST) Message-ID: <3A12A46F.DEC467B8@Sun.COM> Date: Wed, 15 Nov 2000 08:57:51 -0600 From: Dave Marquardt Organization: Sun Microsystems X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Markku Savela CC: "IPng List (E-mail)" Subject: Re: APIs for controlling source address selection References: <000101c04ee2$6ceb4fb0$e82815ac@hews0169nrc.research.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku Savela wrote: > > From: EXT Richard Draves > > > > I have two possible designs for your consideration: A > > (simple) and B (more complex). > > Either one is probably easy to implement and use. > > I'm just wondering whether this type thing is the right direction to go with > the API? It requires each application to include a user controllable method > for choosing these settings. "require" seems a bit strong here. I don't think any applications is REQUIRED to use this interface. -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 Nov 15 07:32:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFFVOG08240 for ipng-dist; Wed, 15 Nov 2000 07:31:24 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFFVEj08233 for ; Wed, 15 Nov 2000 07:31:14 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA25058 for ; Wed, 15 Nov 2000 07:31:08 -0800 (PST) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA21028 for ; Wed, 15 Nov 2000 07:31:07 -0800 (PST) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id 411AA1DBB; Wed, 15 Nov 2000 09:31:07 -0600 (CST) Received: from yquarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id C5E681D1F; Wed, 15 Nov 2000 09:31:06 -0600 (CST) Received: from whitestar.zk3.dec.com by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id KAA0000000805; Wed, 15 Nov 2000 10:31:03 -0500 (EST) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA04472; Wed, 15 Nov 2000 10:31:03 -0500 Message-Id: <3A12AC37.B5C1511@zk3.dec.com> Date: Wed, 15 Nov 2000 10:31:03 -0500 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.7 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: ru, en Mime-Version: 1.0 To: Brian Zill Cc: ipng@sunroof.eng.sun.com Subject: Re: Mutable fields and the Hop-by-Hop and Destination Options headers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Zill wrote: > P.S. As an aside, it occurs to me that it might be clearer to define a new > "Intermediate Destination Options" header to take the place of DO1. Then it > could be declared that this new header (if present) MUST appear before the > Routing Header, and that mutable options (if present) MUST appear in either > this new header or a Hop-by-Hop header. Or to put it another way, mutable > options wouldn't be allowed any more in a Destination Options header. This > would also make the spec cleaner - it could get rid of the special case > notations explaining the difference between DO1 and DO2. Brian I agree with you that Destionation Options headers need to be clarified. In fact, Ken Powel and I talked about this a few days agoa and came up with almost the same solution you have described above. The only difference was that we did not require the Routing Header. In our conversation, this "Intermediate Destination Options" (I kind of like this name) would go after Hop-by-Hop (if present) or after the IPv6 header (if HbH is not present). This header would be non-fragmentable. This header would provide the location for any options that may be mutable and/or any options that may have to be examined by some of the hops along the way to the destination, eg. Tunnel Limit Option, Home Address Option, etc. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 08:34:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFGWc908297 for ipng-dist; Wed, 15 Nov 2000 08:32:38 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFGWTj08290 for ; Wed, 15 Nov 2000 08:32:29 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA17703 for ; Wed, 15 Nov 2000 08:32:29 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA23084 for ; Wed, 15 Nov 2000 08:32:28 -0800 (PST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VTFR5G06; Wed, 15 Nov 2000 17:32:24 +0100 Reply-To: From: "Thomas Eklund" To: Cc: "'Steve Deering'" , "'Brian Zill'" , Subject: RE: Regarding the Options headers Date: Wed, 15 Nov 2000 17:32:15 +0100 Message-ID: <31A473DBB655D21180850008C71E251A02949259@mail.kebne.se> 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 In-Reply-To: <31A473DBB655D21180850008C71E251A02E4F9CE@mail.kebne.se> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Francis, see below. > => I understand your concern but I have just replied to Robert Elz > a MUST for the layout of extension header chain would be too strong > then you must support any layout, including crazy/exotic. > > This is no problem if you do it in a sw based router where > you have all the > time in the world to parse your header > > => no, a software based router wants to be fast too and will > just look at > the destination address (me/them) and the next header type > (zero/non-zero). I was expecting that answer..:-) > > but it becomes an issue when you implement IPv6 in asic!! > > => just don't do layer 4 classification in a router? > Seriously I expect to avoid a IPv4-like situation where > options are not > used because they are processed slowly then not used then... this is just to easy to say that. layer 4 classification will be used in the campus backbone/high-end enterprise and with the current solution it is very difficult to do it if you have any speed (we see 1GE links today and we will see even 10 GE links very soon) so it is an issue if we want ipv6 hot "hit" in the enterprise networks and campus networks... if we dont solve the problem that IPv4 routers do today we are on the wrong path... One might argue that why not use intserv and treat the flowlabel as a intserv flow and let the router map several flow into traffic classes of aggregated traffic (DSCP classes) but then it is up to the flow label to decide and that is as we know undefined.... > > Have people thought about/What do people think about > changing the length > field > > => which one? The IPv6 header length field *is* useful and there is no > free space. I meant the Payload Length.... This is the whole point... I think you missed my point. I wanted a chance to classify on the trnasport header without having to have a loop that first look into the first "next header" and then looks into the senocd extension header "next header" pointer and then look into the next one and in the next one... This require a loop to run which makes it "practically" impsossible to implement in an asic (which is the only way to go if you want speed and a future proven roadmap for higher bandwidth with Moores law) it will let you implement this in a processor based approach and because you will have a loop consuming your pipiline stages in you network processor you will have a VERY difficult task to solve!! (Eventhough I'm in favour of something between a NP and a dedicated ASIC) If we had a chance to mask out the offset where the transport header where immediataly (without the need for a loop) then we can mask out the remaining length that is the new "payload + transport header" and add it to the new "IP header length" (that consists of basic header + extension headers)... And then it is very easy to classify on layer 4. I think that this would be a big improvement for ipv6. > > => I think nothing good of this. It is not the job of a > router to look at > inside packets (ESP will save us!) People that implement this in hardware see this problem TODAY... And of course if the packet is encrypted with an ESP then it is no use to classify on L4 but then we could have a flag in the flow label field that " signalled inband" that we have no way to do this, than we could aggregate this in the router and block any QoS related policy that included layer for instance... But in most cases there sits a firewall at the same place where we have the edge router and then the traffic comes unencrypted to the router and we might want to classify the traffic into a DSCP based on layer 4 info (As a side note: I have spoken to several operators that do exactly this way today for IPv4 > And I would also like to define a mandatory limit on the > length of the IP > header incl extension headers. > > => the maximum size of one extension header is 2048 > ((255+1)*8) octets, > this is already far more than the minimal MTU (1280) then I > expect nobody > will get a consensus for that. Which is not so good if there are any speeds in an edge router... > > What do people think? > > => do the layer >= 4 classification at the edge and use DS > byte, flow label, > ... to mark packets. I believe this is the IntServ/DiffServ > lesson: core > routers should route Of course I'm in favour of having the edge routers classify the packets. But this was not the issue I raised here - I hope you understand what I 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 Nov 15 08:37:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFGag608315 for ipng-dist; Wed, 15 Nov 2000 08:36:42 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFGaWj08308 for ; Wed, 15 Nov 2000 08:36:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA13366 for ; Wed, 15 Nov 2000 08:36:32 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16116 for ; Wed, 15 Nov 2000 08:36:31 -0800 (PST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VTFR5HAZ; Wed, 15 Nov 2000 17:36:31 +0100 Reply-To: From: "Thomas Eklund" To: "'Markku Savela'" , Subject: RE: Regarding the Options headers Date: Wed, 15 Nov 2000 17:36:28 +0100 Message-ID: <31A473DBB655D21180850008C71E251A0294925A@mail.kebne.se> 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 In-Reply-To: <31A473DBB655D21180850008C71E251A02E7D2D0@mail.kebne.se> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just one short comment, I agree with you - but what do you do when the ISP uses this today in their edge routers? Lets not make it a religous thing here - this is a real problem that IPv6 are facing when it will take the next step into production networks (with real speeds) not any field trial networks. -- thomas > > This is no problem if you do it in a sw based router where > > you have all the > > time in the world to parse your header but it becomes an > > issue when you > > implement IPv6 in asic!! > > How about going with the original spirit of the Internet, > that routers have > no business of snooping into packet any deeper than the IP header? > > Lets keep it clean, and not break the layering! > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 15 10:54:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFIqGW08704 for ipng-dist; Wed, 15 Nov 2000 10:52:16 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFIq7j08697 for ; Wed, 15 Nov 2000 10:52:07 -0800 (PST) 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,v1.7) with ESMTP id KAA01528 for ; Wed, 15 Nov 2000 10:52:06 -0800 (PST) Received: from ish7.ericsson.com.au ([203.61.155.111]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12877 for ; Wed, 15 Nov 2000 10:52:04 -0800 (PST) Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id FAA29752; Thu, 16 Nov 2000 05:48:20 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id FAA18396; Thu, 16 Nov 2000 05:51:09 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Nov 2000 05:51:24 +1100 Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613E01@eaubrnt018.epa.ericsson.se> From: "Hesham Soliman (EPA)" To: "'Jun-ichiro itojun Hagino'" , Metzler Jochen Cc: "Ipng (E-Mail)" Subject: RE: Usage of IPv6 flow label Date: Thu, 16 Nov 2000 05:51:22 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Hi all, > >I have some questions depending the usage of the flow > >label field within IPv6. Background of my questioning is > >that actually within 3GPP standardization the discussion > >appears if the flow label could be used for bearer > >identification if IPv6 would be chosen as transport > >option within the UMTS Radio Access Networks. > => It is also used in the GGSN (default router in IPv6 land) as one of the options to identify a flow and make the right QoS decisions. The router is informed by the IPv6 node about the flow label value for each connection. > >- Can intermediate routers change the flow label? > > Appendix A of RFC2460 states that hosts or routers that > > do not support the flow label should pass the field on > > unchanged. Is this also true for hosts or routers that > > do support the flow label? What is the procedure if an > > router supports flow labels but has no context about a > > specific flow label? > > seems to me, no. > => Agreed. Also based on my comment above I don't think it would be a good idea. I can't remember if it's included in the AH calculation or not. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 14:23:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFMMIP08943 for ipng-dist; Wed, 15 Nov 2000 14:22:18 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFMM6j08936 for ; Wed, 15 Nov 2000 14:22:07 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA28260 for ; Wed, 15 Nov 2000 14:22:07 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28655 for ; Wed, 15 Nov 2000 14:22:06 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id OAA00440; Wed, 15 Nov 2000 14:14:24 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA05674; Wed, 15 Nov 2000 14:14:24 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14867.2752.354630.311660@thomasm-u1.cisco.com> Date: Wed, 15 Nov 2000 14:14:24 -0800 (PST) To: "Hesham Soliman (EPA)" Cc: "'Jun-ichiro itojun Hagino'" , Metzler Jochen , "Ipng (E-Mail)" Subject: RE: Usage of IPv6 flow label In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A50C613E01@eaubrnt018.epa.ericsson.se> References: <4B6BC00CD15FD2119E5F0008C7A419A50C613E01@eaubrnt018.epa.ericsson.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham Soliman (EPA) writes: > > >I have some questions depending the usage of the flow > > >label field within IPv6. Background of my questioning is > > >that actually within 3GPP standardization the discussion > > >appears if the flow label could be used for bearer > > >identification if IPv6 would be chosen as transport > > >option within the UMTS Radio Access Networks. > > > => It is also used in the GGSN (default router in IPv6 land) > as one of the options to identify a flow and make the right > QoS decisions. > The router is informed by the IPv6 node about > the flow label value for each connection. Er, by what protocol does it inform the router? Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 14:41:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFMdqQ09001 for ipng-dist; Wed, 15 Nov 2000 14:39:52 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFMdhj08994 for ; Wed, 15 Nov 2000 14:39:43 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA17790 for ; Wed, 15 Nov 2000 14:39:44 -0800 (PST) Received: from ish7.ericsson.com.au ([203.61.155.111]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06071 for ; Wed, 15 Nov 2000 14:39:39 -0800 (PST) Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id JAA10417; Thu, 16 Nov 2000 09:35:56 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id JAA06228; Thu, 16 Nov 2000 09:38:46 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Nov 2000 09:39:00 +1100 Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613E05@eaubrnt018.epa.ericsson.se> From: "Hesham Soliman (EPA)" To: "'Michael Thomas'" Cc: "Ipng (E-Mail)" Subject: RE: Usage of IPv6 flow label Date: Thu, 16 Nov 2000 09:38:49 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Hesham Soliman (EPA) writes: > > > >I have some questions depending the usage of the flow > > > >label field within IPv6. Background of my questioning is > > > >that actually within 3GPP standardization the discussion > > > >appears if the flow label could be used for bearer > > > >identification if IPv6 would be chosen as transport > > > >option within the UMTS Radio Access Networks. > > > > > => It is also used in the GGSN (default router in IPv6 land) > > as one of the options to identify a flow and make the right > > QoS decisions. > > The router is informed by the IPv6 node about > > the flow label value for each connection. > > Er, by what protocol does it inform the router? > => A 3GPP protocol. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 14:47:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFMkEa09028 for ipng-dist; Wed, 15 Nov 2000 14:46:14 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFMk4j09021 for ; Wed, 15 Nov 2000 14:46:05 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA19703 for ; Wed, 15 Nov 2000 14:46:05 -0800 (PST) Received: from ish7.ericsson.com.au ([203.61.155.111]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12971 for ; Wed, 15 Nov 2000 14:46:03 -0800 (PST) Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id JAA11068; Thu, 16 Nov 2000 09:42:20 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id JAA07128; Thu, 16 Nov 2000 09:45:10 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Nov 2000 09:45:25 +1100 Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613E06@eaubrnt018.epa.ericsson.se> From: "Hesham Soliman (EPA)" To: "'Jun-ichiro itojun Hagino'" Cc: Metzler Jochen , "Ipng (E-Mail)" Subject: RE: Usage of IPv6 flow label Date: Thu, 16 Nov 2000 09:45:22 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> >- Can intermediate routers change the flow label? > >> > Appendix A of RFC2460 states that hosts or routers that > >> > do not support the flow label should pass the field on > >> > unchanged. Is this also true for hosts or routers that > >> > do support the flow label? What is the procedure if an > >> > router supports flow labels but has no context about a > >> > specific flow label? > >> seems to me, no. > > => Agreed. Also based on my comment above I > > don't think it would be a good idea. > > I can't remember if it's included in the AH calculation > > or not. > > flow label field is not part of AH calculation, but as RSVP already > requires it to be end-to-end (not hop-by-hop) i think we shouldn't > rewrite it in transit. > => Agreed. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 15:23:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAFNM7Z09099 for ipng-dist; Wed, 15 Nov 2000 15:22:07 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAFNLwj09092 for ; Wed, 15 Nov 2000 15:21:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA15312 for ; Wed, 15 Nov 2000 15:21:54 -0800 (PST) Received: from sa-usa-sj-po.siliconaccess.com (w106.z064001180.sjc-ca.dsl.cnc.net [64.1.180.106]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23315 for ; Wed, 15 Nov 2000 15:21:54 -0800 (PST) Received: by sa-usa-sj-po.sanjose.siliconaccess.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Nov 2000 15:10:15 -0800 Message-ID: <39487C1D4449D41198960090270D93C00CB3CA@sa-can-ott-po.ottawa.siliconaccess.com> From: Mohit Goyal To: "'thomas.eklund@xelerated.com'" , "'Markku Savela'" , ipng@sunroof.eng.sun.com Subject: RE: Regarding the Options headers Date: Wed, 15 Nov 2000 15:23:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A quick question then: How would you handle the cases where a Routing Header is to be processed? In this case, the ROUTER has to go beyond the IPv6 header. Perhaps, even processing a Hop by hop and/or destinations options header, prior to it also. It's tough to do in an ASIC, I agree. However, I still don't how you could simply skip over the extension headers, and go directly to the transport layer. I think the looping algorithm is your best option. On a side note: typically, how many addresses would reside in the Routing Header? Cheers, Mo -----Original Message----- From: Thomas Eklund [mailto:thomas.eklund@xelerated.com] Sent: Wednesday, November 15, 2000 11:36 AM To: 'Markku Savela'; ipng@sunroof.eng.sun.com Subject: RE: Regarding the Options headers Just one short comment, I agree with you - but what do you do when the ISP uses this today in their edge routers? Lets not make it a religous thing here - this is a real problem that IPv6 are facing when it will take the next step into production networks (with real speeds) not any field trial networks. -- thomas > > This is no problem if you do it in a sw based router where > > you have all the > > time in the world to parse your header but it becomes an > > issue when you > > implement IPv6 in asic!! > > How about going with the original spirit of the Internet, > that routers have > no business of snooping into packet any deeper than the IP header? > > Lets keep it clean, and not break the layering! > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 16:40:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAG0dJ009193 for ipng-dist; Wed, 15 Nov 2000 16:39:19 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAG0dAj09186 for ; Wed, 15 Nov 2000 16:39:10 -0800 (PST) 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,v1.7) with ESMTP id QAA20178 for ; Wed, 15 Nov 2000 16:39:10 -0800 (PST) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17421 for ; Wed, 15 Nov 2000 16:39:09 -0800 (PST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 13wD51-0000ih-00; Wed, 15 Nov 2000 19:39:07 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA29303; Wed, 15 Nov 00 19:33:50 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id TAA26496; Wed, 15 Nov 2000 19:38:30 -0500 Message-Id: <3A132C65.E1BA19B1@txc.com> Date: Wed, 15 Nov 2000 19:37:57 -0500 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ion-ipv6-ind-04.txt References: <200011062140.QAA17885@rotala.raleigh.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms3E969755E47C4E7B295B4515" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms3E969755E47C4E7B295B4515 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thomas, Thanks for the suggestion. In response to this, that is, to add more clarity, I am going to modify the text in Section 3.1 (which defines the Source/Target Address List) as follows: <<< Note: An implementation MUST NOT send duplicates in the IPv6 address. <<< will be replaced with: >>> Note 1: The scope of the Inverse Neighbor Discovery mechanism is limited to IPv6 address discovery, that is, providing address mapping information. Therefore, Inverse Neighbor Discovery does not make any provisions or rules regarding how a node uses the addresses that were returned in an Inverse Discovery message. Furthermore, it does not exclude any particular type of IPv6 address from the Source or Target Address List. For example, if an interface has manually configured, and autoconfigured addresses, including temporary ones, unicast, multicast, etc..., the list should not exclude any. Note 2: An implementation MUST NOT send duplicates in the IPv6 address. >>> A new draft containing this modification will be made available shortly. Thanks, Alex Thomas Narten wrote: > > Alex, > > In discussing this document (which the WG requested be advanced as > PS), the IESG had the following question: > > If a node has anonymous address (per > draft-ietf-ipngwg-addrconf-privacy-03.txt), are those IPv6 addresses > also included in IND responses? The document should make this clear. > > 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 > -------------------------------------------------------------------- --------------ms3E969755E47C4E7B295B4515 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKBgYJKoZIhvcNAQcCoIIJ9zCCCfMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICETCCAg0CAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDExMTYwMDM3NTlaMCMGCSqGSIb3DQEJBDEWBBQNfNoEykTsHQ9+AVoh CaQOrIMF1zAnBgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAdunoO/dmKILudhBrVBEivY1pY2csSycUgA+WaFupjXWxKH790c2WRNcv f7G/EamEbjnsXTZYOtYFSYAcPFD9GWVtUGkOFs3yLnbv94D/XzvZdeBz+TFOiyGArXfZITbS ylYZyk5JFEXi8SRN+A6HQAN1GthguP3sbVDHiJjKOS8= --------------ms3E969755E47C4E7B295B4515-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 23:15:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAG7Dik09399 for ipng-dist; Wed, 15 Nov 2000 23:13:44 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAG7DXj09392 for ; Wed, 15 Nov 2000 23:13:33 -0800 (PST) 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,v1.7) with ESMTP id XAA03272 for ; Wed, 15 Nov 2000 23:13:33 -0800 (PST) Received: from starfruit.itojun.org (ny-ppp020.iij-us.net [216.98.99.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA22198 for ; Thu, 16 Nov 2000 00:13:31 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 321B17EF9; Thu, 16 Nov 2000 04:09:19 +0900 (JST) To: "Hesham Soliman (EPA)" Cc: Metzler Jochen , "Ipng (E-Mail)" In-reply-to: Hesham.Soliman's message of Thu, 16 Nov 2000 05:51:22 +1100. <4B6BC00CD15FD2119E5F0008C7A419A50C613E01@eaubrnt018.epa.ericsson.se> 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: Usage of IPv6 flow label From: Jun-ichiro itojun Hagino Date: Thu, 16 Nov 2000 04:09:19 +0900 Message-Id: <20001115190919.321B17EF9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >- Can intermediate routers change the flow label? >> > Appendix A of RFC2460 states that hosts or routers that >> > do not support the flow label should pass the field on >> > unchanged. Is this also true for hosts or routers that >> > do support the flow label? What is the procedure if an >> > router supports flow labels but has no context about a >> > specific flow label? >> seems to me, no. > => Agreed. Also based on my comment above I > don't think it would be a good idea. > I can't remember if it's included in the AH calculation > or not. flow label field is not part of AH calculation, but as RSVP already requires it to be end-to-end (not hop-by-hop) i think we shouldn't rewrite it in transit. 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 Nov 16 00:02:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAG80fe09457 for ipng-dist; Thu, 16 Nov 2000 00:00:41 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAG80Uj09450 for ; Thu, 16 Nov 2000 00:00:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA01056 for ; Thu, 16 Nov 2000 00:00:25 -0800 (PST) Received: from starfruit.itojun.org (ny-ppp020.iij-us.net [216.98.99.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA20027 for ; Thu, 16 Nov 2000 00:00:22 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id D91747EF9; Thu, 16 Nov 2000 16:59:00 +0900 (JST) To: Mohit Goyal Cc: "'thomas.eklund@xelerated.com'" , "'Markku Savela'" , ipng@sunroof.eng.sun.com In-reply-to: Mohit.Goyal's message of Wed, 15 Nov 2000 15:23:34 PST. <39487C1D4449D41198960090270D93C00CB3CA@sa-can-ott-po.ottawa.siliconaccess.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: Regarding the Options headers From: Jun-ichiro itojun Hagino Date: Thu, 16 Nov 2000 16:59:00 +0900 Message-Id: <20001116075900.D91747EF9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >A quick question then: >How would you handle the cases where a Routing Header is to be processed? >In this case, the ROUTER has to go beyond the IPv6 header. Perhaps, even >processing a Hop by hop and/or destinations options header, prior to it >also. >It's tough to do in an ASIC, I agree. However, I still don't how you could >simply skip over the extension headers, and go directly to the transport >layer. I think the looping algorithm is your best option. >On a side note: typically, how many addresses would reside in the Routing >Header? I believe thomas would like to see more use of flow label, like for every TCP sessions. though there's no guarantee that flow label will identify each of TCP sessions (intermediate routes cannot trust the behavior of TCP endpoints), flow label should give thomas a good indication for doing layer 4 classification. 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 Nov 16 01:01:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAG8xix09512 for ipng-dist; Thu, 16 Nov 2000 00:59:44 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAG8xZj09504 for ; Thu, 16 Nov 2000 00:59:35 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA05812 for ; Thu, 16 Nov 2000 00:59:32 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28561 for ; Thu, 16 Nov 2000 00:59:30 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAG8xKb46466; Thu, 16 Nov 2000 09:59:21 +0100 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 JAA21125; Thu, 16 Nov 2000 09:59:20 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA89636; Thu, 16 Nov 2000 10:01:34 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011160901.KAA89636@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: thomas.eklund@xelerated.com cc: "'Steve Deering'" , "'Brian Zill'" , ipng@sunroof.eng.sun.com Subject: Re: Regarding the Options headers In-reply-to: Your message of Wed, 15 Nov 2000 17:32:15 +0100. <31A473DBB655D21180850008C71E251A02949259@mail.kebne.se> Date: Thu, 16 Nov 2000 10:01:34 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > but it becomes an issue when you implement IPv6 in asic!! > > => just don't do layer 4 classification in a router? > Seriously I expect to avoid a IPv4-like situation where > options are not > used because they are processed slowly then not used then... this is just to easy to say that. layer 4 classification will be used in the campus backbone/high-end enterprise and with the current solution it is very difficult to do it if you have any speed (we see 1GE links today and we will see even 10 GE links very soon) => today a standard box can't run at 1GE then I suppose your links are not the host-router links but already campus backbone links. There are no good definition of what is an edge router but it seems that the campus backbone is too fast, ie. edge devices are between hosts and the backbone. so it is an issue if we want ipv6 hot "hit" in the enterprise networks and campus networks... => if an ASIC can do layer >= 4 classification at the host-router link speed then this will work. Today hosts used in number crunching places are cheap dual-CPU PC boxes in clusters (according to what I saw at CERN) then it works. I don't believe we'll see again fast boxes with many high speed buses (mainframes are history, minis are history, workstations become history, ...) then the high-speed router camp should win. if we dont solve the problem that IPv4 routers do today we are on the wrong path... => I don't believe IPv6 has a real disavantage here, it is more a problem of "IPv6 is not yet here then don't put man power on it". Packets in the same flow are similar enough than the caching & hashing strategy works. One might argue that why not use intserv and treat the flowlabel as a intserv flow and let the router map several flow into traffic classes of aggregated traffic (DSCP classes) but then it is up to the flow label to decide and that is as we know undefined.... => this is what to do for core routers. There is and will be no other solutions because core routers need to be *fast*! > Have people thought about/What do people think about > changing the length > field > > => which one? The IPv6 header length field *is* useful and there is no > free space. I meant the Payload Length.... This is the whole point... I think you missed my point. => I had the wish I missed it. You can't reuse the payload length because it is *not* free. You propose to create a very different protocol with a different (likely larger) header... I wanted a chance to classify on the trnasport header without having to have a loop that first look into the first "next header" and then looks into the senocd extension header "next header" pointer and then look into the next one and in the next one... => the extension header chain is in the base design of IPv6: you want another protocol. BTW I'd like to know what is the transport header in VPNs (which are more and more common). > => I think nothing good of this. It is not the job of a > router to look at > inside packets (ESP will save us!) People that implement this in hardware see this problem TODAY... And of course if the packet is encrypted with an ESP then it is no use to classify on L4 but then we could have a flag in the flow label field that " signalled inband" that we have no way to do this, than we could aggregate this in the router and block any QoS related policy that included layer for instance... => QoS related policy that included layer >= 4 was proved as unfeasible in RSVP trials. The issue was more the unscalable nature of signaling than classification but in order to use QoS related policy you have to solve the untracktable signaling problem first... But in most cases there sits a firewall at the same place where we have the edge router and then the traffic comes unencrypted to the router => stop here. Even if today IPsec is VPN we expect in the future to have end-to-end IPsec. But if you believe there is a firewall then the firewall has the same problem (it wants to apply layer >= 4 filtering rules) then you can mark (DSCP + flow label) packets at the same place: or I don't understand your argument or we agree? and we might want to classify the traffic into a DSCP based on layer 4 info (As a side note: I have spoken to several operators that do exactly this way today for IPv4 >... Of course I'm in favour of having the edge routers classify the packets. => I believe the core routers are not able to classify the packets then my position is a bit more than "in favour". 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 Nov 16 01:46:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAG9idN09593 for ipng-dist; Thu, 16 Nov 2000 01:44:39 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAG9iUj09586 for ; Thu, 16 Nov 2000 01:44:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA21025 for ; Thu, 16 Nov 2000 01:44:30 -0800 (PST) Received: from zcamail01.zca.compaq.com (zcamail01.zca.compaq.com [161.114.32.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA13317 for ; Thu, 16 Nov 2000 01:44:29 -0800 (PST) Received: by zcamail01.zca.compaq.com (Postfix, from userid 12345) id 11809147C; Thu, 16 Nov 2000 01:45:40 -0800 (PST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zcamail01.zca.compaq.com (Postfix) with ESMTP id 8BCF915BA; Thu, 16 Nov 2000 01:45:39 -0800 (PST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id EAA0000859421; Thu, 16 Nov 2000 04:44:17 -0500 (EST) From: Jim Bound Message-Id: <200011160944.EAA0000859421@anw.zk3.dec.com> To: Richard Draves Cc: "IPng List (E-mail)" , bound@zk3.dec.com Subject: Re: APIs for controlling source address selection In-reply-to: Your message of "Tue, 14 Nov 2000 09:24:55 PST." <7695E2F6903F7A41961F8CF888D87EA81C9BBD@red-msg-06.redmond.corp.microsoft.com> Date: Thu, 16 Nov 2000 04:44:16 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, I do not want this in 2553bis. We are closing down this API for good. Future work will be done in XNET. What I suggest is you take it to the advanced API or create a new draft for these options. I have no comment on your proposal at this time. Other than on any good implementation of IPv6 for Servers and Routers the vendor needs to be able to permit the user to override the entire notion of source address selection, in your draft. I most likely will object to any MUSTS in this drafts anyway at last call. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 01:48:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAG9lsG09630 for ipng-dist; Thu, 16 Nov 2000 01:47:54 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAG9ljj09623 for ; Thu, 16 Nov 2000 01:47:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA10287 for ; Thu, 16 Nov 2000 01:47:44 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA26340 for ; Thu, 16 Nov 2000 02:47:43 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAG9lXb45636; Thu, 16 Nov 2000 10:47:34 +0100 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 KAA22142; Thu, 16 Nov 2000 10:47:32 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA89963; Thu, 16 Nov 2000 10:49:46 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011160949.KAA89963@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mohit Goyal cc: "'thomas.eklund@xelerated.com'" , "'Markku Savela'" , ipng@sunroof.eng.sun.com Subject: Re: Regarding the Options headers In-reply-to: Your message of Wed, 15 Nov 2000 15:23:34 PST. <39487C1D4449D41198960090270D93C00CB3CA@sa-can-ott-po.ottawa.siliconaccess.com> Date: Thu, 16 Nov 2000 10:49:46 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: A quick question then: How would you handle the cases where a Routing Header is to be processed? => I don't understand your argument. A routing header is to be processed only if the destination address (in the IPv6 header, the router can't do something without looking at it :-) is one of the router addresses. On a side note: typically, how many addresses would reside in the Routing Header? => one but you can have more or less: - one if it is for mobile IPv6 routing optimization - zero if it is in order to crash your friend implementation (:-) - some if it is for another usage (some kind of policy routing, in this case some addresses will be subnet anycasts). The maximal number is 127 addresses but should have the same effect than zero! Francis.Dupont@enst-bretagne.fr PS: your argument is valid for a firewall: inspection should be implemented by a loop. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 01:54:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAG9rG609660 for ipng-dist; Thu, 16 Nov 2000 01:53:16 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAG9r7j09653 for ; Thu, 16 Nov 2000 01:53:07 -0800 (PST) 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,v1.7) with ESMTP id BAA16462 for ; Thu, 16 Nov 2000 01:53:07 -0800 (PST) Received: from zcamail02.zca.compaq.com (zcamail02.zca.compaq.com [161.114.32.102]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18568 for ; Thu, 16 Nov 2000 01:53:07 -0800 (PST) Received: by zcamail02.zca.compaq.com (Postfix, from userid 12345) id 31ED57664; Thu, 16 Nov 2000 01:53:12 -0800 (PST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zcamail02.zca.compaq.com (Postfix) with ESMTP id 77C8A751F; Thu, 16 Nov 2000 01:53:11 -0800 (PST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id EAA0000861084; Thu, 16 Nov 2000 04:52:59 -0500 (EST) From: Jim Bound Message-Id: <200011160952.EAA0000861084@anw.zk3.dec.com> To: Steve Deering Cc: Brian Zill , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: Mutable fields and the Hop-by-Hop and Destination Options headers In-reply-to: Your message of "Tue, 14 Nov 2000 21:40:38 PST." Date: Thu, 16 Nov 2000 04:52:59 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, Coudn't we do what Brian wants or with your suggestion with a BCP rather than messing with 2460.? I would not hold up 2460 to IS for this changed. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 01:57:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAG9tiX09678 for ipng-dist; Thu, 16 Nov 2000 01:55:44 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAG9tZj09671 for ; Thu, 16 Nov 2000 01:55:35 -0800 (PST) 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,v1.7) with ESMTP id BAA21871 for ; Thu, 16 Nov 2000 01:55:35 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA19073 for ; Thu, 16 Nov 2000 01:55:34 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 4AB5DA41B; Thu, 16 Nov 2000 04:55:34 -0500 (EST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 0EAB5A6A2; Thu, 16 Nov 2000 04:55:34 -0500 (EST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id EAA0000861157; Thu, 16 Nov 2000 04:55:27 -0500 (EST) From: Jim Bound Message-Id: <200011160955.EAA0000861157@anw.zk3.dec.com> To: "Markku Savela" Cc: "IPng List (E-mail)" , bound@zk3.dec.com Subject: Re: APIs for controlling source address selection In-reply-to: Your message of "Wed, 15 Nov 2000 10:59:55 +0200." <000101c04ee2$6ceb4fb0$e82815ac@hews0169nrc.research.nokia.com> Date: Thu, 16 Nov 2000 04:55:26 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I like the idea of a selector API greatlly. This could be a new piece of work we need too. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 02:01:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGA05309719 for ipng-dist; Thu, 16 Nov 2000 02:00:05 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAG9xtj09712 for ; Thu, 16 Nov 2000 01:59:55 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA11029 for ; Thu, 16 Nov 2000 01:59:55 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA20182 for ; Thu, 16 Nov 2000 01:59:53 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAG9uAb37919; Thu, 16 Nov 2000 10:56:10 +0100 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 KAA22363; Thu, 16 Nov 2000 10:56:07 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA90047; Thu, 16 Nov 2000 10:58:21 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011160958.KAA90047@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jun-ichiro itojun Hagino cc: "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of Thu, 16 Nov 2000 04:09:19 +0900. <20001115190919.321B17EF9@starfruit.itojun.org> Date: Thu, 16 Nov 2000 10:58:21 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: flow label field is not part of AH calculation, but as RSVP already requires it to be end-to-end (not hop-by-hop) i think we shouldn't rewrite it in transit. => I don't read your argument as you. I'll say it should not be rewritten in transit if RSVP is in use. A DiffServ edge router can rewrite it in some situation (it is supposed to know what is RSVP and do the right thing). Don't forget that in the real world RSVP is not end-to-end and is managed by smart edge routers, this comes more from practice (the end user doesn't know how to use RSVP, the edge router manager knows) than from deep design... 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 Nov 16 02:05:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGA4Tp09746 for ipng-dist; Thu, 16 Nov 2000 02:04:29 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGA4Kj09739 for ; Thu, 16 Nov 2000 02:04:20 -0800 (PST) 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,v1.7) with ESMTP id CAA22568 for ; Thu, 16 Nov 2000 02:04:19 -0800 (PST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21094 for ; Thu, 16 Nov 2000 02:04:18 -0800 (PST) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA20798; Thu, 16 Nov 2000 11:03:50 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA03019; Thu, 16 Nov 2000 11:04:16 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Nov 2000 11:04:15 +0100 Message-ID: <158669A6D0F5D3119B940060086D94F55006BB@ULML202E> From: Metzler Jochen To: "'Francis Dupont'" , Jun-ichiro itojun Hagino Cc: "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" Subject: AW: Usage of IPv6 flow label Date: Thu, 16 Nov 2000 11:04:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id eAGA4Kj09740 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Can you explain to me what the matter with DiffServ is? I assumed that DiffServ makes use of the ToS field and not of the flow label? -- jochen -----Ursprüngliche Nachricht----- Von: Francis Dupont [SMTP:Francis.Dupont@enst-bretagne.fr] Gesendet am: Donnerstag, 16. November 2000 10:58 An: Jun-ichiro itojun Hagino Cc: Hesham Soliman (EPA); Metzler Jochen; Ipng (E-Mail) Betreff: Re: Usage of IPv6 flow label In your previous mail you wrote: flow label field is not part of AH calculation, but as RSVP already requires it to be end-to-end (not hop-by-hop) i think we shouldn't rewrite it in transit. => I don't read your argument as you. I'll say it should not be rewritten in transit if RSVP is in use. A DiffServ edge router can rewrite it in some situation (it is supposed to know what is RSVP and do the right thing). Don't forget that in the real world RSVP is not end-to-end and is managed by smart edge routers, this comes more from practice (the end user doesn't know how to use RSVP, the edge router manager knows) than from deep design... 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 Nov 16 02:08:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGA7Ri09768 for ipng-dist; Thu, 16 Nov 2000 02:07:27 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGA7Ij09761 for ; Thu, 16 Nov 2000 02:07:19 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA22745 for ; Thu, 16 Nov 2000 02:07:19 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16866 for ; Thu, 16 Nov 2000 02:07:18 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 3BDEB55D6; Thu, 16 Nov 2000 05:07:18 -0500 (EST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id DA0CA5656; Thu, 16 Nov 2000 05:07:14 -0500 (EST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id FAA0000861930; Thu, 16 Nov 2000 05:07:08 -0500 (EST) From: Jim Bound Message-Id: <200011161007.FAA0000861930@anw.zk3.dec.com> To: Metzler Jochen Cc: "Ipng (E-Mail)" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Wed, 15 Nov 2000 12:55:42 +0100." <158669A6D0F5D3119B940060086D94F55006B4@ULML202E> Date: Thu, 16 Nov 2000 05:07:08 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jochen, The flow label is used in RSVP with IPv6 and we have implemented it. I believe it could be used as b-service for 3GPP but you need to make proposal to this list. If you need implementation input let me know offline. ALso there are other than 3GPP users that want to do the same thing that will need to identify b-services. I can discuss with you offline. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 03:07:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGB5nr09840 for ipng-dist; Thu, 16 Nov 2000 03:05:49 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGB5dj09833 for ; Thu, 16 Nov 2000 03:05:40 -0800 (PST) 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,v1.7) with ESMTP id DAA19900 for ; Thu, 16 Nov 2000 03:05:39 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03680 for ; Thu, 16 Nov 2000 03:05:38 -0800 (PST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VTFR5LPN; Thu, 16 Nov 2000 12:05:37 +0100 Reply-To: From: "Thomas Eklund" To: Cc: "'Steve Deering'" , "'Brian Zill'" , Subject: RE: Regarding the Options headers Date: Thu, 16 Nov 2000 12:05:29 +0100 Message-ID: <31A473DBB655D21180850008C71E251A02949260@mail.kebne.se> 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 In-Reply-To: <31A473DBB655D21180850008C71E251A02E90CF4@mail.kebne.se> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Francis, > > => just don't do layer 4 classification in a router? > > Seriously I expect to avoid a IPv4-like situation where > > options are not > > used because they are processed slowly then not used then... What you are saying might be ONE way of doing it, but I have talked to several ISP that use this today in the access - what do you say to them? Invent a new protocol or something else? Note in ipv4 you have a protocol field that could be used to determine the offset in the packet for TCP and you dont have that option in ipv6. ok, most of the info is parsed at the destination in destination options for ipv6 and the whole idea is to only parse the basic header along the path. but there are many scenarios where this is not enough and people want to have a chance to classify on layer 4 > => today a standard box can't run at 1GE then I suppose your My box do. And Apple's new computer is shipping with GE interfaces for instance... > links are not > the host-router links but already campus backbone links. > There are no good > definition of what is an edge router but it seems that the > campus backbone > is too fast, ie. edge devices are between hosts and the backbone. If you look at figures from Garter Group, IDC, DellOro, you see a trend that GE will enter the LAN market very fast... just like FE entered the market fast when it come and people used the same cabling but upgraded from 10 Mb to FE. > I meant the Payload Length.... This is the whole point... > I think you missed > my point. > > => I had the wish I missed it. You can't reuse the payload > length because > it is *not* free. You propose to create a very different protocol with > a different (likely larger) header... Yes - with a chance to make a deterministic implementation of it in asic, np etc... > > I wanted a chance to classify on the trnasport header > without having to have > a loop that first look into the first "next header" and > then looks into the > senocd extension header "next header" pointer and then > look into the next > one and in the next one... > > => the extension header chain is in the base design of IPv6: you want > another protocol. BTW I'd like to know what is the transport header > in VPNs (which are more and more common). I know - and I'm not proposing any change of it! Simply a change of the interpretation of the length field which would have many benefits when you implement it in hw. But once again - most of the ISP's I spoken to run vpn with mpls and build there network in a very pragmatic way (mostly based on over provisioning) and dont use esp for instance... But if you would base your VPN on ipsec with both ah and esp then you probably want to have the vpn endpoint as close to the CPE as possible (where there is no speed) and then you will need a way of managing the vpn further up in the backbone which would require some kind of tag (mpls, flow label etc) and some might also want to do traffic engineering to improve the availability of the vpn... > > => I think nothing good of this. It is not the job of a > > router to look at > > inside packets (ESP will save us!) This trend is driven from the operators and the router vendors ingrate more and more into its boxes... You need to look into the packet at every edge (backbone/WAN edge, MAN edge, LAN edge/access edge etc.) This is also a natural way to go when you go up in speeds. > > People that implement this in hardware see this problem TODAY... > And of course if the packet is encrypted with an ESP then > it is no use to > classify on L4 but then we could have a flag in the flow > label field that " > signalled inband" that we have no way to do this, than we > could aggregate > this in the router and block any QoS related policy that > included layer for > instance... > > => QoS related policy that included layer >= 4 was proved as > unfeasible > in RSVP trials. Dont mix the RSVP/intserv based approach with layer 4 classification possibilities in a full MF classifier... > But in most cases there sits a firewall at the same place > where we have the > edge router and then the traffic comes unencrypted to the router > > => stop here. Even if today IPsec is VPN we expect in the > future to have > end-to-end IPsec. I'm a believer of the en-to-end model as well but that was NOT the issue here. > But if you believe there is a firewall then the firewall has the same > problem (it wants to apply layer >= 4 filtering rules) then you can > mark (DSCP + flow label) packets at the same place: or I > don't understand > your argument or we agree? This would probably be one out many solutions... And as I said before since this is not standardised today then the operators label their traffic with 802.1Q tag, mpls tag or something else just to achive this.. > => I believe the core routers are not able to classify the > packets then > my position is a bit more than "in favour". I was not talking about core routers... -- 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 Nov 16 03:07:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGB6fn09849 for ipng-dist; Thu, 16 Nov 2000 03:06:41 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGB6Sj09842 for ; Thu, 16 Nov 2000 03:06:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA15319 for ; Thu, 16 Nov 2000 03:06:27 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA04603 for ; Thu, 16 Nov 2000 04:06:25 -0700 (MST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VTFR5LP5; Thu, 16 Nov 2000 12:06:29 +0100 Reply-To: From: "Thomas Eklund" To: "'Jun-ichiro itojun Hagino'" , "'Mohit Goyal'" Cc: "'Markku Savela'" , Subject: RE: Regarding the Options headers Date: Thu, 16 Nov 2000 12:06:27 +0100 Message-ID: <31A473DBB655D21180850008C71E251A02949261@mail.kebne.se> 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 In-Reply-To: <31A473DBB655D21180850008C71E251A02E90CCC@mail.kebne.se> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Itojun, > I believe thomas would like to see more use of flow label, like > for every TCP sessions. though there's no guarantee > that flow label > will identify each of TCP sessions (intermediate routes > cannot trust > the behavior of TCP endpoints), flow label should give thomas > a good indication for doing layer 4 classification. > > itojun What I said is that since the flow label is unassigned people are classifying their in their acces based on l4 info as well in the classification... I would on the other hand not object if in where mandatory for a host to set its flow label... -- 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 Nov 16 03:24:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGBNSb09899 for ipng-dist; Thu, 16 Nov 2000 03:23:28 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGBNJj09892 for ; Thu, 16 Nov 2000 03:23:19 -0800 (PST) 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,v1.7) with ESMTP id DAA23002 for ; Thu, 16 Nov 2000 03:23:18 -0800 (PST) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA06958 for ; Thu, 16 Nov 2000 03:23:18 -0800 (PST) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id 23879CBE; Thu, 16 Nov 2000 05:23:18 -0600 (CST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 64ACCF86; Thu, 16 Nov 2000 05:23:17 -0600 (CST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id GAA0000868045; Thu, 16 Nov 2000 06:22:53 -0500 (EST) From: Jim Bound Message-Id: <200011161122.GAA0000868045@anw.zk3.dec.com> To: Francis Dupont Cc: Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Thu, 16 Nov 2000 10:58:21 +0100." <200011160958.KAA90047@givry.rennes.enst-bretagne.fr> Date: Thu, 16 Nov 2000 06:22:53 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, You bring up a point that is critical regarding the flow and something I am looking at now. How and when is the flow label used. Like you state when RSVP is being used we should not aloter the flowlabel. I don't want to use up bits in the flowlabel to identify the type of packet and I don't think we can count on next header value. That is why I send mail stating I liked the idea of a "selector" in an API. But how we convey that to the routing layer is the magic we need. God forgive me but I am playing with the use of a state machine for the network layer which will also be useful for site/scopes and anycast for Hosts. :---) /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 04:28:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGCQxK09980 for ipng-dist; Thu, 16 Nov 2000 04:26:59 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGCQoj09973 for ; Thu, 16 Nov 2000 04:26:50 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA21678 for ; Thu, 16 Nov 2000 04:26:49 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00131 for ; Thu, 16 Nov 2000 04:26:46 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAGCN0b22198; Thu, 16 Nov 2000 13:23:00 +0100 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 NAA27314; Thu, 16 Nov 2000 13:22:58 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id NAA90604; Thu, 16 Nov 2000 13:25:12 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011161225.NAA90604@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Metzler Jochen cc: Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , "Ipng (E-Mail)" Subject: Re: AW: Usage of IPv6 flow label In-reply-to: Your message of Thu, 16 Nov 2000 11:04:12 +0100. <158669A6D0F5D3119B940060086D94F55006BB@ULML202E> Date: Thu, 16 Nov 2000 13:25:12 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Can you explain to me what the matter with DiffServ is? I assumed that DiffServ makes use of the ToS field and not of the flow label? => a part of this comes from a collision with a discussion initiated by Thomas Eklund about DSCP and flow label marking... The notion of edge routers is in the DiffServ architecture not in the IntServ/RSVP one, and the same for the idea to mark packets by edge routers and to use marks on core routers, but of course these ideas can be (and are) used by RSVP too. 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 Nov 16 04:46:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGCjg910020 for ipng-dist; Thu, 16 Nov 2000 04:45:42 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGCjXj10013 for ; Thu, 16 Nov 2000 04:45:33 -0800 (PST) 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,v1.7) with ESMTP id EAA29632 for ; Thu, 16 Nov 2000 04:45:32 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25219 for ; Thu, 16 Nov 2000 04:45:30 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAGCjNb48749; Thu, 16 Nov 2000 13:45:24 +0100 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 NAA28232; Thu, 16 Nov 2000 13:45:23 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id NAA90728; Thu, 16 Nov 2000 13:47:37 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011161247.NAA90728@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: thomas.eklund@xelerated.com cc: "'Steve Deering'" , "'Brian Zill'" , ipng@sunroof.eng.sun.com Subject: Re: Regarding the Options headers In-reply-to: Your message of Thu, 16 Nov 2000 12:05:29 +0100. <31A473DBB655D21180850008C71E251A02949260@mail.kebne.se> Date: Thu, 16 Nov 2000 13:47:37 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => today a standard box can't run at 1GE then I suppose your My box do. And Apple's new computer is shipping with GE interfaces for instance... => standard boxes with a standard PCI can't go at 1Gbits/s. There is a difference between to put a giga Ethernet board in a box and to go at 1 Gbits/s. I know this will be fixed (I'd like ASAP) but the gap between standard boxes and ASIC is enough to be able to use ASICs for hard things at standard box speed. And I believe this will be true in the long term then the issue is hard things can be done only by edge devices and not in the core, but we know that (as I said this is the IntServ/DiffServ lesson). If you look at figures from Garter Group, IDC, DellOro, you see a trend that GE will enter the LAN market very fast... => where? I know GE for campus backbones but GE is not very common for hosts (for three reasons today: fibers are expensive (will change when copper GE will be common), boards are expensive (will change when GE will spread enough) and PCI bus is too slow (will change when chipsets will be improved but (this is a shame, I agree) this seems to take time)). just like FE entered the market fast when it come and people used the same cabling but upgraded from 10 Mb to FE. => the same cabling hypothesis seems less likely for GE. > => I had the wish I missed it. You can't reuse the payload > length because > it is *not* free. You propose to create a very different protocol with > a different (likely larger) header... Yes - with a chance to make a deterministic implementation of it in asic, np etc... => (I have not the answer) Is a discussion about a new protocol in the scope of this list? > > => I think nothing good of this. It is not the job of a > > router to look at > > inside packets (ESP will save us!) This trend is driven from the operators and the router vendors ingrate more and more into its boxes... You need to look into the packet at every edge (backbone/WAN edge, MAN edge, LAN edge/access edge etc.) This is also a natural way to go when you go up in speeds. => I don't understand, I believed you should do simpler and simpler things when you want/need to be faster and faster, not the opposite. > => I believe the core routers are not able to classify the > packets then > my position is a bit more than "in favour". I was not talking about core routers... => oc-768 isn't for core routers? I don't understand your arguments... 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 Nov 16 04:53:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGCqBi10072 for ipng-dist; Thu, 16 Nov 2000 04:52:11 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGCq2j10065 for ; Thu, 16 Nov 2000 04:52:02 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA23667 for ; Thu, 16 Nov 2000 04:52:01 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA07689 for ; Thu, 16 Nov 2000 04:52:00 -0800 (PST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VTFR5MRL; Thu, 16 Nov 2000 13:52:00 +0100 Reply-To: From: "Thomas Eklund" To: "'Francis Dupont'" , "'Metzler Jochen'" Cc: "'Jun-ichiro itojun Hagino'" , "'Hesham Soliman \(EPA\)'" , "'Ipng \(E-Mail\)'" Subject: RE: AW: Usage of IPv6 flow label Date: Thu, 16 Nov 2000 13:51:51 +0100 Message-ID: <31A473DBB655D21180850008C71E251A02949268@mail.kebne.se> 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 In-Reply-To: <31A473DBB655D21180850008C71E251A02E91010@mail.kebne.se> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Note my comment was NOT bound to either diffserv or intserv. It was a discusson on the IP header structure and things that might become an issue when v6 gets more deployed (which means it will run in both asic's and np's as well). My suggestion was an issue that is related to determinism to achieche QoS but the same classification mechanism is used in packet filterering firewalls (that might alsoi have a counter associated - i.e stateful inspection) as well. This problems arise from existing memory contraints (and at least future constraints within 2-3 years from now). But it was a question/issue raised from me if people shared my concerns. -- thomas > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Francis Dupont > Sent: den 16 november 2000 13:25 > To: Metzler Jochen > Cc: Jun-ichiro itojun Hagino; Hesham Soliman (EPA); Ipng (E-Mail) > Subject: Re: AW: Usage of IPv6 flow label > > > In your previous mail you wrote: > > Can you explain to me what the matter with DiffServ is? > I assumed that DiffServ makes use of the ToS field and > not of the flow label? > > => a part of this comes from a collision with a discussion initiated > by Thomas Eklund about DSCP and flow label marking... > The notion of edge routers is in the DiffServ architecture not in > the IntServ/RSVP one, and the same for the idea to mark packets > by edge routers and to use marks on core routers, but of course > these ideas can be (and are) used by RSVP too. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 05:06:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGD5Eh10099 for ipng-dist; Thu, 16 Nov 2000 05:05:14 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGD54j10092 for ; Thu, 16 Nov 2000 05:05:05 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA01471 for ; Thu, 16 Nov 2000 05:05:04 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA13768 for ; Thu, 16 Nov 2000 05:05:03 -0800 (PST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VTFR5MWX; Thu, 16 Nov 2000 14:05:07 +0100 Reply-To: From: "Thomas Eklund" To: "'Francis Dupont'" Cc: "'Steve Deering'" , "'Brian Zill'" , Subject: RE: Regarding the Options headers Date: Thu, 16 Nov 2000 14:05:00 +0100 Message-ID: <31A473DBB655D21180850008C71E251A02949269@mail.kebne.se> 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 In-Reply-To: <31A473DBB655D21180850008C71E251A02E9105E@mail.kebne.se> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, just a short comment - if you would like to continue to misunderstand me thats fine, but I'm telling you that there are people having problems out there TODAY. What we do have in common is that we share the same vision about ipv6 but I think that we are experincing different problems and to be frank I dont think you understand my concers buts thats fine - there are others that do. > If you look at figures from Garter Group, IDC, DellOro, > you see a trend that > GE will enter the LAN market very fast... > > => where? I know GE for campus backbones but GE is not very common for > hosts (for three reasons today: fibers are expensive (will change when > copper GE will be common), boards are expensive (will change > when GE will > spread enough) and PCI bus is too slow (will change when chipsets will > be improved but (this is a shame, I agree) this seems to take time)). And if you look in my answer I was talking about campus backbones! As a side note, many operators are bulding a new infrastructure for residential access and they are using fiber in many cases to the household... -- 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 Nov 16 05:39:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGDcST10123 for ipng-dist; Thu, 16 Nov 2000 05:38:28 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGDcJj10116 for ; Thu, 16 Nov 2000 05:38:19 -0800 (PST) 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,v1.7) with ESMTP id FAA04274 for ; Thu, 16 Nov 2000 05:38:20 -0800 (PST) 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 FAA06159 for ; Thu, 16 Nov 2000 05:38:19 -0800 (PST) Received: from localhost ([3ffe:501:100f:10c1:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id WAA04928 for ; Thu, 16 Nov 2000 22:24:24 +0900 (JST) Date: Thu, 16 Nov 2000 22:37:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option In-Reply-To: In your message of "Tue, 14 Nov 2000 09:42:19 +0100" <200011140842.JAA77413@givry.rennes.enst-bretagne.fr> References: <200011140842.JAA77413@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 14 Nov 2000 09:42:19 +0100, >>>>> Francis Dupont said: > In your previous mail you wrote: > I'm now considering UDP applications that are sensitive to path MTU > (toward the destinations). I recalled a discussion about a new socket > option "IPV6_USEMTU", which allowed an application to specify an > appropriate path MTU for packets sent from the application. I checked > the archive of this list in April 2000, and, to my suprise, the > discussion suddenly disappeared without any consensus. > => today only IPV6_USE_MIN_MTU seems to be defined, implemented and > used (for instance by BIND and racoon, the KAME IKE daemon). > I don't know if IPV6_USEMTU as you define is very useful but the > getsockopt() counterpart (which gives the actual path MTU) *is* useful. > Perhaps the getsockopt() with a standard way to disable fragmentation > is enough (it should be enough for a traceroute_pmtu6)? My main concern is about UDP applications that can't divide outgoing data into multiple packets but do not want to fragment the packet in a (much) smaller size than the path MTU. Possible examples would be NFS and DHCP. I admit that NFS may not be a good example, because in UNIX systems, NFS is typically implemented in the kernel. 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 Nov 16 05:42:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGDfP010141 for ipng-dist; Thu, 16 Nov 2000 05:41:25 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGDfFj10134 for ; Thu, 16 Nov 2000 05:41:15 -0800 (PST) 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,v1.7) with ESMTP id FAA09136 for ; Thu, 16 Nov 2000 05:41:16 -0800 (PST) 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 FAA06789 for ; Thu, 16 Nov 2000 05:41:13 -0800 (PST) Received: from localhost ([3ffe:501:100f:10c1:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id WAA04937; Thu, 16 Nov 2000 22:26:56 +0900 (JST) Date: Thu, 16 Nov 2000 22:40:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Yves Legrandgerard Cc: Francis Dupont , ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option In-Reply-To: In your message of "Tue, 14 Nov 2000 10:43:32 +0100 (CET)" References: <200011140842.JAA77413@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 14 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 14 Nov 2000 10:43:32 +0100 (CET), >>>>> Yves Legrandgerard said: > I agree, we need two things: > 1) a new option for getsockopt() to get the actual path MTU (there is no > standard way to do that). Applications can dynamically grab the path MTU by the IPV6_RECVPATHMTU socket option (upon receiving an ICMPv6 packet toobig error). 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 Nov 16 05:54:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGDrRj10176 for ipng-dist; Thu, 16 Nov 2000 05:53:27 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGDrHj10169 for ; Thu, 16 Nov 2000 05:53:18 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA10121; Thu, 16 Nov 2000 05:53:18 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26753; Thu, 16 Nov 2000 05:53:17 -0800 (PST) Received: from localhost ([3ffe:501:100f:10c1:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id WAA05004; Thu, 16 Nov 2000 22:39:08 +0900 (JST) Date: Thu, 16 Nov 2000 22:52:31 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU In-Reply-To: In your message of "Thu, 09 Nov 2000 01:32:54 +0900" References: <200011071100.MAA47016@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 45 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 09 Nov 2000 01:32:54 +0900, >>>>> JINMEI Tatuya said: >> Does the implementors have any preferences between #2 and #3? >> Doing #3 would require defining a data structure containing an MTU field >> plus a socketaddr_in6. >> => by problem with #3 is the path MTU is a property of the path, not >> of an address, ie. with a routing header the path MTU can be different. >> I know this is not implemented like that (ie. pMTU are cached by destination >> address and if someone plays with a routing header one can spuriously >> change the pMTU :-) but it should then we have to keep the distinction... > I personally like #3, because it seems the most flexible one (e.g. to > contain the real "path" including all intermediate nodes - although > I'm not sure if this kind of stuff is worth implementing despite of > its complexity). But this will affect existing implementations, so I > won't insist on this idea. I vote for #3 if pre-implementors of this > option do not object. (We've not implemented this option yet.) I've implemented the IPV6_RECVPATHMTU option adopting #3 approach. I defined a new structure "ip6_mtuinfo" as ancillary data item for IPV6_PATHMTU as follows: struct ip6_mtuinfo { u_int32_t ip6mtu_mtu; struct sockaddr_in6 ip6mtu_dst; }; I used the sockaddr_in6 structure for the ip6mtu_dst (not just in6_addr) in order to support scoped addresses. As Francis pointed out, the finally destination does not necessarily give complete information of a "path", but I think it is usually enough in a practical point of view. We could also add some additional data after the ip6mtu_dst if we wanted. By the way, the rfc2292bis draft seems a bit ambiguous on the byte order of the 32-bit MTU value. Like other fields used in the spec, I treated the value in the network byte order, but the spec should clearly specify the byte order. 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 Nov 16 05:57:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGDuqH10194 for ipng-dist; Thu, 16 Nov 2000 05:56:52 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGDuhj10187 for ; Thu, 16 Nov 2000 05:56:43 -0800 (PST) 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,v1.7) with ESMTP id FAA10348 for ; Thu, 16 Nov 2000 05:56:44 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA00492 for ; Thu, 16 Nov 2000 06:56:42 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAGDuPb46366; Thu, 16 Nov 2000 14:56:26 +0100 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 OAA01321; Thu, 16 Nov 2000 14:56:25 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id OAA91320; Thu, 16 Nov 2000 14:58:40 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011161358.OAA91320@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: thomas.eklund@xelerated.com cc: "'Steve Deering'" , "'Brian Zill'" , ipng@sunroof.eng.sun.com Subject: Re: Regarding the Options headers In-reply-to: Your message of Thu, 16 Nov 2000 14:05:00 +0100. <31A473DBB655D21180850008C71E251A02949269@mail.kebne.se> Date: Thu, 16 Nov 2000 14:58:40 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Francis, just a short comment - if you would like to continue to misunderstand me thats fine, but I'm telling you that there are people having problems out there TODAY. => what I have understood of your issue is the IPv6 protocol with its extension header chain defined today makes layer >= 4 classification hard or impossible at very high speed. This is true (then I don't really misunderstand you :-) but the real question is whether it is a real issue (ie. something we need to solve) or not, my argument is the classification should be done by edge routers and not by core routers. Then there are two different points: - does the issue remain if edge routers are closed enough to hosts: * an interface only (for direct connections) * line speed limited at least by available stock hardware * low or at least reasonable number of flows? I believe the issue doesn't remain just because for many reasons stock hardware had, has and will have poor I/O performances - is it possible to put edge routers closed enough: * technical constraints: I can't see one? * price constraints: with ASICs we are supposed to do it cheaply? * policy constraints: I am sorry to have to say that but it is the job of a ISP to look at inside packets of its customers. It is why I said ESP will save us. Of course this should be the point where we have a very different opinion, in the past my current ISP decided the Web was mainly pornography and tried to limit the bandwidth for a particular TCP port... I have talked about firewalls because: - they shared the same issue but they have to do something a bit harder (BTW I think a solution which works for routers and not for firewalls will have a problem in the future: there are (too) many ISPs which put firewalls to protect (against) customers) - they (will?) use ASICs when high performances are needed - they share the management issue, security policies are even more critical than QoS policies (a mistake for instance has worse consequences). What we do have in common is that we share the same vision about ipv6 but I think that we are experincing different problems and to be frank I dont think you understand my concers buts thats fine - there are others that do. => do you want a private or a public answer (:-)? As a side note, many operators are bulding a new infrastructure for residential access and they are using fiber in many cases to the household... => I don't believe they want to give a cheap giga Ethernet per access with an usable 1Gbits/s (or I'll move to this place). 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 Nov 16 06:06:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGE4kx10225 for ipng-dist; Thu, 16 Nov 2000 06:04:46 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGE4aj10218 for ; Thu, 16 Nov 2000 06:04:36 -0800 (PST) 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,v1.7) with ESMTP id GAA03660; Thu, 16 Nov 2000 06:04:36 -0800 (PST) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12031; Thu, 16 Nov 2000 06:04:35 -0800 (PST) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.11.0+3.3W/8.11.1/Debian 8.11.0-6) with ESMTP id eAGE41p10375; Thu, 16 Nov 2000 23:04:01 +0900 To: jinmei@isl.rdc.toshiba.co.jp Cc: Francis.Dupont@enst-bretagne.fr, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU In-Reply-To: References: <200011071100.MAA47016@givry.rennes.enst-bretagne.fr> X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Message-Id: <20001116230401T.yoshfuji@ecei.tohoku.ac.jp> Date: Thu, 16 Nov 2000 23:04:01 +0900 From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) X-Dispatcher: imput version 990905(IM130) Lines: 16 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article (at Thu, 16 Nov 2000 22:52:31 +0900), JINMEI Tatuya / $B?@L@C#:H(B says: > I've implemented the IPV6_RECVPATHMTU option adopting #3 approach. I > defined a new structure "ip6_mtuinfo" as ancillary data item for > IPV6_PATHMTU as follows: > > struct ip6_mtuinfo { > u_int32_t ip6mtu_mtu; > struct sockaddr_in6 ip6mtu_dst; > }; How do you think about alignment? -- Hideaki YOSHIFUJI @ USAGI Project PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 06:14:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGEDus10251 for ipng-dist; Thu, 16 Nov 2000 06:13:56 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGEDlj10244 for ; Thu, 16 Nov 2000 06:13:47 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA07789 for ; Thu, 16 Nov 2000 06:13:48 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA16951 for ; Thu, 16 Nov 2000 06:13:46 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id GAA03145; Thu, 16 Nov 2000 06:06:03 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA05946; Thu, 16 Nov 2000 06:06:03 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14867.59850.899996.178063@thomasm-u1.cisco.com> Date: Thu, 16 Nov 2000 06:06:02 -0800 (PST) To: Francis Dupont Cc: Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label In-Reply-To: <200011160958.KAA90047@givry.rennes.enst-bretagne.fr> References: <20001115190919.321B17EF9@starfruit.itojun.org> <200011160958.KAA90047@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont writes: > In your previous mail you wrote: > > flow label field is not part of AH calculation, but as RSVP already > requires it to be end-to-end (not hop-by-hop) i think we shouldn't > rewrite it in transit. > > => I don't read your argument as you. I'll say it should not be rewritten > in transit if RSVP is in use. A DiffServ edge router can rewrite it > in some situation (it is supposed to know what is RSVP and do the right > thing). Why would a diffserv router _want_ to rewrite a flow label? It can still rewrite the DSCP if it wants. The only thing that I've seen mentioned that could actually take advantage in the way you are mentioning is using the flow label for MPLS label swapping bits. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 06:15:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGEEgv10260 for ipng-dist; Thu, 16 Nov 2000 06:14:42 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGEESj10253 for ; Thu, 16 Nov 2000 06:14:28 -0800 (PST) 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,v1.7) with ESMTP id GAA04468 for ; Thu, 16 Nov 2000 06:14:29 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14308 for ; Thu, 16 Nov 2000 06:14:28 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id GAA03215; Thu, 16 Nov 2000 06:14:26 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA05949; Thu, 16 Nov 2000 06:14:26 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14867.60354.125664.657991@thomasm-u1.cisco.com> Date: Thu, 16 Nov 2000 06:14:26 -0800 (PST) To: "Hesham Soliman (EPA)" Cc: "'Michael Thomas'" , "Ipng (E-Mail)" Subject: RE: Usage of IPv6 flow label In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A50C613E05@eaubrnt018.epa.ericsson.se> References: <4B6BC00CD15FD2119E5F0008C7A419A50C613E05@eaubrnt018.epa.ericsson.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham Soliman (EPA) writes: > > Hesham Soliman (EPA) writes: > > > => It is also used in the GGSN (default router in IPv6 land) > > > as one of the options to identify a flow and make the right > > > QoS decisions. > > > The router is informed by the IPv6 node about > > > the flow label value for each connection. > > > > Er, by what protocol does it inform the router? > > > => A 3GPP protocol. Which is different from an IETF protocol? Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 06:42:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGEehE10321 for ipng-dist; Thu, 16 Nov 2000 06:40:43 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGEeYj10314 for ; Thu, 16 Nov 2000 06:40:34 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA04783; Thu, 16 Nov 2000 06:40:34 -0800 (PST) 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 HAA23918; Thu, 16 Nov 2000 07:40:31 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id XAA05204; Thu, 16 Nov 2000 23:26:20 +0900 (JST) Date: Thu, 16 Nov 2000 23:39:42 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Hideaki YOSHIFUJI (=?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?=) Cc: Francis.Dupont@enst-bretagne.fr, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU In-Reply-To: In your message of "Thu, 16 Nov 2000 23:04:01 +0900" <20001116230401T.yoshfuji@ecei.tohoku.ac.jp> References: <200011071100.MAA47016@givry.rennes.enst-bretagne.fr> <20001116230401T.yoshfuji@ecei.tohoku.ac.jp> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 21 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 16 Nov 2000 23:04:01 +0900, >>>>> Hideaki YOSHIFUJI said: >> I've implemented the IPV6_RECVPATHMTU option adopting #3 approach. I >> defined a new structure "ip6_mtuinfo" as ancillary data item for >> IPV6_PATHMTU as follows: >> >> struct ip6_mtuinfo { >> u_int32_t ip6mtu_mtu; >> struct sockaddr_in6 ip6mtu_dst; >> }; > How do you think about alignment? Currently, I only consider 32-bit alignment, but I'm open to hear others' opinions. 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 Nov 16 07:02:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGEvCT10383 for ipng-dist; Thu, 16 Nov 2000 06:57:12 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGEuxj10376 for ; Thu, 16 Nov 2000 06:57:00 -0800 (PST) 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,v1.7) with ESMTP id GAA16435 for ; Thu, 16 Nov 2000 06:57:00 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA04654 for ; Thu, 16 Nov 2000 07:56:58 -0700 (MST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VTFR53GD; Thu, 16 Nov 2000 15:57:02 +0100 Reply-To: From: "Thomas Eklund" To: "'Michael Thomas'" , "'Francis Dupont'" Cc: "'Jun-ichiro itojun Hagino'" , "'Hesham Soliman \(EPA\)'" , "'Metzler Jochen'" , "'Ipng \(E-Mail\)'" Subject: RE: Usage of IPv6 flow label Date: Thu, 16 Nov 2000 15:57:00 +0100 Message-ID: <31A473DBB655D21180850008C71E251A0294926C@mail.kebne.se> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <31A473DBB655D21180850008C71E251A02E912B2@mail.kebne.se> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree. -- thomas > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Michael Thomas > Sent: den 16 november 2000 15:06 > To: Francis Dupont > Cc: Jun-ichiro itojun Hagino; Hesham Soliman (EPA); Metzler > Jochen; Ipng > (E-Mail) > Subject: Re: Usage of IPv6 flow label > > > Francis Dupont writes: > > In your previous mail you wrote: > > > > flow label field is not part of AH calculation, > but as RSVP already > > requires it to be end-to-end (not hop-by-hop) i > think we shouldn't > > rewrite it in transit. > > > > => I don't read your argument as you. I'll say it should > not be rewritten > > in transit if RSVP is in use. A DiffServ edge router can rewrite it > > in some situation (it is supposed to know what is RSVP and > do the right > > thing). > > Why would a diffserv router _want_ to rewrite a flow label? > It can still rewrite the DSCP if it wants. The only thing > that I've seen mentioned that could actually take advantage > in the way you are mentioning is using the flow label for > MPLS label swapping bits. > > Mike > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 16 07:02:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGEtpA10374 for ipng-dist; Thu, 16 Nov 2000 06:55:51 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGEtgj10367 for ; Thu, 16 Nov 2000 06:55:42 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA09286 for ; Thu, 16 Nov 2000 06:55:43 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA09376 for ; Thu, 16 Nov 2000 06:55:41 -0800 (PST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VTFR53FS; Thu, 16 Nov 2000 15:55:45 +0100 Reply-To: From: "Thomas Eklund" To: Cc: "'Steve Deering'" , "'Brian Zill'" , Subject: RE: Regarding the Options headers Date: Thu, 16 Nov 2000 15:55:31 +0100 Message-ID: <31A473DBB655D21180850008C71E251A0294926B@mail.kebne.se> 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 In-Reply-To: <31A473DBB655D21180850008C71E251A02E91247@mail.kebne.se> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Francis, > Then there are two different points: > - does the issue remain if edge routers are closed enough to hosts: > * an interface only (for direct connections) > * line speed limited at least by available stock hardware > * low or at least reasonable number of flows? In many cases yes. > I believe the issue doesn't remain just because for many reasons > stock hardware had, has and will have poor I/O performances > - is it possible to put edge routers closed enough: what I trying to say here is that people can build there network in different way... as you know 99,99 % of the isp's still use IPv4 for instance eventhough v6 is better and haver a nicer cleaner arhitechure.. > * technical constraints: I can't see one? you will have to buy more memory which is very expensive since you must have a recursive loop in the packet to find the offset where the transport header sits - this is doable but much worse than ipv4 where you have the header length and can dfind the offset immediatly for the transport header... > * price constraints: with ASICs we are supposed to do it cheaply? like I said it will be more expensier to build the hardware and in the end it might have an impact on the rollout of ipv6... > * policy constraints: I am sorry to have to say that but it > is the job > of a ISP to look at inside packets of its customers. It is why > I said ESP will save us. Of course this should be the point where > we have a very different opinion, in the past my current > ISP decided > the Web was mainly pornography and tried to limit the bandwidth > for a particular TCP port... And as I said I agree with your reasoning here from a pricipal clean IP arhitechure but there are many service providers that wants to use this feature. > I have talked about firewalls because: > - they shared the same issue but they have to do something a > bit harder > (BTW I think a solution which works for routers and not > for firewalls > will have a problem in the future: there are (too) many ISPs which > put firewalls to protect (against) customers) In other words we agree. Like I said before layer 4 classification is not nescessarily tied to qos classification it can be packet filtering as well and in both cases we have the same problem. > - they (will?) use ASICs when high performances are needed not nescesseary asic it could be np's as well. > - they share the management issue, security policies are even more > critical than QoS policies (a mistake for instance has > worse consequences). I agree. But I think that the UML base QoS policy model for managing Qos related policies is a very good start and hopefully we will have a security base policy model as well... Regards 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 Nov 16 07:06:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGF57L10421 for ipng-dist; Thu, 16 Nov 2000 07:05:07 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGF4rj10410 for ; Thu, 16 Nov 2000 07:04:54 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id eAGF4rB251593; Thu, 16 Nov 2000 07:04:53 -0800 (PST) Date: Thu, 16 Nov 2000 07:04:36 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: deprecated address handling for inbound TCP To: itojun@iijlab.net Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <2535.974147269@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 > well, the above scenario looks too aggressive to me. > the invariants we would like to keep are: > - advertise address by DNS, only after addresses are ready Ready to accept traffic I assume. Or do you mean "ready = preferred"? > - mark addresses deprecated, only after we remove them DNS and > we wait till DNS TTL has passed That means that the old adresses will be used as source addresses when they don't exist in the DNS. So any application on a peer which does a reverse + forward DNS lookup of the source address, will not find anything in the DNS. While we'd like to see such DNS host name verification replaced by stronger measures (such as IPsec) I think it would be unfortunate to completely throw out the ability the rely on DNS for reverse + forward lookups. Erik > so, the scenario will be as follows: time unit = minutes. > > T=0 add a new prefix. > T=5 test new prefix and confirm that it is working okay. > T=10 advertise address on new prefix (and old prefix) via DNS > T=70 confirm that we now have clicks to www.erik.net > T=75 remove addresses on old prefix from DNS > T=135 mark old address deprecated (pltime = 0). > T=140 confirm that there's no new connectivity to old address coming, > terminate contract with old ISP. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 07:10:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGF8n610448 for ipng-dist; Thu, 16 Nov 2000 07:08:49 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGF8cj10441 for ; Thu, 16 Nov 2000 07:08:39 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id eAGF8cB251963; Thu, 16 Nov 2000 07:08:38 -0800 (PST) Date: Thu, 16 Nov 2000 07:08:21 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: default router selection based on network topology To: itojun@iijlab.net Cc: Erik Nordmark , Robert Elz , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <2616.974147458@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 > >> from RFC2461 5.1 (conceptual data structures) I feel that the authors > >> assumed that: > >> - autoconfigured hosts are at the very edge of the site only > >> - if we put a host onto a link with more than 2 routers, they will not > >> automatically be configured, and do something tricky (like running > >> routing daemon on hosts in receive-only mode). > >Why doesn't advertising all 3 routers (without any preferences) plus > >redirects solve this problem? > > if you pick a wrong router (like one of two downstream router) > as the default and stick to that one, i'm afraid you will see so many > redirects. if redirect traffic are okay for you, i have no objection > with your plan. Even if you have just two routers (and no upstream/downstream issue) you will see redirect traffic. I don't see this as being a problem (one redirect per IP destination the host ever sends to isn't a big deal - note that redirect routes don't need to be timed out in IPv6 since NUD protects against stale information). 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 Nov 16 08:24:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGGNXn10633 for ipng-dist; Thu, 16 Nov 2000 08:23:33 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGGNOj10626 for ; Thu, 16 Nov 2000 08:23:25 -0800 (PST) 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,v1.7) with ESMTP id IAA00446 for ; Thu, 16 Nov 2000 08:23:25 -0800 (PST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23651 for ; Thu, 16 Nov 2000 08:23:24 -0800 (PST) Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 749372407DDF; Thu, 16 Nov 2000 17:23:18 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id RAA07991; Thu, 16 Nov 2000 17:23:18 +0100 (MET) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Francis Dupont , Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU References: <200011071100.MAA47016@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 16 Nov 2000 17:23:14 +0100 In-Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?='s message of "Thu, 16 Nov 2000 22:52:31 +0900" Message-ID: Lines: 18 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= writes: > struct ip6_mtuinfo { > u_int32_t ip6mtu_mtu; > struct sockaddr_in6 ip6mtu_dst; > }; ... > By the way, the rfc2292bis draft seems a bit ambiguous on the byte > order of the 32-bit MTU value. Like other fields used in the spec, I > treated the value in the network byte order, but the spec should > clearly specify the byte order. Is this value ever transmitted on the wire? If not, it should probably use host byte order. /Niels -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 08:34:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGGX4Z10728 for ipng-dist; Thu, 16 Nov 2000 08:33:04 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGGWqj10721 for ; Thu, 16 Nov 2000 08:32:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA02347 for ; Thu, 16 Nov 2000 08:32:52 -0800 (PST) Received: from starfruit.itojun.org (ny-ppp007.iij-us.net [216.98.99.7]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07393 for ; Thu, 16 Nov 2000 08:32:50 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id EC7017EF9; Fri, 17 Nov 2000 00:09:34 +0900 (JST) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Hideaki YOSHIFUJI (=?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?=) , Francis.Dupont@enst-bretagne.fr, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: jinmei's message of Thu, 16 Nov 2000 23:39:42 +0900. 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: [advanced API] how to get the destination address for IPV6_RECVPATHMTU From: Jun-ichiro itojun Hagino Date: Fri, 17 Nov 2000 00:09:34 +0900 Message-Id: <20001116150935.EC7017EF9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> I've implemented the IPV6_RECVPATHMTU option adopting #3 approach. I >>> defined a new structure "ip6_mtuinfo" as ancillary data item for >>> IPV6_PATHMTU as follows: >>> struct ip6_mtuinfo { >>> u_int32_t ip6mtu_mtu; >>> struct sockaddr_in6 ip6mtu_dst; >>> }; >> How do you think about alignment? >Currently, I only consider 32-bit alignment, but I'm open to hear >others' opinions. as this structure is host-local (will not appear on wire) there's no serious issue with alignment, I believe. ip6mtu_dst will be aligned to whatever look natural to the machine based on sockaddr_in6 declaration. 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 Nov 16 08:36:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGGZlQ10768 for ipng-dist; Thu, 16 Nov 2000 08:35:47 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGGZbj10761 for ; Thu, 16 Nov 2000 08:35:37 -0800 (PST) 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,v1.7) with ESMTP id IAA29438 for ; Thu, 16 Nov 2000 08:35:37 -0800 (PST) Received: from ish7.ericsson.com.au ([203.61.155.111]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02759 for ; Thu, 16 Nov 2000 08:35:35 -0800 (PST) Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id DAA09619; Fri, 17 Nov 2000 03:31:53 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id DAA09976; Fri, 17 Nov 2000 03:34:42 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Nov 2000 03:34:54 +1100 Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613E0D@eaubrnt018.epa.ericsson.se> From: "Hesham Soliman (EPA)" To: "'Michael Thomas '" , "Hesham Soliman (EPA)" Cc: "'Ipng (E-Mail) '" Subject: RE: Usage of IPv6 flow label Date: Fri, 17 Nov 2000 03:34:57 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04FEB.27D4A4D0" 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_01C04FEB.27D4A4D0 Content-Type: text/plain Hesham Soliman (EPA) writes: > > Hesham Soliman (EPA) writes: > > > => It is also used in the GGSN (default router in IPv6 land) > > > as one of the options to identify a flow and make the right > > > QoS decisions. > > > The router is informed by the IPv6 node about > > > the flow label value for each connection. > > > > Er, by what protocol does it inform the router? > > > => A 3GPP protocol. Which is different from an IETF protocol? => Yes. Otherwise it would not be a 3GPP protocol ;) ------_=_NextPart_001_01C04FEB.27D4A4D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Usage of IPv6 flow label

 

Hesham Soliman (EPA) writes:
 > > Hesham Soliman (EPA) writes:
 > >  > =         =3D> It is also used in = the GGSN (default router in IPv6
land)
 > >  > =         as one of the options to = identify a flow and make the
right
 > >  > =         QoS decisions.
 > >  > =         The router is informed by = the IPv6 node about
 > >  > =         the flow label value for = each connection.
 > >
 > >    Er, by what = protocol does it inform the router?
 > >
 >      =3D> A 3GPP = protocol.

   Which is different from an IETF = protocol?

=3D> Yes. Otherwise it would not be a 3GPP = protocol ;)

------_=_NextPart_001_01C04FEB.27D4A4D0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 08:43:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGGgZD10823 for ipng-dist; Thu, 16 Nov 2000 08:42:35 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGGgQj10816 for ; Thu, 16 Nov 2000 08:42:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA01955 for ; Thu, 16 Nov 2000 08:42:26 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22866 for ; Thu, 16 Nov 2000 09:42:19 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAGGg8b14997; Thu, 16 Nov 2000 17:42:08 +0100 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 RAA08565; Thu, 16 Nov 2000 17:42:02 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id RAA92214; Thu, 16 Nov 2000 17:44:17 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011161644.RAA92214@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: thomas.eklund@xelerated.com cc: "'Steve Deering'" , "'Brian Zill'" , ipng@sunroof.eng.sun.com Subject: Re: Regarding the Options headers In-reply-to: Your message of Thu, 16 Nov 2000 15:55:31 +0100. <31A473DBB655D21180850008C71E251A0294926B@mail.kebne.se> Date: Thu, 16 Nov 2000 17:44:17 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > * technical constraints: I can't see one? you will have to buy more memory which is very expensive since you must have a recursive loop in the packet to find the offset where the transport header sits - this is doable but much worse than ipv4 where you have the header length and can find the offset immediatly for the transport header... => I don't understand the memory problem: you still need enough memory to handle the packet... Perhaps you'd like to cache the first bytes in another (fast and more expensive) memory and in this case the offset won't help. You should have a particular design in the mind (and of course you don't want to give all the details in an open list). > * policy constraints: I am sorry to have to say that but it > is the job of a ISP to look at inside packets of its > customers. It is why I said ESP will save us. Of course this should be > the point where we have a very different opinion, in the past my > current ISP decided the Web was mainly pornography and tried to limit > the bandwidth for a particular TCP port... And as I said I agree with your reasoning here from a principal clean IP architecture but there are many service providers that want to use this feature. => then your issue is you can't say just no as I can? 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 Nov 16 08:51:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGGoP410863 for ipng-dist; Thu, 16 Nov 2000 08:50:25 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGGo4j10843 for ; Thu, 16 Nov 2000 08:50:05 -0800 (PST) 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,v1.7) with ESMTP id IAA02973 for ; Thu, 16 Nov 2000 08:50:05 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28188 for ; Thu, 16 Nov 2000 09:50:03 -0700 (MST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id IAA05675; Thu, 16 Nov 2000 08:49:32 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA06001; Thu, 16 Nov 2000 08:49:32 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14868.4124.287839.157557@thomasm-u1.cisco.com> Date: Thu, 16 Nov 2000 08:49:32 -0800 (PST) To: "Hesham Soliman (EPA)" Cc: "'Michael Thomas '" , "'Ipng (E-Mail) '" Subject: RE: Usage of IPv6 flow label In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A50C613E0D@eaubrnt018.epa.ericsson.se> References: <4B6BC00CD15FD2119E5F0008C7A419A50C613E0D@eaubrnt018.epa.ericsson.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham Soliman (EPA) writes: > > > Er, by what protocol does it inform the router? > > > > > => A 3GPP protocol. > > Which is different from an IETF protocol? > > => Yes. Otherwise it would not be a 3GPP protocol ;) Is there some compelling reason why RSVP is not that protocol, or is this yet another case of the parochial "our layer 2 is _so_ different we can't possibly use widely accepted and standards based protocols." Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 08:51:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGGoIU10862 for ipng-dist; Thu, 16 Nov 2000 08:50:18 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGGo5j10845 for ; Thu, 16 Nov 2000 08:50:05 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA02954 for ; Thu, 16 Nov 2000 08:49:55 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15444 for ; Thu, 16 Nov 2000 08:49:49 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAGGk1b47094; Thu, 16 Nov 2000 17:46:01 +0100 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 RAA08721; Thu, 16 Nov 2000 17:46:00 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id RAA92240; Thu, 16 Nov 2000 17:48:16 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011161648.RAA92240@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: thomas.eklund@xelerated.com cc: "'Michael Thomas'" , "'Jun-ichiro itojun Hagino'" , "'Hesham Soliman \(EPA\)'" , "'Metzler Jochen'" , "'Ipng \(E-Mail\)'" Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of Thu, 16 Nov 2000 15:57:00 +0100. <31A473DBB655D21180850008C71E251A0294926C@mail.kebne.se> Date: Thu, 16 Nov 2000 17:48:16 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just in order to make things clear, a DiffServ edge router ::= an edge router with the DiffServ definition of what is an edge router. 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 Nov 16 08:59:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGGwPh10936 for ipng-dist; Thu, 16 Nov 2000 08:58:25 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGGwGj10929 for ; Thu, 16 Nov 2000 08:58:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA06725; Thu, 16 Nov 2000 08:58:15 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19908; Thu, 16 Nov 2000 08:58:11 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAGGuPb15097; Thu, 16 Nov 2000 17:56:25 +0100 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 RAA09125; Thu, 16 Nov 2000 17:56:24 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id RAA92356; Thu, 16 Nov 2000 17:58:40 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011161658.RAA92356@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jun-ichiro itojun Hagino cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Hideaki YOSHIFUJI (=?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?=) , Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU In-reply-to: Your message of Fri, 17 Nov 2000 00:09:34 +0900. <20001116150935.EC7017EF9@starfruit.itojun.org> Date: Thu, 16 Nov 2000 17:58:40 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >>> I've implemented the IPV6_RECVPATHMTU option adopting #3 approach. I >>> defined a new structure "ip6_mtuinfo" as ancillary data item for >>> IPV6_PATHMTU as follows: >>> struct ip6_mtuinfo { >>> u_int32_t ip6mtu_mtu; >>> struct sockaddr_in6 ip6mtu_dst; >>> }; >> How do you think about alignment? >Currently, I only consider 32-bit alignment, but I'm open to hear >others' opinions. as this structure is host-local (will not appear on wire) there's no serious issue with alignment, I believe. => I disagree, I'd like to be able to defined struct in6_addr as a pair of 64 bit integers one day (:-)! ip6mtu_dst will be aligned to whatever look natural to the machine based on sockaddr_in6 declaration. => please do something similar to in6_pktinfo... 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 Nov 16 09:14:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGHDIC10999 for ipng-dist; Thu, 16 Nov 2000 09:13:18 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGHD3j10991 for ; Thu, 16 Nov 2000 09:13:03 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA11802; Thu, 16 Nov 2000 09:13:02 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27529; Thu, 16 Nov 2000 09:12:57 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id BAA05829; Fri, 17 Nov 2000 01:58:45 +0900 (JST) Date: Fri, 17 Nov 2000 01:34:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Niels =?ISO-8859-1?Q?M=81=F6ller?= Cc: Francis Dupont , Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU In-Reply-To: In your message of "16 Nov 2000 17:23:14 +0100" References: <200011071100.MAA47016@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=ISO-8859-1 X-Dispatcher: imput version 980905(IM100) Lines: 21 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id eAGHD4j10992 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On 16 Nov 2000 17:23:14 +0100, >>>>> nisse@lysator.liu.se (Niels Möller) said: >> By the way, the rfc2292bis draft seems a bit ambiguous on the byte >> order of the 32-bit MTU value. Like other fields used in the spec, I >> treated the value in the network byte order, but the spec should >> clearly specify the byte order. > Is this value ever transmitted on the wire? No, but the MTU value would be copied from the corresponding ICMPv6 error message, so I don't surprise if an implementation keeps the field in the network byte order. However, I don't stick to using the network byte order. The point is that we should clearly state the byte order in the spec. 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 Nov 16 09:14:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGHDDM10998 for ipng-dist; Thu, 16 Nov 2000 09:13:13 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGHCxj10983 for ; Thu, 16 Nov 2000 09:12:59 -0800 (PST) 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,v1.7) with ESMTP id JAA10160; Thu, 16 Nov 2000 09:12:54 -0800 (PST) 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 JAA16603; Thu, 16 Nov 2000 09:12:52 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id BAA05833; Fri, 17 Nov 2000 01:58:56 +0900 (JST) Date: Fri, 17 Nov 2000 02:12:18 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU In-Reply-To: In your message of "Mon, 6 Nov 2000 13:11:07 -0800 (PST)" References: User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 17 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 6 Nov 2000 13:11:07 -0800 (PST), >>>>> Erik Nordmark said: >> 1. this option has its meaning for a connected socket only. The >> destination is the foreign address of the socket. > I do think we want this to work for unconnected datagram sockets i.e. 1 is > not an option. Then, I believe the spec should clearly state the point, because (for example) BSD derived kernels do not notify unconnected sockets of errors. 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 Nov 16 09:23:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGHM8211055 for ipng-dist; Thu, 16 Nov 2000 09:22:08 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGHLxj11048 for ; Thu, 16 Nov 2000 09:21:59 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA15107; Thu, 16 Nov 2000 09:21:58 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08199; Thu, 16 Nov 2000 09:21:54 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAGHL0b48380; Thu, 16 Nov 2000 18:21:00 +0100 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 SAA10048; Thu, 16 Nov 2000 18:20:59 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA92518; Thu, 16 Nov 2000 18:23:14 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011161723.SAA92518@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Niels =?ISO-8859-1?Q?M=81=F6ller?= , Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU In-reply-to: Your message of Fri, 17 Nov 2000 01:34:37 +0900. Date: Thu, 16 Nov 2000 18:23:14 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Is this value ever transmitted on the wire? No, but the MTU value would be copied from the corresponding ICMPv6 error message, so I don't surprise if an implementation keeps the field in the network byte order. => or if there is no ICMPv6 error the MTU value would be copied from the outgoing interface MTU parameter which has no reason to be in the network byte order (this will only make comparaison harder). However, I don't stick to using the network byte order. The point is that we should clearly state the byte order in the spec. => I agree and I vote for the host byte order. 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 Thu Nov 16 09:51:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGHo5a11150 for ipng-dist; Thu, 16 Nov 2000 09:50:05 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGHnuj11143 for ; Thu, 16 Nov 2000 09:49:57 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA18512 for ; Thu, 16 Nov 2000 09:49:52 -0800 (PST) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17145 for ; Thu, 16 Nov 2000 09:49:49 -0800 (PST) Received: from godel.logique.jussieu.fr (root@godel.logique.jussieu.fr [134.157.19.1]) by shiva.jussieu.fr (8.10.0/jtpda-5.3.3) with ESMTP id eAGHnjt77768 ; Thu, 16 Nov 2000 18:49:45 +0100 (CET) Received: from bernays.logique.jussieu.fr (bernays.logique.jussieu.fr [134.157.19.71]) by godel.logique.jussieu.fr (8.9.3/jtpda-5.3.1) with ESMTP id SAA27990 ; Thu, 16 Nov 2000 18:49:26 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 16 Nov 2000 18:55:04 +0100 (CET) From: Yves Legrandgerard To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Subject: Re: IPV6_USEMTU socket option Cc: ipng@sunroof.eng.sun.com, Francis Dupont Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 16-Nov-00 JINMEI Tatuya wrote: > Applications can dynamically grab the path MTU by the IPV6_RECVPATHMTU > socket option (upon receiving an ICMPv6 packet toobig error). > Is that mean, when IPV6_RECVPATHMTU option is setted (UDP/raw socket), that fragmentation is disabled ? ---------------------------------- Yves Legrandgérard E-Mail: ylg@logique.jussieu.fr Date: 16-Nov-00 Time: 18:46:04 ---------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 10:19:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGII8q11244 for ipng-dist; Thu, 16 Nov 2000 10:18:08 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGII3j11237 for ; Thu, 16 Nov 2000 10:18:03 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id eAGIH4R02372 for ipng@sunroof.eng.sun.com; Thu, 16 Nov 2000 10:17:04 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGEqFj10355 for ; Thu, 16 Nov 2000 06:52:16 -0800 (PST) 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,v1.7) with ESMTP id GAA11921 for ; Thu, 16 Nov 2000 06:52:16 -0800 (PST) Received: from zmailer.org (mail.zmailer.org [194.252.70.162]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01256 for ; Thu, 16 Nov 2000 07:52:15 -0700 (MST) Received: (from localhost user: 'mea' uid#500 fake: STDIN (mea@zmailer.org)) by mail.zmailer.org id ; Thu, 16 Nov 2000 16:52:09 +0200 Date: Thu, 16 Nov 2000 16:52:09 +0200 From: Matti Aarnio To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" Cc: ipng@sunroof.eng.sun.com Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU Message-ID: <20001116165209.H28963@mea-ext.zmailer.org> References: <200011071100.MAA47016@givry.rennes.enst-bretagne.fr> <20001116230401T.yoshfuji@ecei.tohoku.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Thu, Nov 16, 2000 at 11:39:42PM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Nov 16, 2000 at 11:39:42PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: > >> defined a new structure "ip6_mtuinfo" as ancillary data item for > >> IPV6_PATHMTU as follows: > >> > >> struct ip6_mtuinfo { > >> u_int32_t ip6mtu_mtu; > >> struct sockaddr_in6 ip6mtu_dst; > >> }; > > > How do you think about alignment? > > Currently, I only consider 32-bit alignment, but I'm open to hear > others' opinions. My main tool for IPv6 related development is 64-bit Alpha, and I do presume that within a year or two we will have ia64 systems to consider as well. > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp /Matti Aarnio -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 10:22:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGILnt11266 for ipng-dist; Thu, 16 Nov 2000 10:21:49 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGILej11259 for ; Thu, 16 Nov 2000 10:21:40 -0800 (PST) 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,v1.7) with ESMTP id KAA05298 for ; Thu, 16 Nov 2000 10:21:40 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07421 for ; Thu, 16 Nov 2000 11:21:37 -0700 (MST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VTFR5P8Z; Thu, 16 Nov 2000 19:21:40 +0100 Reply-To: From: "Thomas Eklund" To: Cc: "'Steve Deering'" , "'Brian Zill'" , Subject: RE: Regarding the Options headers Date: Thu, 16 Nov 2000 19:21:36 +0100 Message-ID: <31A473DBB655D21180850008C71E251A0294926F@mail.kebne.se> 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 In-Reply-To: <31A473DBB655D21180850008C71E251A02E91469@mail.kebne.se> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Francis, > => then your issue is you can't say just no as I can? No - because there are too many customers asking for it. -- 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 Nov 16 11:06:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGJ4UD11417 for ipng-dist; Thu, 16 Nov 2000 11:04:30 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGJ4Kj11410 for ; Thu, 16 Nov 2000 11:04:20 -0800 (PST) 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,v1.7) with ESMTP id LAA19160 for ; Thu, 16 Nov 2000 11:04:19 -0800 (PST) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26363 for ; Thu, 16 Nov 2000 11:04:19 -0800 (PST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 13wUDg-0005PQ-00; Thu, 16 Nov 2000 13:57:12 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA05735; Thu, 16 Nov 00 13:52:23 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id NAA17893; Thu, 16 Nov 2000 13:57:02 -0500 Message-Id: <3A142DEE.AA44B45F@txc.com> Date: Thu, 16 Nov 2000 13:56:46 -0500 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Michael Thomas Cc: Francis Dupont , Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <20001115190919.321B17EF9@starfruit.itojun.org> <200011160958.KAA90047@givry.rennes.enst-bretagne.fr> <14867.59850.899996.178063@thomasm-u1.cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF925F61CB3A9D25923A7C2E6" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msF925F61CB3A9D25923A7C2E6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If flow IDs are used for fast forwarding, without the ability to rewrite them, it seems to me that a router will not be able to aggregate flows. Alex Michael Thomas wrote: > > Francis Dupont writes: > > In your previous mail you wrote: > > > > flow label field is not part of AH calculation, but as RSVP already > > requires it to be end-to-end (not hop-by-hop) i think we shouldn't > > rewrite it in transit. > > > > => I don't read your argument as you. I'll say it should not be rewritten > > in transit if RSVP is in use. A DiffServ edge router can rewrite it > > in some situation (it is supposed to know what is RSVP and do the right > > thing). > > Why would a diffserv router _want_ to rewrite a flow label? > It can still rewrite the DSCP if it wants. The only thing > that I've seen mentioned that could actually take advantage > in the way you are mentioning is using the flow label for > MPLS label swapping bits. > > Mike > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------msF925F61CB3A9D25923A7C2E6 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKBgYJKoZIhvcNAQcCoIIJ9zCCCfMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICETCCAg0CAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDExMTYxODU2NDlaMCMGCSqGSIb3DQEJBDEWBBSIWa205z7wHpMt3KsX IPOVwGNTkDAnBgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGANHaHHOqPoHNgBuqXu10ADc3Tfc2+ygIfBMmtSEqWYoqNbm0F/RX77STC 5VeKTg5rUZ61+A+lealbhVpBEYBaD5yyFqyGK5jACtnThNpBMUcEIirX6GUpD3Jc1CfjymAV SBSXOnxN0uvSKHraelhAXHHXR9Zkjij7MVd8G23WQnE= --------------msF925F61CB3A9D25923A7C2E6-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 11:15:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGJEQC11465 for ipng-dist; Thu, 16 Nov 2000 11:14:26 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGJEHj11458 for ; Thu, 16 Nov 2000 11:14:17 -0800 (PST) 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,v1.7) with ESMTP id LAA22137 for ; Thu, 16 Nov 2000 11:14:17 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29801 for ; Thu, 16 Nov 2000 11:14:16 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id LAA09455; Thu, 16 Nov 2000 11:02:18 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA06048; Thu, 16 Nov 2000 11:02:18 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14868.12090.132937.881088@thomasm-u1.cisco.com> Date: Thu, 16 Nov 2000 11:02:18 -0800 (PST) To: Alex Conta Cc: Michael Thomas , Francis Dupont , Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label In-Reply-To: <3A142DEE.AA44B45F@txc.com> References: <20001115190919.321B17EF9@starfruit.itojun.org> <200011160958.KAA90047@givry.rennes.enst-bretagne.fr> <14867.59850.899996.178063@thomasm-u1.cisco.com> <3A142DEE.AA44B45F@txc.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex Conta writes: > If flow IDs are used for fast forwarding, without the ability to rewrite > them, it seems to me > that a router will not be able to aggregate flows. Boy, I may be missing something really stupid, but the DSCP seems like the obvious flow aggregation handle to me. Mike > > Alex > > > Michael Thomas wrote: > > > > Francis Dupont writes: > > > In your previous mail you wrote: > > > > > > flow label field is not part of AH calculation, but as RSVP already > > > requires it to be end-to-end (not hop-by-hop) i think we shouldn't > > > rewrite it in transit. > > > > > > => I don't read your argument as you. I'll say it should not be rewritten > > > in transit if RSVP is in use. A DiffServ edge router can rewrite it > > > in some situation (it is supposed to know what is RSVP and do the right > > > thing). > > > > Why would a diffserv router _want_ to rewrite a flow label? > > It can still rewrite the DSCP if it wants. The only thing > > that I've seen mentioned that could actually take advantage > > in the way you are mentioning is using the flow label for > > MPLS label swapping bits. > > > > Mike > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Nov 16 11:31:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGJUHP11544 for ipng-dist; Thu, 16 Nov 2000 11:30:17 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGJU8j11537 for ; Thu, 16 Nov 2000 11:30:09 -0800 (PST) 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,v1.7) with ESMTP id LAA19640 for ; Thu, 16 Nov 2000 11:30:08 -0800 (PST) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05550 for ; Thu, 16 Nov 2000 11:30:08 -0800 (PST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 13wUcx-0003Xz-00; Thu, 16 Nov 2000 14:23:19 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA06030; Thu, 16 Nov 00 14:18:39 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id OAA18774; Thu, 16 Nov 2000 14:23:20 -0500 Message-Id: <3A143423.1ED00F6A@txc.com> Date: Thu, 16 Nov 2000 14:23:15 -0500 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Thomas Narten Cc: Metzler Jochen , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <200011151444.JAA08525@rotala.raleigh.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms43E9E3C677FFC9A289971667" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms43E9E3C677FFC9A289971667 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thomas, This is or may be a sensitive topic for many. The reality is that, at least a majority, if not all, of the original goals of the Flow ID field are achieved by the MPLS shim header. Remember the discussions of many years ago, of where to place the flow ID relative to the source and destination addresses? Well that was also answered by the MPLS header. Furthermore, The MPLS label distribution protocols - RSVP is one of them - are the mechanisms used to assign and distribute labels. IPng WG never really tackled this area, and in reality there is no protocol that defines a consistent IPv6 flow ID allocation, and distribution that I am aware of. Furthermore, the ability to build hierarchies, the ability to use directly fast ATM, and FR hardware forwarding engines, and the better traffic engineering capabilities, give a considerable edge to MPLS, over the IPv6 flow ID. Considering these, and perhaps more, I think the IPv6 flow ID field is obsolete, and could be redefined as "reserved", or renamed, and given a more useful role than it has now. I may put out a draft on this topic, to generate or add to a discussion point on the agenda, if one already exists. Alex Thomas Narten wrote: > > Metzler, > > > Within RFC2460 the usage of the flow label field is not > > fully described and for me it is not clear if anything > > mentioned in the Appendix is part of the standard or > > only for information. Therefore I have the following > > questions: > > The bottom line is that as of this time, no one has proposed how they > would like to use the Flow Label and led the WG to consensus on their > approach. Hence, it really is unspecified in the sense that its > useage/definition remains to be defined. > > If you have a proposal on how it could/should be used, this WG is > certainly the place to make that proposal, and I would encourage you > to do so. > > I'll note that there have been discussions in the past where arguments > have been made that the flow label should not be modified by any > routers (i.e., it has end-to-end semantics that need to respected) > while other folks have argued that it might be good to allow it to be > modified by routers (e.g., in support of something like MPLS). The > door has been left open for either of those approaches. Specifically, > the Flow Label is considered a mutable field from the perspective of > IPsec, thus IPsec won't break if the field is modified by routers. > > Again, what is needed is a concrete proposal that answers the types of > questions you raised. > > 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 > -------------------------------------------------------------------- --------------ms43E9E3C677FFC9A289971667 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKBgYJKoZIhvcNAQcCoIIJ9zCCCfMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICETCCAg0CAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDExMTYxOTIzMTZaMCMGCSqGSIb3DQEJBDEWBBSqE8ZP8uD9ZsyPUsQ7 77ZCMEDCTTAnBgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAdgtNHkTAkRzPPiSb9DeVLS2OYuW/j6fBgAuZswGqZ6IChspGhGoZGa9i 7R8rpRqH/c1IxdjKMgiRe9C4OspuBKYEGn+be7ZHn+JQiw0khEj+Z5lLXYeYTzTBbeN1n8n8 8KwytK09Wztvz7gurUt6Rff9KJGop1ENCyiydFaBhCo= --------------ms43E9E3C677FFC9A289971667-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 11:44:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGJh3M11646 for ipng-dist; Thu, 16 Nov 2000 11:43:03 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGJgqj11639 for ; Thu, 16 Nov 2000 11:42:53 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id eAGJgpB322551; Thu, 16 Nov 2000 11:42:51 -0800 (PST) Date: Thu, 16 Nov 2000 11:42:34 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , 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 do think we want this to work for unconnected datagram sockets i.e. 1 is > > not an option. > > Then, I believe the spec should clearly state the point, because (for > example) BSD derived kernels do not notify unconnected sockets of > errors. I agree completely that, once we know what we want the API to look like, we need to make this very clear in the spec. 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 Nov 16 11:45:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGJi3x11655 for ipng-dist; Thu, 16 Nov 2000 11:44:03 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGJhlj11648 for ; Thu, 16 Nov 2000 11:43:47 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA25765 for ; Thu, 16 Nov 2000 11:43:46 -0800 (PST) Received: from roll.mentat.com ([192.88.122.129]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19490 for ; Thu, 16 Nov 2000 11:43:46 -0800 (PST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA07539; Thu, 16 Nov 2000 11:45:04 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA19907; Thu, 16 Nov 2000 11:45:02 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id LAA25723; Thu, 16 Nov 2000 11:45:15 -0800 (PST) Date: Thu, 16 Nov 2000 11:45:15 -0800 (PST) From: Tim Hartrick Message-Id: <200011161945.LAA25723@feller.mentat.com> To: itojun@iijlab.net, Francis.Dupont@enst-bretagne.fr Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, > > >>> I've implemented the IPV6_RECVPATHMTU option adopting #3 approach. I > >>> defined a new structure "ip6_mtuinfo" as ancillary data item for > >>> IPV6_PATHMTU as follows: > >>> struct ip6_mtuinfo { > >>> u_int32_t ip6mtu_mtu; > >>> struct sockaddr_in6 ip6mtu_dst; > >>> }; > >> How do you think about alignment? > >Currently, I only consider 32-bit alignment, but I'm open to hear > >others' opinions. > > as this structure is host-local (will not appear on wire) there's no > serious issue with alignment, I believe. > > => I disagree, I'd like to be able to defined struct in6_addr as a pair > of 64 bit integers one day (:-)! > I don't understand the point. The two 64 bit fields will be forced onto their natural boundaries. This might lead to the compiler adding padding between the ip6mtu_mtu and ip6mtu_dst but so what. This structure doesn't go on the wire so padding that is added by the compiler is not relevent. With regard to the Endianness of the ip6mtu_mtu, I agree that it should be in host order. 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 Nov 16 12:43:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGKfiD11748 for ipng-dist; Thu, 16 Nov 2000 12:41:44 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGKfZj11741 for ; Thu, 16 Nov 2000 12:41:35 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA10805 for ; Thu, 16 Nov 2000 12:41:35 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17660 for ; Thu, 16 Nov 2000 12:41:34 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id MAB29514; Thu, 16 Nov 2000 12:40:20 -0800 Received: from hursley.ibm.com (brianc [9.111.137.51] (may be forged)) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA29676; Thu, 16 Nov 2000 12:41:10 -0800 Message-ID: <3A143526.A89A1CEC@hursley.ibm.com> Date: Thu, 16 Nov 2000 13:27:34 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Metzler Jochen CC: "'Francis Dupont'" , Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , "Ipng (E-Mail)" Subject: Re: AW: Usage of IPv6 flow label References: <158669A6D0F5D3119B940060086D94F55006BB@ULML202E> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id eAGKfaj11742 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As far as I know neither diffserv nor intserv/RSVP know anything about the flow label field. Brian Metzler Jochen wrote: > > Can you explain to me what the matter with DiffServ is? > I assumed that DiffServ makes use of the ToS field and > not of the flow label? > -- jochen > > > -----Ursprüngliche Nachricht----- > Von: Francis Dupont [SMTP:Francis.Dupont@enst-bretagne.fr] > Gesendet am: Donnerstag, 16. November 2000 10:58 > An: Jun-ichiro itojun Hagino > Cc: Hesham Soliman (EPA); Metzler Jochen; Ipng (E-Mail) > Betreff: Re: Usage of IPv6 flow label > > In your previous mail you wrote: > > flow label field is not part of AH calculation, but as RSVP already > requires it to be end-to-end (not hop-by-hop) i think we shouldn't > rewrite it in transit. > > => I don't read your argument as you. I'll say it should not be rewritten > in transit if RSVP is in use. A DiffServ edge router can rewrite it > in some situation (it is supposed to know what is RSVP and do the right > thing). Don't forget that in the real world RSVP is not end-to-end and > is managed by smart edge routers, this comes more from practice (the end > user doesn't know how to use RSVP, the edge router manager knows) than > from deep design... > > 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 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.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 Thu Nov 16 13:29:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGLMo511815 for ipng-dist; Thu, 16 Nov 2000 13:22:50 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGLMYj11808 for ; Thu, 16 Nov 2000 13:22:36 -0800 (PST) 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,v1.7) with ESMTP id NAA26631 for ; Thu, 16 Nov 2000 13:22:17 -0800 (PST) Received: from starfruit.itojun.org (h010.p022.iij4u.or.jp [210.130.22.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25460 for ; Thu, 16 Nov 2000 13:22:15 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 76E867EFA; Fri, 17 Nov 2000 06:22:13 +0900 (JST) To: Francis Dupont Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Hideaki YOSHIFUJI (=?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?=) , Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Thu, 16 Nov 2000 17:58:40 +0100. <200011161658.RAA92356@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: [advanced API] how to get the destination address for IPV6_RECVPATHMTU From: Jun-ichiro itojun Hagino Date: Fri, 17 Nov 2000 06:22:13 +0900 Message-Id: <20001116212213.76E867EFA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >>> I've implemented the IPV6_RECVPATHMTU option adopting #3 approach. I > >>> defined a new structure "ip6_mtuinfo" as ancillary data item for > >>> IPV6_PATHMTU as follows: > >>> struct ip6_mtuinfo { > >>> u_int32_t ip6mtu_mtu; > >>> struct sockaddr_in6 ip6mtu_dst; > >>> }; > >> How do you think about alignment? > >Currently, I only consider 32-bit alignment, but I'm open to hear > >others' opinions. > as this structure is host-local (will not appear on wire) there's no > serious issue with alignment, I believe. >=> I disagree, I'd like to be able to defined struct in6_addr as a pair >of 64 bit integers one day (:-)! I don't understand what you are saying, at all. ip6mtu_dst will be aligned to the alignment whatever necessary for us, depending on how your compiler aligns it. sockaddr_in6 includes struct in6_addr (sin6_addr), and if you declare in6_addr like: struct in6_addr { union { uint8_t foo8[16]; uint16_t foo16[8]; uint32_t foo32[4]; uint64_t foo32[2]; } foo; }; ip6mtu_dst.sin6_addr should be aligned to 64bit boundary. > ip6mtu_dst will be aligned to whatever look natural to the machine > based on sockaddr_in6 declaration. >=> please do something similar to in6_pktinfo... 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 Nov 16 13:32:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGLUYv11864 for ipng-dist; Thu, 16 Nov 2000 13:30:34 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGLUMj11857 for ; Thu, 16 Nov 2000 13:30:23 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA28740; Thu, 16 Nov 2000 13:30:14 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11520; Thu, 16 Nov 2000 13:30:13 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id GAA12910; Fri, 17 Nov 2000 06:30:11 +0900 (JST) To: Erik Nordmark cc: Robert Elz , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Thu, 16 Nov 2000 07:08:21 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: default router selection based on network topology From: itojun@iijlab.net Date: Fri, 17 Nov 2000 06:30:11 +0900 Message-ID: <12908.974410211@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> if you pick a wrong router (like one of two downstream router) >> as the default and stick to that one, i'm afraid you will see so many >> redirects. if redirect traffic are okay for you, i have no objection >> with your plan. >Even if you have just two routers (and no upstream/downstream issue) you will >see redirect traffic. I don't see this as being a problem (one redirect >per IP destination the host ever sends to isn't a big deal - note that >redirect routes don't need to be timed out in IPv6 since NUD protects >against stale information). i'm still having fuzzy feeling about ICMPv6 redirects - if we have famous web server in our network, and the web server picked wrong (downstream) router as its default router, i'm not sure if the amount of ICMPv6 redirects will be acceptable for us. another thing - you will want to timeout redirect routes, as they will chew your kernel memory space. you cannot keep them forever. 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 Nov 16 13:34:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGLWuh11883 for ipng-dist; Thu, 16 Nov 2000 13:32:56 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGLWaj11870 for ; Thu, 16 Nov 2000 13:32:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA03822; Thu, 16 Nov 2000 13:32:34 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12757; Thu, 16 Nov 2000 13:32:33 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id GAA12936; Fri, 17 Nov 2000 06:32:32 +0900 (JST) To: Erik Nordmark cc: ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Thu, 16 Nov 2000 07:04:36 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: deprecated address handling for inbound TCP From: itojun@iijlab.net Date: Fri, 17 Nov 2000 06:32:32 +0900 Message-ID: <12934.974410352@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> well, the above scenario looks too aggressive to me. >> the invariants we would like to keep are: >> - advertise address by DNS, only after addresses are ready >Ready to accept traffic I assume. Or do you mean "ready = preferred"? ready to accept traffic, yes. i'd enable forward DNS records, only after I confirmed the reachability of new address is stable enough (run some test from outside, by ping6 or traceroute6). >> - mark addresses deprecated, only after we remove them DNS and >> we wait till DNS TTL has passed >That means that the old adresses will be used as source addresses >when they don't exist in the DNS. So any application on a peer which does a >reverse + forward DNS lookup of the source address, will not find anything >in the DNS. While we'd like to see such DNS host name verification replaced >by stronger measures (such as IPsec) I think it would be unfortunate to >completely throw out the ability the rely on DNS for reverse + forward lookups. if you want to you may put reverse DNS entries earlier than forward DNS entries. about the use of old address without forward DNS entries, i have no answer yet. let me think. 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 Nov 16 13:38:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGLYYJ11903 for ipng-dist; Thu, 16 Nov 2000 13:34:34 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGLYFj11892 for ; Thu, 16 Nov 2000 13:34:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA21905 for ; Thu, 16 Nov 2000 13:34:15 -0800 (PST) Received: from starfruit.itojun.org (h010.p022.iij4u.or.jp [210.130.22.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13611 for ; Thu, 16 Nov 2000 13:34:14 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 329F47EF9; Fri, 17 Nov 2000 06:14:16 +0900 (JST) To: Brian E Carpenter Cc: Metzler Jochen , "'Francis Dupont'" , "Hesham Soliman (EPA)" , "Ipng (E-Mail)" In-reply-to: brian's message of Thu, 16 Nov 2000 13:27:34 CST. <3A143526.A89A1CEC@hursley.ibm.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: AW: Usage of IPv6 flow label From: Jun-ichiro itojun Hagino Date: Fri, 17 Nov 2000 06:14:16 +0900 Message-Id: <20001116211416.329F47EF9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >As far as I know neither diffserv nor intserv/RSVP know anything >about the flow label field. RSVP has a reference to flow label, in RFC2205 section A.9. 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 Nov 16 13:47:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGLkBn11977 for ipng-dist; Thu, 16 Nov 2000 13:46:12 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGLk1j11970 for ; Thu, 16 Nov 2000 13:46:01 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id eAGLjtB346549; Thu, 16 Nov 2000 13:45:55 -0800 (PST) Date: Thu, 16 Nov 2000 13:45:38 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU To: Jun-ichiro itojun Hagino Cc: Francis Dupont , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Hideaki YOSHIFUJI , Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20001116212213.76E867EFA@starfruit.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 don't understand what you are saying, at all. > ip6mtu_dst will be aligned to the alignment whatever necessary for us, > depending on how your compiler aligns it. sockaddr_in6 includes > struct in6_addr (sin6_addr), and if you declare in6_addr like: > struct in6_addr { > union { > uint8_t foo8[16]; > uint16_t foo16[8]; > uint32_t foo32[4]; > uint64_t foo32[2]; > } foo; > }; > ip6mtu_dst.sin6_addr should be aligned to 64bit boundary. > > > ip6mtu_dst will be aligned to whatever look natural to the machine > > based on sockaddr_in6 declaration. You are correct that the compiler will take care of this by inserting any necessary padding in the data structure. I think there were some concerns about data structure size when sockaddr_in6 was defined which is why the flowid was placed before the address. This ensured that even if in6_addr is 64 bit aligned the compiler wouldn't need to insert a pad of 32 bits. I don't know if there is a concern of wasting space in the ip6_mtuinfo structure by having compiler inserted padding. This can be avoided by placing the mtu after the sockaddr_in6. 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 Nov 16 13:51:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGLndj12003 for ipng-dist; Thu, 16 Nov 2000 13:49:39 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGLnPj11992 for ; Thu, 16 Nov 2000 13:49:25 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id eAGLnMB347144; Thu, 16 Nov 2000 13:49:22 -0800 (PST) Date: Thu, 16 Nov 2000 13:49:05 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: default router selection based on network topology To: itojun@iijlab.net Cc: Erik Nordmark , Robert Elz , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <12908.974410211@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'm still having fuzzy feeling about ICMPv6 redirects - if we have > famous web server in our network, and the web server picked > wrong (downstream) router as its default router, i'm not sure if > the amount of ICMPv6 redirects will be acceptable for us. I don't have any data to say how much it will be in such a case. The worst case is clearly something that exchanges exactly one packet with every IPv6 address on the planet where you'll see one redirect per sent IP packet. A web server typically sends a lot more than one IP packet per destination. But as I said I don't have any hard data here. > another thing - you will want to timeout redirect routes, as they will > chew your kernel memory space. you cannot keep them forever. Our implementation keeps them around until the kernel gets low on memory. 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 Nov 16 14:48:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGMl7J12109 for ipng-dist; Thu, 16 Nov 2000 14:47:07 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGMkuj12102 for ; Thu, 16 Nov 2000 14:46:56 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id eAGMkrB357091; Thu, 16 Nov 2000 14:46:53 -0800 (PST) Date: Thu, 16 Nov 2000 14:46:36 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPV6_USEMTU socket option To: Yves Legrandgerard Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com, Francis Dupont 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 > > On 16-Nov-00 JINMEI Tatuya wrote: > > Applications can dynamically grab the path MTU by the IPV6_RECVPATHMTU > > socket option (upon receiving an ICMPv6 packet toobig error). > > > > Is that mean, when IPV6_RECVPATHMTU option is setted (UDP/raw socket), that > fragmentation is disabled ? No, I don't think so. IPV6_RECVPATHMTU is so that e.g. UDP applications that do packetization can determine when the path MTU changes and adjust the size of the packets they are sending. Should we just define the semantic equivalent of setting IP_DF on a raw socket with IP_HDRINCL set for IPv6? (IPV6_DONTFRAG?) This would allow a traceroute to detect the MTU, and it would allow the above UDP example application to avoid "accidental" fragmentation by a too helpful IP/UDP layer. (The IP/UDP layer needs to be helpful for UDP applications which are not involved in PMTU discovery.) 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 Nov 16 15:57:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGNtR712186 for ipng-dist; Thu, 16 Nov 2000 15:55:27 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGNtIj12179 for ; Thu, 16 Nov 2000 15:55:18 -0800 (PST) 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,v1.7) with ESMTP id PAA15864 for ; Thu, 16 Nov 2000 15:55:18 -0800 (PST) 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 QAA29229 for ; Thu, 16 Nov 2000 16:55:16 -0700 (MST) 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 PAA29237; Thu, 16 Nov 2000 15:55:14 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eAGNtBl23170; Thu, 16 Nov 2000 15:55:11 -0800 X-Virus-Scanned: Thu, 16 Nov 2000 15:55:11 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdXcAqNp; Thu, 16 Nov 2000 15:55:04 PST Message-Id: <4.3.2.7.2.20001116153608.0238dca0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 16 Nov 2000 15:53:10 -0800 To: itojun@iijlab.net From: Bob Hinden Subject: Re: default router selection based on network topology Cc: ipng@sunroof.eng.sun.com In-Reply-To: <12908.974410211@coconut.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, > i'm still having fuzzy feeling about ICMPv6 redirects - if we have > famous web server in our network, and the web server picked > wrong (downstream) router as its default router, i'm not sure if > the amount of ICMPv6 redirects will be acceptable for us. The issue you are raising is inherent in IP (IPv4 and IPv6) and the decision long ago of not having the hosts participate in routing. I think a better solution is to change the topology to something like this: segment1 | routerA routerB--->(backbone) | | ---+--+-----------+--+--- | | Router Router | | ---+-+------+--+--- | | Web Host Server This puts your "famous web server" on a link where the outgoing router can pick the best next hop based on routing (and avoids the redirects). 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 Thu Nov 16 17:21:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAH1K8p12271 for ipng-dist; Thu, 16 Nov 2000 17:20:08 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAH1Jwj12264 for ; Thu, 16 Nov 2000 17:19:58 -0800 (PST) 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,v1.7) with ESMTP id RAA08869 for ; Thu, 16 Nov 2000 17:19:58 -0800 (PST) Received: from mlgw.sdcinc.co.jp ([203.140.145.99]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12081 for ; Thu, 16 Nov 2000 17:19:57 -0800 (PST) Received: from yokoyama [172.16.2.104] by mlgw.sdcinc.co.jp (SMTPD32-4.10) id A62A18003EA; Fri, 17 Nov 2000 10:17:14 +0900 Date: Fri, 17 Nov 2000 10:12:43 +0900 From: "Thomas Eklund" To: "'Jun-ichiro itojun Hagino'" , "'Mohit Goyal'" Cc: "'Markku Savela'" , Subject: RE: Regarding the Options headers Reply-To: X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <31A473DBB655D21180850008C71E251A02E90CCC@mail.kebne.se> X-RCPT-TO: Message-Id: <3A14860B1C7.DBA8THOMAS.EKLUND@172.16.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.25.04 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Itojun, > I believe thomas would like to see more use of flow label, like > for every TCP sessions. though there's no guarantee > that flow label > will identify each of TCP sessions (intermediate routes > cannot trust > the behavior of TCP endpoints), flow label should give thomas > a good indication for doing layer 4 classification. > > itojun What I said is that since the flow label is unassigned people are classifying their in their acces based on l4 info as well in the classification... I would on the other hand not object if in where mandatory for a host to set its flow label... -- 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 Thu Nov 16 21:30:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAH5TKA12346 for ipng-dist; Thu, 16 Nov 2000 21:29:20 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAH5TBj12339 for ; Thu, 16 Nov 2000 21:29:11 -0800 (PST) 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,v1.7) with ESMTP id VAA10588; Thu, 16 Nov 2000 21:29:09 -0800 (PST) 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 WAA28428; Thu, 16 Nov 2000 22:29:07 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id OAA08101; Fri, 17 Nov 2000 14:15:09 +0900 (JST) Date: Fri, 17 Nov 2000 14:28:31 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: default router selection based on network topology In-Reply-To: In your message of "Thu, 16 Nov 2000 13:49:05 -0800 (PST)" References: <12908.974410211@coconut.itojun.org> <4.3.1-J.20001117141757.02e7c6a8@ff.iij4u.or.jp> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 23 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 16 Nov 2000 13:49:05 -0800 (PST), >>>>> Erik Nordmark said: >> i'm still having fuzzy feeling about ICMPv6 redirects - if we have >> famous web server in our network, and the web server picked >> wrong (downstream) router as its default router, i'm not sure if >> the amount of ICMPv6 redirects will be acceptable for us. > I don't have any data to say how much it will be in such a case. > The worst case is clearly something that exchanges exactly one packet > with every IPv6 address on the planet where you'll see one redirect > per sent IP packet. A web server typically sends a lot more than > one IP packet per destination. But as I said I don't have any hard data > here. So, how about letting all routers in the segment where our "famous" web server is located advertise RA, and checking the ratio of outgoing TCP (or IP6) packets to incoming redirects on the server? 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 Nov 16 21:52:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAH5oph12390 for ipng-dist; Thu, 16 Nov 2000 21:50:51 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAH5ohj12383 for ; Thu, 16 Nov 2000 21:50:43 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA03532 for ; Thu, 16 Nov 2000 21:50:43 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA17414 for ; Thu, 16 Nov 2000 21:50:42 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 16 Nov 2000 21:49:54 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Thu, 16 Nov 2000 21:50:41 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80130C96D@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: ipng@sunroof.eng.sun.com Subject: RE: default router selection based on network topology Date: Thu, 16 Nov 2000 21:50:18 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK, I just submitted the promised draft on this topic... If you'd like to check it out early, you can find it here: ftp://ftp.research.microsoft.com/users/richdr/draft-draves-ipngwg-router-sel ection-00.txt Comments welcome! Thanks, 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 Nov 16 23:20:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAH7JMg12446 for ipng-dist; Thu, 16 Nov 2000 23:19:22 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAH7JDj12439 for ; Thu, 16 Nov 2000 23:19:13 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA10850 for ; Thu, 16 Nov 2000 23:19:14 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA10243 for ; Thu, 16 Nov 2000 23:19:14 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 16 Nov 2000 23:18:26 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Thu, 16 Nov 2000 23:19:13 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80130C973@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "'Dave Marquardt'" , Markku Savela Cc: "IPng List (E-mail)" Subject: RE: APIs for controlling source address selection Date: Thu, 16 Nov 2000 22:19:09 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > I have two possible designs for your consideration: A > > > (simple) and B (more complex). > > > > Either one is probably easy to implement and use. > > > > I'm just wondering whether this type thing is the right > direction to go with > > the API? It requires each application to include a user > controllable method > > for choosing these settings. > > "require" seems a bit strong here. I don't think any applications is > REQUIRED to use this interface. That's right. In fact, I expect relatively few applications would use these APIs, because I think the default behavior is right for most apps. In general, I think users should not be be controlling the use of these APIs. The application should know what makes sense. For example, if an application knows that it is creating short-lived TCP connections and it can survive the failure of a connection in case the host moves, then the application might prefer care-of addresses over home addresses. But this is something that the application knows, not the user. 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 Fri Nov 17 01:02:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAH8vgJ12550 for ipng-dist; Fri, 17 Nov 2000 00:57:42 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAH8vXj12543 for ; Fri, 17 Nov 2000 00:57:33 -0800 (PST) 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,v1.7) with ESMTP id AAA19697 for ; Fri, 17 Nov 2000 00:57:23 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.12.73.37]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA26267 for ; Fri, 17 Nov 2000 01:57:14 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id eAH8uM202332; Fri, 17 Nov 2000 15:56:22 +0700 (ICT) From: Robert Elz To: Richard Draves cc: ipng@sunroof.eng.sun.com Subject: Re: default router selection based on network topology In-reply-to: Your message of "Thu, 16 Nov 2000 21:50:18 PST." <7695E2F6903F7A41961F8CF888D87EA80130C96D@red-msg-06.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Nov 2000 15:56:22 +0700 Message-ID: <2330.974451382@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 16 Nov 2000 21:50:18 -0800 From: Richard Draves Message-ID: <7695E2F6903F7A41961F8CF888D87EA80130C96D@red-msg-06.redmond.corp.microsoft.com> | OK, I just submitted the promised draft on this topic... | If you'd like to check it out early, you can find it here: It is pretty much as expected - essentially a routing protocol, simplified. That is, the distinction between a host implementing this fully (your host C) and a host running "routed -q" is entirely illusory (the protocols have differences but they're not important ones here). Unfortunately, as much as we have always preferred for hosts to not engage in routing protocols, the number that do run routed -q and the obvious need to do something to handle multi-homed hosts (for which, as the draft points out, redirects are singularly useless), I suspect that we really need something like this. To the details ... The choice of a two bit signed number as the preference is quaint, though understandable... I'm not sure though that this belongs in RA - it is the kind of thing which I suspect I'd prefer to have a user level application dealing with, and so having it as a UDP protocol would have a lot of advantages, even if it currently does gain some advantages by sharing quite a bit with what RAs already offer at the more primitive level - and that most likely a host would want to use only one method - this new protocol, or RAs as its method for finding routers. This is kind of a big uncertainty in my mind. I'd probably make the routing info messages variable length though, padded to whatever alignment needs to be enforced, but not necessarily to the maximum address length (ie: sending a 128 bit address to say 0::0/0 seems a bit overboard). I wouldn't want to restrict the prefixes that can be advertised to max 64 bits though, that would be an overly restrictive optimisation for future flexibility - hosts should treat add addresses as simply 128 bits masked (other than for autoconf purposes, when that is enabled). 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 Nov 17 02:30:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHATRo12659 for ipng-dist; Fri, 17 Nov 2000 02:29:27 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHATIj12652 for ; Fri, 17 Nov 2000 02:29:18 -0800 (PST) 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,v1.7) with ESMTP id CAA15544 for ; Fri, 17 Nov 2000 02:29:18 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.12.73.37]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA02215 for ; Fri, 17 Nov 2000 03:29:11 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id eAHASL202637; Fri, 17 Nov 2000 17:28:21 +0700 (ICT) From: Robert Elz To: Richard Draves , ipng@sunroof.eng.sun.com Subject: Re: default router selection based on network topology In-reply-to: Your message of "Fri, 17 Nov 2000 15:56:22 +0700." <2330.974451382@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Nov 2000 17:28:21 +0700 Message-ID: <2635.974456901@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have been thinking about this a little more, and I suspect that if this is to fly, the currently unassigned "10" preference value is going to be needed (but is is OK, it fits the "signed 2 bit integer model well enough as "-2" .. more negative than "11"). That is, I think there needs to be a "blackhole" (or unreachable) preference as well as "bad" "average" "good" (or low medium high). Without that, there's no way to subtract out a piece from a large block, and you're left having to instead to form the address space you want to reference from the union of a lot of smaller blocks, which is error prone (though I guess it could be done in software with a configuration language that includes a blackhole) and generates much larger RAs (or whatever they turn out to be). For example, in your section 5.2, if router Y simply identifies itself as a default router, then it is claiming that it can reach the isolated corporate net that is really only reachable via X (which it is assumed isn't connected to Y, or known to it). That's not good. While X is alive, things work, as its more specific route will be used instead of the default from Y. But when X is down, there's nothing to stop traffic heading at Y. This may sound like not much of a problem, as if the corporate net can't be reached at all (its only gateway being down) then not reaching it via Y might not seem like much of a problem - but it does mean that what might be potentially sensitive corporate information, that wasn't ever intended to go anywhere near Y (and who knows how much further before the default routes end and the lack of a specific route is detected) which is being dumped that direction (this could be as simple as SNMP traps from C - so there is no need to postulate the establishment of a TCP connection before any real data is sent). So, I would suggest allocating that final code as "unreachable", with the interpretation by the host that after running the algorithm the route selected is unreachable, then packets should simply be discarded (with an appropriate error to the application). 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 Nov 17 03:57:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHBtgS12727 for ipng-dist; Fri, 17 Nov 2000 03:55:42 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHBtXj12720 for ; Fri, 17 Nov 2000 03:55:33 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA05432 for ; Fri, 17 Nov 2000 03:55:33 -0800 (PST) From: John.Burgess@predictive.com Received: from athena.predictive.com (athena.predictive.com [208.209.197.197]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11383 for ; Fri, 17 Nov 2000 03:55:32 -0800 (PST) To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: Regarding the Options headers X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Fri, 17 Nov 2000 06:59:03 -0500 X-MIMETrack: Serialize by Router on Athena/Predictive(Release 5.0.5 |September 22, 2000) at 11/17/2000 06:59:11 AM, Serialize complete at 11/17/2000 06:59:11 AM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm usually just a listener on this group, but I have to put in my 2 cents here. I am a consultant designing the network for a new "campus in a high rise" for a major financial institution. 1) Mainframes and minis are NOT dead. Talk to anyone at IBM, Sun, or HP, or other high-end server manufacturers. These boxes TODAY have Gig-E interfaces and can consume a significant fraction (and not just brief bursts). 2) Even the edges are getting faster. User workstations all have 100bT Fdx interfaces. Streaming video is a requirement. Uplinks from my edge switches are Gig-E. 3) Latency is a serious issue. Users currently have 3ms or better round-trip latency to every server in the company. They will not tolerate a reduction in this SLA, rather it must improve with each new generation of hardware. 4) Need I say it ... Moore's law is NOT dead. Expect all feeds and speeds to continue to go up and up... Therefore, IPv6 MUST be implemented in hardware, and MUST forward at line rates (ALL future line rates!) with layer 4 QoS, ACLs, and all the other goodies that we dream up at the same time. Or else! Or else it will stay a research toy and not fulfill its destiny of replacing IPv4 in the Real Internet. So there's the challenge. Find some way to, as Jean-Luc Picard would say, "make it so". Have fun guys! :-) John Burgess Principal Consultant Predictive Systems, Inc. Francis Dupont Sent by: owner-ipng@sunroof.eng.sun.com 11/16/00 04:01 AM To: thomas.eklund@xelerated.com cc: "'Steve Deering'" , "'Brian Zill'" , ipng@sunroof.eng.sun.com Subject: Re: Regarding the Options headers In your previous mail you wrote: > but it becomes an issue when you implement IPv6 in asic!! > > => just don't do layer 4 classification in a router? > Seriously I expect to avoid a IPv4-like situation where > options are not > used because they are processed slowly then not used then... this is just to easy to say that. layer 4 classification will be used in the campus backbone/high-end enterprise and with the current solution it is very difficult to do it if you have any speed (we see 1GE links today and we will see even 10 GE links very soon) => today a standard box can't run at 1GE then I suppose your links are not the host-router links but already campus backbone links. There are no good definition of what is an edge router but it seems that the campus backbone is too fast, ie. edge devices are between hosts and the backbone. so it is an issue if we want ipv6 hot "hit" in the enterprise networks and campus networks... => if an ASIC can do layer >= 4 classification at the host-router link speed then this will work. Today hosts used in number crunching places are cheap dual-CPU PC boxes in clusters (according to what I saw at CERN) then it works. I don't believe we'll see again fast boxes with many high speed buses (mainframes are history, minis are history, workstations become history, ...) then the high-speed router camp should win. if we dont solve the problem that IPv4 routers do today we are on the wrong path... => I don't believe IPv6 has a real disavantage here, it is more a problem of "IPv6 is not yet here then don't put man power on it". Packets in the same flow are similar enough than the caching & hashing strategy works. One might argue that why not use intserv and treat the flowlabel as a intserv flow and let the router map several flow into traffic classes of aggregated traffic (DSCP classes) but then it is up to the flow label to decide and that is as we know undefined.... => this is what to do for core routers. There is and will be no other solutions because core routers need to be *fast*! > Have people thought about/What do people think about > changing the length > field > > => which one? The IPv6 header length field *is* useful and there is no > free space. I meant the Payload Length.... This is the whole point... I think you missed my point. => I had the wish I missed it. You can't reuse the payload length because it is *not* free. You propose to create a very different protocol with a different (likely larger) header... I wanted a chance to classify on the trnasport header without having to have a loop that first look into the first "next header" and then looks into the senocd extension header "next header" pointer and then look into the next one and in the next one... => the extension header chain is in the base design of IPv6: you want another protocol. BTW I'd like to know what is the transport header in VPNs (which are more and more common). > => I think nothing good of this. It is not the job of a > router to look at > inside packets (ESP will save us!) People that implement this in hardware see this problem TODAY... And of course if the packet is encrypted with an ESP then it is no use to classify on L4 but then we could have a flag in the flow label field that " signalled inband" that we have no way to do this, than we could aggregate this in the router and block any QoS related policy that included layer for instance... => QoS related policy that included layer >= 4 was proved as unfeasible in RSVP trials. The issue was more the unscalable nature of signaling than classification but in order to use QoS related policy you have to solve the untracktable signaling problem first... But in most cases there sits a firewall at the same place where we have the edge router and then the traffic comes unencrypted to the router => stop here. Even if today IPsec is VPN we expect in the future to have end-to-end IPsec. But if you believe there is a firewall then the firewall has the same problem (it wants to apply layer >= 4 filtering rules) then you can mark (DSCP + flow label) packets at the same place: or I don't understand your argument or we agree? and we might want to classify the traffic into a DSCP based on layer 4 info (As a side note: I have spoken to several operators that do exactly this way today for IPv4 >... Of course I'm in favour of having the edge routers classify the packets. => I believe the core routers are not able to classify the packets then my position is a bit more than "in favour". 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 17 04:28:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHCRR312781 for ipng-dist; Fri, 17 Nov 2000 04:27:27 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHCRHj12774 for ; Fri, 17 Nov 2000 04:27:18 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA07884 for ; Fri, 17 Nov 2000 04:27:17 -0800 (PST) Received: from ish7.ericsson.com.au ([203.61.155.111]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18920 for ; Fri, 17 Nov 2000 04:27:15 -0800 (PST) Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id XAA11309; Fri, 17 Nov 2000 23:23:32 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id XAA20777; Fri, 17 Nov 2000 23:26:21 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Nov 2000 23:26:35 +1100 Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613E0F@eaubrnt018.epa.ericsson.se> From: "Hesham Soliman (EPA)" To: "'Michael Thomas'" Cc: "'Ipng (E-Mail) '" Subject: RE: Usage of IPv6 flow label Date: Fri, 17 Nov 2000 23:26:34 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Hesham Soliman (EPA) writes: > > > > Er, by what protocol does it inform the router? > > > > > > > => A 3GPP protocol. > > > > Which is different from an IETF protocol? > > > > => Yes. Otherwise it would not be a 3GPP protocol ;) > > Is there some compelling reason why RSVP is not > that protocol, or is this yet another case of > the parochial "our layer 2 is _so_ different we > can't possibly use widely accepted and standards > based protocols." > => You have to ask someone from 3GPP who worked on that protocol. There are some reasons for their chioces, whether you agree with it or not it's a different story. You can get more detail if you ask the people who invented these protocols. Anyway this is getting outside this mailing list's interest. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 17 04:32:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHCVk112804 for ipng-dist; Fri, 17 Nov 2000 04:31:46 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHCVbj12797 for ; Fri, 17 Nov 2000 04:31:37 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA13421 for ; Fri, 17 Nov 2000 04:31:36 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA16672 for ; Fri, 17 Nov 2000 04:31:35 -0800 (PST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id NAA02623 for ipng@sunroof.eng.sun.com; Fri, 17 Nov 2000 13:31:33 +0100 (MET) Date: Fri, 17 Nov 2000 13:31:33 +0100 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Subject: Re: Regarding the Options headers Message-ID: <20001117133133.C1773@theory.cs.uni-bonn.de> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="mxv5cy4qt+RJ9ypb" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from John.Burgess@predictive.com on Fri, Nov 17, 2000 at 06:59:03AM -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --mxv5cy4qt+RJ9ypb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 17, 2000 at 06:59:03AM -0500, John.Burgess@predictive.com wrote: > Therefore, IPv6 MUST be implemented in hardware, and MUST forward at line= =20 > rates > (ALL future line rates!) with layer 4 QoS, ACLs, and all the other goodie= s=20 > that we dream up at the same time. I'm wondering: - Are you also saying that end-to-end ESP must be made a MUST NOT? (in which case you are complaining much too late, I think). While I'm convinced that the Power Router Vendors Out There will implement= =20 option header chasing for filtering purposes as soon as they think they can sell it, getting at Level 4 on encrypted traffic is simply impossible. Well, we should hope so. Regards, -is --mxv5cy4qt+RJ9ypb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBOhUlIDCn4om+4LhpAQH86ggAlQIHSDpplfedvWrKHxkO7cMmtwY/k2w4 eC5TJzecHMnH1SPITSVTHLEM52YLdVtkzYhc4yNBqEHPz7vxSTSN7y5P9VgLuHuu UbxzS5S5hSudhRVQa9fvOznbpFHHlH7nkci7UwpG+xor9mo6XfJZscy3osKJ6/tD 6U/Rf+UK888+aL3JKTxCSz3GPwv0jaC27eJ7t78fOHUH/HF6/HWFNMeTsxF3Hosu M2HIiUcYMgzHJrVCa82gfjyLKU+F1DUIYebRKGmFD8T+GZX2YFD1fUONXq28JS2w LsxiVy3SEvlc7oVIpBtRQsc4MeXeNdxl7qRLTea58OgdBicF4gYS4w== =Y7GK -----END PGP SIGNATURE----- --mxv5cy4qt+RJ9ypb-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 17 05:25:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHDNf912875 for ipng-dist; Fri, 17 Nov 2000 05:23:41 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHDNWj12868 for ; Fri, 17 Nov 2000 05:23:32 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA18733 for ; Fri, 17 Nov 2000 05:23:33 -0800 (PST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA02594 for ; Fri, 17 Nov 2000 05:23:32 -0800 (PST) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA25072; Fri, 17 Nov 2000 14:22:56 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA10664; Fri, 17 Nov 2000 14:23:29 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Nov 2000 14:23:28 +0100 Message-ID: <158669A6D0F5D3119B940060086D94F55006CA@ULML202E> From: Metzler Jochen To: "'Hesham Soliman (EPA)'" , "'Michael Thomas'" Cc: "'Ipng (E-Mail) '" Subject: AW: Usage of IPv6 flow label Date: Fri, 17 Nov 2000 14:23:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id eAHDNXj12869 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk some words for clarification, regarding the flow label within 3GPP: as far as I know is the flow label ONLY part of the Packet Filter Attributes, which are used to classify User Packets (- from an 3GPP point of view -) to distinguish between several connection of a certain user. It is only an optional criteria in the case of IPv6 User IP. (see 3GPP TS26.060) -- jochen -----Ursprüngliche Nachricht----- Von: Hesham Soliman (EPA) [SMTP:Hesham.Soliman@ericsson.com.au] Gesendet am: Freitag, 17. November 2000 13:27 An: 'Michael Thomas' Cc: 'Ipng (E-Mail) ' Betreff: RE: Usage of IPv6 flow label > Hesham Soliman (EPA) writes: > > > > Er, by what protocol does it inform the router? > > > > > > > => A 3GPP protocol. > > > > Which is different from an IETF protocol? > > > > => Yes. Otherwise it would not be a 3GPP protocol ;) > > Is there some compelling reason why RSVP is not > that protocol, or is this yet another case of > the parochial "our layer 2 is _so_ different we > can't possibly use widely accepted and standards > based protocols." > => You have to ask someone from 3GPP who worked on that protocol. There are some reasons for their chioces, whether you agree with it or not it's a different story. You can get more detail if you ask the people who invented these protocols. Anyway this is getting outside this mailing list's interest. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Nov 17 05:47:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHDjgN12923 for ipng-dist; Fri, 17 Nov 2000 05:45:42 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHDjXj12916 for ; Fri, 17 Nov 2000 05:45:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA21142; Fri, 17 Nov 2000 05:45:32 -0800 (PST) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA09692; Fri, 17 Nov 2000 05:45:28 -0800 (PST) Received: from godel.logique.jussieu.fr (root@godel.logique.jussieu.fr [134.157.19.1]) by shiva.jussieu.fr (8.10.0/jtpda-5.3.3) with ESMTP id eAHDjIt71221 ; Fri, 17 Nov 2000 14:45:18 +0100 (CET) Received: from bernays.logique.jussieu.fr (bernays.logique.jussieu.fr [134.157.19.71]) by godel.logique.jussieu.fr (8.9.3/jtpda-5.3.1) with ESMTP id OAA32151 ; Fri, 17 Nov 2000 14:44:59 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 17 Nov 2000 14:50:38 +0100 (CET) From: Yves Legrandgerard To: Erik Nordmark Subject: Re: IPV6_USEMTU socket option Cc: Francis Dupont , ipng@sunroof.eng.sun.com, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 16-Nov-00 Erik Nordmark wrote: >> >> On 16-Nov-00 JINMEI Tatuya wrote: >> > Applications can dynamically grab the path MTU by the IPV6_RECVPATHMTU >> > socket option (upon receiving an ICMPv6 packet toobig error). >> > >> >> Is that mean, when IPV6_RECVPATHMTU option is setted (UDP/raw socket), that >> fragmentation is disabled ? > > No, I don't think so. > IPV6_RECVPATHMTU is so that e.g. UDP applications that do packetization > can determine when the path MTU changes and adjust the size of the > packets they are sending. > > Should we just define the semantic equivalent of setting IP_DF on > a raw socket with IP_HDRINCL set for IPv6? (IPV6_DONTFRAG?) [ylg]=> Yes, that's exactly wee need, a socket option like : int on = 1; setsockopt(fd, IPPROTO_IPV6, IPV6_DONTFRAG, &on, sizeof(&on)); to disable fragmentation for UDP/Raw sockets (and of course on = 0 to (re)enable fragmentation which would be the default). > This would allow a traceroute to detect the MTU, and it would allow > the above UDP example application to avoid "accidental" fragmentation > by a too helpful IP/UDP layer. (The IP/UDP layer needs to be helpful for > UDP applications which are not involved in PMTU discovery.) > > Erik As we said in a previous message, F. Dupont and me, a useful option would be a new option to getsockopt() to get the outgoing MTU. For example, it helps tracemtu to discover the right mtu to start (otherwise, we have to set IPV6_DONTFRAG option, and try successive MTU (choosen in a list of possible MTU, ordered decreasingly) until we don't get EMSGSIZE error (an other pb : does exist such a list, i.e. the (right) list of all possible MTUs?). Regards, ---------------------------------- Yves Legrandgérard E-Mail: ylg@logique.jussieu.fr Date: 17-Nov-00 Time: 14:24:22 ---------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 17 06:01:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHDxoc12953 for ipng-dist; Fri, 17 Nov 2000 05:59:50 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHDxfj12945 for ; Fri, 17 Nov 2000 05:59:41 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA22749 for ; Fri, 17 Nov 2000 05:59:42 -0800 (PST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15357 for ; Fri, 17 Nov 2000 05:59:41 -0800 (PST) Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id eAHDxbr04055; Fri, 17 Nov 2000 14:59:38 +0100 (MET) Received: from alcatel.be ([138.203.65.20]) by bemail04.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C125699A.004CDBF2; Fri, 17 Nov 2000 14:59:30 +0100 Message-ID: <3A153972.3439F0B7@alcatel.be> Date: Fri, 17 Nov 2000 14:58:10 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Brian Zill CC: ipng@sunroof.eng.sun.com Subject: Re: Mutable fields and the Hop-by-Hop and Destination Options headers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have the impression that a lot of the complexity in these chained extension headers is caused by the way Source Routing is specified. If Source Routing would be a hop-by-hop extension and the IPv6 destination was always the final destination the header mess wouldn't be that big (the disadvantage being that Loose Source Routed packets need additional procesing in non-fixed hops, but who is using Source Routing anyhow?). dirk Brian Zill wrote: > > Hi all, got a question about mutable options. > > As described in RFC 2460, Option Type identifiers have an encoded bit (aka > the mutable option bit) indicating "whether or not the Option Data of that > option can change en-route to the packet's final destination". This allows > new IPv6 options to be defined with contents that may be changed by either > routers or intermediate destinations along the way to the final destination, > without breaking IPsec authentication. > > RFC 2460 also specifies the recommended Extension Header Order as: > > IPv6|HbH|DO1|RH|FH|AH|ESP|DO2|TCP/UDP/etc > > where DO1 is "for options to be processed by the first destination that > appears in the IPv6 Destination Address field plus subsequent destinations > listed in the Routing header", and DO2 is "for options to be processed only > by the final destination of the packet". The exact order is only a > recommendation, but the distinction between Destination Options headers that > appear before the Routing Header versus those that appear after it is the > important part here. > > From the above, one could reasonably conclude that mutable options should > only appear in Hop-by-Hop and Destination Options 1, and not in Destination > Options 2. Options that appear in DO2 have no need to be mutable since this > header is never examined until after the packet has arrived at the final > destination. And in fact, if they were mutable and mutated in-flight, they > would break things like ESP in null-encryption authentication-only mode. > > Unfortunately, this requirement that mutable options not appear after the > Routing Header is not explicitly stated in the spec anywhere. And it > matters for how one calculates the ICV when processing AH headers (since the > calculation treats mutable options as zeroed fields in all cases). If one > allows mutable options to appear anywhere, then the AH ICV calculation needs > to parse past the AH header through to the end of the packet, instead of > being able to treat everything inside of the AH header as an opaque blob. > This would needlessly complicate the AH ICV calculation for no practical > reason. > > Therefore, I'd like to propose that the spec is clarified to limit mutable > options to where they make sense, i.e. in Hop-by-Hop and Destination Options > headers that appear before the Routing Header. > > Comments? > > Thanks, > --Brian > > P.S. As an aside, it occurs to me that it might be clearer to define a new > "Intermediate Destination Options" header to take the place of DO1. Then it > could be declared that this new header (if present) MUST appear before the > Routing Header, and that mutable options (if present) MUST appear in either > this new header or a Hop-by-Hop header. Or to put it another way, mutable > options wouldn't be allowed any more in a Destination Options header. This > would also make the spec cleaner - it could get rid of the special case > notations explaining the difference between DO1 and DO2. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 17 07:03:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHF0QW13019 for ipng-dist; Fri, 17 Nov 2000 07:00:26 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHExsj13012 for ; Fri, 17 Nov 2000 07:00:01 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA29607 for ; Fri, 17 Nov 2000 06:59:54 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18624 for ; Fri, 17 Nov 2000 06:59:54 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id GAA11934; Fri, 17 Nov 2000 06:53:01 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <2330.974451382@brandenburg.cs.mu.OZ.AU> References: <2330.974451382@brandenburg.cs.mu.OZ.AU> Date: Fri, 17 Nov 2000 06:52:59 -0800 To: Robert Elz From: Steve Deering Subject: Re: default router selection based on network topology Cc: Richard Draves , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 3:56 PM +0700 11/17/00, Robert Elz wrote: >I'm not sure though that this belongs in RA - it is the kind of thing >which I suspect I'd prefer to have a user level application dealing >with, and so having it as a UDP protocol would have a lot of advantages, There are also advantages, and architectural arguments, for keeping it as part of ICMP. An intermediate approach would be to keep it in ICMP, but in a separate (new) message type, to facilitate separate processing. (Note that ICMP Echo Requests are typically handled by user-space ping clients, so the fact that something is part of ICMP certainly does not rule out its implementation in user space.) However, my first choice would be the same as Richard's, i.e., included in RAs. 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 Fri Nov 17 07:20:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHFIii13082 for ipng-dist; Fri, 17 Nov 2000 07:18:44 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHFIXj13075 for ; Fri, 17 Nov 2000 07:18:33 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id eAHFIWB462018; Fri, 17 Nov 2000 07:18:32 -0800 (PST) Date: Fri, 17 Nov 2000 07:18:14 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPV6_USEMTU socket option To: Yves Legrandgerard Cc: Erik Nordmark , Francis Dupont , ipng@sunroof.eng.sun.com, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= 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 > [ylg]=> Yes, that's exactly wee need, a socket option like : > int on = 1; > > setsockopt(fd, IPPROTO_IPV6, IPV6_DONTFRAG, &on, sizeof(&on)); > to disable fragmentation for UDP/Raw sockets (and of course on = 0 to > (re)enable fragmentation which would be the default). I'll add it to 2292bis. > As we said in a previous message, F. Dupont and me, a useful option would be > a new option to getsockopt() to get the outgoing MTU. For example, it helps > tracemtu to discover the right mtu to start (otherwise, we have to set > IPV6_DONTFRAG option, and try successive MTU (choosen in a list of possible > MTU, ordered decreasingly) until we don't get EMSGSIZE error (an other pb : > does exist such a list, i.e. the (right) list of all possible MTUs?). Presumably such an option needs to take a sockaddr_in6 as an argument to specify the destination. We can reuse the proposed ip6_mtuinfo structure for this. Do you care to know whether the kernel has path mtu information or is just returning the mtu of the outgoing 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 Nov 17 07:52:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHFoJj13179 for ipng-dist; Fri, 17 Nov 2000 07:50:19 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHFoAj13172 for ; Fri, 17 Nov 2000 07:50:10 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA00363 for ; Fri, 17 Nov 2000 07:50:11 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23366 for ; Fri, 17 Nov 2000 07:50:10 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA17428; Fri, 17 Nov 2000 07:49:45 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <3A153972.3439F0B7@alcatel.be> References: <3A153972.3439F0B7@alcatel.be> Date: Fri, 17 Nov 2000 07:49:43 -0800 To: Dirk Ooms From: Steve Deering Subject: Re: Mutable fields and the Hop-by-Hop and Destination Options headers Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 2:58 PM +0100 11/17/00, Dirk Ooms wrote: >I have the impression that a lot of the complexity in these chained >extension headers is caused by the way Source Routing is specified. The chained headers aren't complex. (Warning: digression ahead...) The issues under discussion arise from the extra-architectural use of layer-violating devices along a delivery path. The Flow Label is in IPv6 specifically to avoid the need for (and the parsing expense/ complexity of ) looking at transport-layer port fields to do flow classification. Perhaps we ought to have moved the port fields into the IP header instead, as in Xerox's XNS / Novell's IPX; that was actually considered and discussed at great length in the early days of IPv6's predecessor, SIP, and rejected as being too radical a change to the IP architecture which would have required significant redesign of IP implementations. And though that would have made it easier to do port-based firewall filtering for IPv6, it wouldn't have helped all the other forwarding-path layer-violations that some people deem desirable today, e.g., stateful firewalls, "performance-enhancing proxies", "layer 7 switching", etc., but all of those are at odds with end-to-end encryption, which we were/are hoping will someday become common in the Internet. Better to put the effort into IP-architecture -compatible solutions to those other problems. I'm also surprised that people are using the rationale that speeds are increasing to argue for changing IPv6 to make it easier for the routers to do more functions than just forwarding packets. I would think that ever increasing speeds are a reason to *reduce* the number of tasks that routers do. (For example, that's why we eliminated a header checksum from IPv6.) >If Source Routing would be a hop-by-hop extension and the IPv6 >destination was always the final destination the header mess wouldn't be >that big (the disadvantage being that Loose Source Routed packets need >additional procesing in non-fixed hops, but who is using Source Routing >anyhow?). Mobile IPv6 is using the Routing header. There's some chance that that that header will show up in a significant number of IPv6 packets, some day. (I happen to think it was a mistake to use the Routing header for Mobile IPv6 -- encapsulation would have been much better -- but it's probably too late to do anything about that now.) 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 Fri Nov 17 08:03:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHG1q613206 for ipng-dist; Fri, 17 Nov 2000 08:01:52 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHG1hj13199 for ; Fri, 17 Nov 2000 08:01:43 -0800 (PST) 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,v1.7) with ESMTP id IAA15539 for ; Fri, 17 Nov 2000 08:01:43 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21107 for ; Fri, 17 Nov 2000 09:01:41 -0700 (MST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA17947; Fri, 17 Nov 2000 07:54:49 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <12539.974291444@brandenburg.cs.mu.OZ.AU> References: <12539.974291444@brandenburg.cs.mu.OZ.AU> Date: Fri, 17 Nov 2000 07:54:47 -0800 To: Robert Elz From: Steve Deering Subject: Re: Mutable fields and the Hop-by-Hop and Destination Options headers Cc: Brian Zill , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 7:30 PM +0700 11/15/00, Robert Elz wrote: >Please, no - the double use of the DO header is a thing of beauty. >It, just by being there, makes clear the way the IPv6 header structure >is to work, it makes clear that headers can appear more than once, >it makes clear that the interpretation of a header depends upon where >in the sequence of headers it is found, it makes clear the onion >peeling parsing technique that is defined to apply to IPv6 headers, >and is a very clean architectural design. Yes, that's what I should have said. :-) 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 Fri Nov 17 08:14:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHGCsW13242 for ipng-dist; Fri, 17 Nov 2000 08:12:54 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHGCjj13235 for ; Fri, 17 Nov 2000 08:12:45 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA17395 for ; Fri, 17 Nov 2000 08:12:45 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09034 for ; Fri, 17 Nov 2000 08:12:37 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAHGBib36363; Fri, 17 Nov 2000 17:11:44 +0100 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 RAA19743; Fri, 17 Nov 2000 17:11:42 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id RAA97968; Fri, 17 Nov 2000 17:14:03 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011171614.RAA97968@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tim Hartrick cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU In-reply-to: Your message of Thu, 16 Nov 2000 11:45:15 PST. <200011161945.LAA25723@feller.mentat.com> Date: Fri, 17 Nov 2000 17:14:03 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => I disagree, I'd like to be able to defined struct in6_addr as a pair > of 64 bit integers one day (:-)! I don't understand the point. The two 64 bit fields will be forced onto their natural boundaries. This might lead to the compiler adding padding between the ip6mtu_mtu and ip6mtu_dst but so what. => not so what, I prefer to have a layout which gives the same padding with 4*32 and 2*64 bit definitions! This structure doesn't go on the wire so padding that is added by the compiler is not relevent. => with a right order 4*32 and 2*64 are binary compatible and you can get this nice property for free. Francis.Dupont@enst-bretagne.fr PS: I've tried one day the 2*64 definition on a Sparc (ie. with 64 bit alignment). It didn't work because of some details, for instance the route structure (pointer + sockaddr) or IPv6 over ATM (32 bit difference in alignment between unicast and multicast). I can't see a good reason to add a new source of problems... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 17 08:18:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHGHRv13273 for ipng-dist; Fri, 17 Nov 2000 08:17:27 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHGHIj13266 for ; Fri, 17 Nov 2000 08:17:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA16751 for ; Fri, 17 Nov 2000 08:17:18 -0800 (PST) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07648 for ; Fri, 17 Nov 2000 08:17:17 -0800 (PST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 13wo56-0004GL-00; Fri, 17 Nov 2000 11:09:40 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA13418; Fri, 17 Nov 00 11:04:55 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id LAA13388; Fri, 17 Nov 2000 11:09:35 -0500 Message-Id: <3A155838.F2BD900F@txc.com> Date: Fri, 17 Nov 2000 11:09:28 -0500 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Michael Thomas Cc: Francis Dupont , Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <20001115190919.321B17EF9@starfruit.itojun.org> <200011160958.KAA90047@givry.rennes.enst-bretagne.fr> <14867.59850.899996.178063@thomasm-u1.cisco.com> <3A142DEE.AA44B45F@txc.com> <14868.12090.132937.881088@thomasm-u1.cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF50DD4A14773AEDABEF79443" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msF50DD4A14773AEDABEF79443 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit You missed my point: the Diffserv field is used for QoS flow aggregation and not packet forwarding. Alex Michael Thomas wrote: > > Alex Conta writes: > > If flow IDs are used for fast forwarding, without the ability to rewrite > > them, it seems to me > > that a router will not be able to aggregate flows. > > Boy, I may be missing something really stupid, but > the DSCP seems like the obvious flow aggregation > handle to me. > > Mike > > > > Alex > > > > > > Michael Thomas wrote: > > > > > > Francis Dupont writes: > > > > In your previous mail you wrote: > > > > > > > > flow label field is not part of AH calculation, but as RSVP already > > > > requires it to be end-to-end (not hop-by-hop) i think we shouldn't > > > > rewrite it in transit. > > > > > > > > => I don't read your argument as you. I'll say it should not be rewritten > > > > in transit if RSVP is in use. A DiffServ edge router can rewrite it > > > > in some situation (it is supposed to know what is RSVP and do the right > > > > thing). > > > > > > Why would a diffserv router _want_ to rewrite a flow label? > > > It can still rewrite the DSCP if it wants. The only thing > > > that I've seen mentioned that could actually take advantage > > > in the way you are mentioning is using the flow label for > > > MPLS label swapping bits. > > > > > > Mike > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- --------------msF50DD4A14773AEDABEF79443 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKBgYJKoZIhvcNAQcCoIIJ9zCCCfMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICETCCAg0CAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDExMTcxNjA5MzBaMCMGCSqGSIb3DQEJBDEWBBQ94BuzsuAmijyRYG2D hZD0D3MQ0DAnBgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAtQXh6GYYrKm5t1S1gkp2vf/G8U3eVWmNTHsIfDWZks8npNBMtRuA/2lb S/pP37xAIS5Q8YExKybLs3Moakuv/iaGCG6bMDtPIw1drKRSBbPmKOO4VMkxMh/q5Zu/tvFv cVrWLBLvFxk/7/Zsojwb5EcoATri1bhE7wdudaOxrTM= --------------msF50DD4A14773AEDABEF79443-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 17 08:19:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHGIQE13282 for ipng-dist; Fri, 17 Nov 2000 08:18:26 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHGI7j13275 for ; Fri, 17 Nov 2000 08:18:08 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA18286 for ; Fri, 17 Nov 2000 08:18:08 -0800 (PST) Received: from starfruit.itojun.org (ny-ppp012.iij-us.net [216.98.99.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11220 for ; Fri, 17 Nov 2000 08:18:06 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 48FBF7EF9; Sat, 18 Nov 2000 01:18:01 +0900 (JST) To: Francis Dupont Cc: Tim Hartrick , ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Fri, 17 Nov 2000 17:14:03 +0100. <200011171614.RAA97968@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: [advanced API] how to get the destination address for IPV6_RECVPATHMTU From: Jun-ichiro itojun Hagino Date: Sat, 18 Nov 2000 01:18:01 +0900 Message-Id: <20001117161801.48FBF7EF9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >PS: I've tried one day the 2*64 definition on a Sparc (ie. with 64 bit >alignment). It didn't work because of some details, for instance the >route structure (pointer + sockaddr) or IPv6 over ATM (32 bit difference >in alignment between unicast and multicast). I can't see a good reason >to add a new source of problems... for the latter case, you need __attribute__((__packed__)) (gcc-ism) for header declaration. to control structure packing. 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 Nov 17 08:24:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHGNRF13329 for ipng-dist; Fri, 17 Nov 2000 08:23:27 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHGNBj13306 for ; Fri, 17 Nov 2000 08:23:12 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA18214; Fri, 17 Nov 2000 08:23:10 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10948; Fri, 17 Nov 2000 08:23:08 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAHGL4b45297; Fri, 17 Nov 2000 17:21:05 +0100 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 RAA20103; Fri, 17 Nov 2000 17:21:03 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id RAA98049; Fri, 17 Nov 2000 17:23:23 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011171623.RAA98049@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jun-ichiro itojun Hagino cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Hideaki YOSHIFUJI (=?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?=) , Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU In-reply-to: Your message of Fri, 17 Nov 2000 06:22:13 +0900. <20001116212213.76E867EFA@starfruit.itojun.org> Date: Fri, 17 Nov 2000 17:23:23 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >=> I disagree, I'd like to be able to defined struct in6_addr as a pair >of 64 bit integers one day (:-)! I don't understand what you are saying, at all. => if in6_addr is defined as four 32 bit integers then the compiler won't add padding. If it is defined as a pair of 64 bit integers the compiler may add 32 bits for padding if the MTU field is before and the architecture needs 64 bit alignment for 64 bit quantities. ip6mtu_dst will be aligned to the alignment whatever necessary for us, depending on how your compiler aligns it. sockaddr_in6 includes struct in6_addr (sin6_addr), and if you declare in6_addr like: struct in6_addr { union { uint8_t foo8[16]; uint16_t foo16[8]; uint32_t foo32[4]; uint64_t foo32[2]; => but we (you and me) have not the last definition, I don't know your reasons but I tried and got too many problems. } foo; }; ip6mtu_dst.sin6_addr should be aligned to 64bit boundary. 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 Nov 17 08:46:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHGinu13369 for ipng-dist; Fri, 17 Nov 2000 08:44:49 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHGiej13361 for ; Fri, 17 Nov 2000 08:44:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA23925 for ; Fri, 17 Nov 2000 08:44:40 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21357 for ; Fri, 17 Nov 2000 09:44:38 -0700 (MST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA22439; Fri, 17 Nov 2000 08:36:01 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <3A142DEE.AA44B45F@txc.com> References: <20001115190919.321B17EF9@starfruit.itojun.org> <200011160958.KAA90047@givry.rennes.enst-bretagne.fr> <14867.59850.899996.178063@thomasm-u1.cisco.com> <3A142DEE.AA44B45F@txc.com> Date: Fri, 17 Nov 2000 08:35:59 -0800 To: Alex Conta From: Steve Deering Subject: Re: Usage of IPv6 flow label Cc: Michael Thomas , Francis Dupont , Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:56 PM -0500 11/16/00, Alex Conta wrote: >If flow IDs are used for fast forwarding, without the ability to rewrite >them, it seems to me that a router will not be able to aggregate flows. Alex, That is incorrect. A router can aggregate flows by encapsulation (similar to, but more powerful than, label stacks), and therefore not need to rewrite flow IDs. A system that rewrites flow IDs to do aggregation is unable to efficiently *de*aggregate at the other end of the aggregating path. 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 Fri Nov 17 08:55:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHGsYh13404 for ipng-dist; Fri, 17 Nov 2000 08:54:34 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHGsPj13397 for ; Fri, 17 Nov 2000 08:54:25 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA11748; Fri, 17 Nov 2000 08:54:25 -0800 (PST) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22831; Fri, 17 Nov 2000 08:54:22 -0800 (PST) Received: from godel.logique.jussieu.fr (root@godel.logique.jussieu.fr [134.157.19.1]) by shiva.jussieu.fr (8.10.0/jtpda-5.3.3) with ESMTP id eAHGsBt97040 ; Fri, 17 Nov 2000 17:54:12 +0100 (CET) Received: from bernays.logique.jussieu.fr (bernays.logique.jussieu.fr [134.157.19.71]) by godel.logique.jussieu.fr (8.9.3/jtpda-5.3.1) with ESMTP id RAA02256 ; Fri, 17 Nov 2000 17:53:53 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 17 Nov 2000 17:59:33 +0100 (CET) From: Yves Legrandgerard To: Erik Nordmark Subject: Re: IPV6_USEMTU socket option Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com, Francis Dupont Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 17-Nov-00 Erik Nordmark wrote: > >> [ylg]=> Yes, that's exactly wee need, a socket option like : >> int on = 1; >> >> setsockopt(fd, IPPROTO_IPV6, IPV6_DONTFRAG, &on, sizeof(&on)); >> to disable fragmentation for UDP/Raw sockets (and of course on = 0 to >> (re)enable fragmentation which would be the default). > > I'll add it to 2292bis. > [ylg]=> Nice, thanks. > >> As we said in a previous message, F. Dupont and me, a useful option would be >> a new option to getsockopt() to get the outgoing MTU. For example, it helps >> tracemtu to discover the right mtu to start (otherwise, we have to set >> IPV6_DONTFRAG option, and try successive MTU (choosen in a list of possible >> MTU, ordered decreasingly) until we don't get EMSGSIZE error (an other pb : >> does exist such a list, i.e. the (right) list of all possible MTUs?). > > Presumably such an option needs to take a sockaddr_in6 as an argument > to specify the destination. We can reuse the proposed ip6_mtuinfo structure > for this. > > Do you care to know whether the kernel has path mtu information or > is just returning the mtu of the outgoing interface? > [ylg]=> No, I don't care. I'm only interessed in outgoing interface mtu. I think that your proposal to reuse the proposed ip6_mtuinfo structure is a good idea. Regards, ---------------------------------- Yves Legrandgérard E-Mail: ylg@logique.jussieu.fr Date: 17-Nov-00 Time: 17:49:40 ---------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 17 09:04:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHH36G13489 for ipng-dist; Fri, 17 Nov 2000 09:03:06 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHH2uj13482 for ; Fri, 17 Nov 2000 09:02:57 -0800 (PST) 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,v1.7) with ESMTP id JAA27137; Fri, 17 Nov 2000 09:02:56 -0800 (PST) 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 JAA04413; Fri, 17 Nov 2000 09:02:54 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id BAA10882; Sat, 18 Nov 2000 01:49:00 +0900 (JST) Date: Sat, 18 Nov 2000 02:02:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: Yves Legrandgerard , ipng@sunroof.eng.sun.com, Francis Dupont Subject: Re: IPV6_USEMTU socket option In-Reply-To: In your message of "Thu, 16 Nov 2000 14:46:36 -0800 (PST)" References: User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 16 Nov 2000 14:46:36 -0800 (PST), >>>>> Erik Nordmark said: >> > Applications can dynamically grab the path MTU by the IPV6_RECVPATHMTU >> > socket option (upon receiving an ICMPv6 packet toobig error). >> > >> >> Is that mean, when IPV6_RECVPATHMTU option is setted (UDP/raw socket), that >> fragmentation is disabled ? > No, I don't think so. > IPV6_RECVPATHMTU is so that e.g. UDP applications that do packetization > can determine when the path MTU changes and adjust the size of the > packets they are sending. My understanding is the same as yours. > Should we just define the semantic equivalent of setting IP_DF on > a raw socket with IP_HDRINCL set for IPv6? (IPV6_DONTFRAG?) I think this type of option can be useful, but I still think the IPV6_USEMTU option (which allows an application to specify the path MTU for an outgoing packet) is useful as well. And, if we take this approach, prohibiting fragment can be implemented as a special case of the option (i.e, setting a very large value as the MTU). What do you think of this? 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 Nov 17 09:05:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHH4vB13555 for ipng-dist; Fri, 17 Nov 2000 09:04:57 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHH4kj13548 for ; Fri, 17 Nov 2000 09:04:46 -0800 (PST) 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,v1.7) with ESMTP id JAA14104 for ; Fri, 17 Nov 2000 09:04:46 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05474 for ; Fri, 17 Nov 2000 09:04:40 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAHH3sb47306; Fri, 17 Nov 2000 18:03:59 +0100 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 SAA21679; Fri, 17 Nov 2000 18:03:53 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA98599; Fri, 17 Nov 2000 18:06:14 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011171706.SAA98599@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Dirk Ooms cc: Brian Zill , ipng@sunroof.eng.sun.com Subject: Re: Mutable fields and the Hop-by-Hop and Destination Options headers In-reply-to: Your message of Fri, 17 Nov 2000 14:58:10 +0100. <3A153972.3439F0B7@alcatel.be> Date: Fri, 17 Nov 2000 18:06:14 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I have the impression that a lot of the complexity in these chained extension headers is caused by the way Source Routing is specified. If Source Routing would be a hop-by-hop extension and the IPv6 destination was always the final destination the header mess wouldn't be that big => hop-by-hop means to be processed by each router on the path... What you propose in fact is to kill the routing header facility (as it was for IPv4 in the real world) but I am sorry but the routing header is useful, for instance for mobility (routing optimization needs it) and policy routing. (the disadvantage being that Loose Source Routed packets need additional procesing in non-fixed hops, => IPv6 routing header type 0 (other types are not used) is *loose* source routing. but who is using Source Routing anyhow?). => see before. 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 Nov 17 09:09:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHH8EL13591 for ipng-dist; Fri, 17 Nov 2000 09:08:14 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHH85j13584 for ; Fri, 17 Nov 2000 09:08:05 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA02337; Fri, 17 Nov 2000 09:08:05 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29869; Fri, 17 Nov 2000 09:08:04 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id BAA10895; Sat, 18 Nov 2000 01:54:08 +0900 (JST) Date: Sat, 18 Nov 2000 02:07:27 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Yves Legrandgerard Cc: Erik Nordmark , ipng@sunroof.eng.sun.com, Francis Dupont Subject: Re: IPV6_USEMTU socket option In-Reply-To: In your message of "Fri, 17 Nov 2000 17:59:33 +0100 (CET)" References: User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 17 Nov 2000 17:59:33 +0100 (CET), >>>>> Yves Legrandgerard said: >>> As we said in a previous message, F. Dupont and me, a useful option would be >>> a new option to getsockopt() to get the outgoing MTU. For example, it helps >>> tracemtu to discover the right mtu to start (otherwise, we have to set >>> IPV6_DONTFRAG option, and try successive MTU (choosen in a list of possible >>> MTU, ordered decreasingly) until we don't get EMSGSIZE error (an other pb : >>> does exist such a list, i.e. the (right) list of all possible MTUs?). >> >> Presumably such an option needs to take a sockaddr_in6 as an argument >> to specify the destination. We can reuse the proposed ip6_mtuinfo structure >> for this. >> >> Do you care to know whether the kernel has path mtu information or >> is just returning the mtu of the outgoing interface? >> > [ylg]=> No, I don't care. I'm only interessed in outgoing interface mtu. I > think that your proposal to reuse the proposed ip6_mtuinfo structure is a good > idea. Then why not just look up the routing table and get the MTU of the outgoing interface? I admit that a single operation to do that would be convenient, but I personally don't think we have to add a separate socket option for this particular purpose. 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 Nov 17 10:03:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHI1la13780 for ipng-dist; Fri, 17 Nov 2000 10:01:47 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHI1cj13773 for ; Fri, 17 Nov 2000 10:01:39 -0800 (PST) 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,v1.7) with ESMTP id KAA29409; Fri, 17 Nov 2000 10:01:37 -0800 (PST) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10618; Fri, 17 Nov 2000 10:01:36 -0800 (PST) Received: from godel.logique.jussieu.fr (root@godel.logique.jussieu.fr [134.157.19.1]) by shiva.jussieu.fr (8.10.0/jtpda-5.3.3) with ESMTP id eAHI1Zt33871 ; Fri, 17 Nov 2000 19:01:35 +0100 (CET) Received: from bernays.logique.jussieu.fr (bernays.logique.jussieu.fr [134.157.19.71]) by godel.logique.jussieu.fr (8.9.3/jtpda-5.3.1) with ESMTP id TAA02958 ; Fri, 17 Nov 2000 19:01:16 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 17 Nov 2000 19:06:56 +0100 (CET) From: Yves Legrandgerard To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Subject: Re: IPV6_USEMTU socket option Cc: Francis Dupont , ipng@sunroof.eng.sun.com, Erik Nordmark Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 17-Nov-00 JINMEI Tatuya / $B?@L@C#:H(B wrote: >>> Do you care to know whether the kernel has path mtu information or >>> is just returning the mtu of the outgoing interface? >>> > >> [ylg]=> No, I don't care. I'm only interessed in outgoing interface mtu. I >> think that your proposal to reuse the proposed ip6_mtuinfo structure is a >> good >> idea. > > Then why not just look up the routing table and get the MTU of the > outgoing interface? I admit that a single operation to do that would > be convenient, but I personally don't think we have to add a separate > socket option for this particular purpose. > You're right but, as you mentionned, it's not a single operation. I still think that it would be useful to get the outgoing interface MTU with a single operation not only for the particular case of tracemtu (I admit that create a new option just for a particular case is a bad idea) because UDP/Raw applications eventually need to know outgoing interface MTU when they have disabled fragmentation. Regards, ---------------------------------- Yves Legrandgérard E-Mail: ylg@logique.jussieu.fr Date: 17-Nov-00 Time: 18:50:12 ---------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 17 10:26:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHIORw13889 for ipng-dist; Fri, 17 Nov 2000 10:24:27 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHIOIj13882 for ; Fri, 17 Nov 2000 10:24:18 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA20261; Fri, 17 Nov 2000 10:24:17 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21975; Fri, 17 Nov 2000 10:24:14 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAHINUb39993; Fri, 17 Nov 2000 19:23:31 +0100 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 TAA24470; Fri, 17 Nov 2000 19:23:29 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA99057; Fri, 17 Nov 2000 19:25:51 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011171825.TAA99057@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Yves Legrandgerard cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: IPV6_USEMTU socket option In-reply-to: Your message of Fri, 17 Nov 2000 19:06:56 +0100. Date: Fri, 17 Nov 2000 19:25:51 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Then why not just look up the routing table and get the MTU of the > outgoing interface? I admit that a single operation to do that would > be convenient, but I personally don't think we have to add a separate > socket option for this particular purpose. => I agree, it should be a library function (still in advanced API but not as a getsockopt()). Francis.Dupont@enst-bretagne.fr PS: on some systems getsockopt() is not supposed to have an argument (ie. optval points only to a buffer for the result) then be careful. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 17 10:28:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHIRiO13907 for ipng-dist; Fri, 17 Nov 2000 10:27:44 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHIRWj13900 for ; Fri, 17 Nov 2000 10:27:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA18470 for ; Fri, 17 Nov 2000 10:27:32 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10207 for ; Fri, 17 Nov 2000 10:27:31 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id DAA22918; Sat, 18 Nov 2000 03:27:02 +0900 (JST) To: Francis Dupont cc: ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Fri, 17 Nov 2000 17:23:23 +0100. <200011171623.RAA98049@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: [advanced API] how to get the destination address for IPV6_RECVPATHMTU From: itojun@iijlab.net Date: Sat, 18 Nov 2000 03:27:02 +0900 Message-ID: <22916.974485622@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >=> if in6_addr is defined as four 32 bit integers then the compiler >won't add padding. If it is defined as a pair of 64 bit integers the >compiler may add 32 bits for padding if the MTU field is before and >the architecture needs 64 bit alignment for 64 bit quantities. well, i'd like to know how far do we need to go. think of binary compatibility with 32/64/128/256bit CPUs, i believe we cannot do much here anyways. 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 Nov 17 10:33:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHIVoY13926 for ipng-dist; Fri, 17 Nov 2000 10:31:50 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHIVfj13919 for ; Fri, 17 Nov 2000 10:31:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA22494 for ; Fri, 17 Nov 2000 10:31:41 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08595 for ; Fri, 17 Nov 2000 11:31:38 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAHIUsb40135; Fri, 17 Nov 2000 19:30:54 +0100 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 TAA24733; Fri, 17 Nov 2000 19:30:53 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA99109; Fri, 17 Nov 2000 19:33:15 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011171833.TAA99109@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU In-reply-to: Your message of Sat, 18 Nov 2000 03:27:02 +0900. <22916.974485622@coconut.itojun.org> Date: Fri, 17 Nov 2000 19:33:15 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >=> if in6_addr is defined as four 32 bit integers then the compiler >won't add padding. If it is defined as a pair of 64 bit integers the >compiler may add 32 bits for padding if the MTU field is before and >the architecture needs 64 bit alignment for 64 bit quantities. well, i'd like to know how far do we need to go. think of binary compatibility with 32/64/128/256bit CPUs, i believe we cannot do much here anyways. => no, my concern is binary compatibility for the same 32 bit CPU with two different definitions of struct in6_addr. 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 Nov 17 10:35:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHIY2j13944 for ipng-dist; Fri, 17 Nov 2000 10:34:02 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHIXoj13937 for ; Fri, 17 Nov 2000 10:33:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA23251 for ; Fri, 17 Nov 2000 10:33:50 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13244 for ; Fri, 17 Nov 2000 10:33:48 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id DAA23037; Sat, 18 Nov 2000 03:33:39 +0900 (JST) To: Francis Dupont cc: ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Fri, 17 Nov 2000 19:33:15 +0100. <200011171833.TAA99109@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: [advanced API] how to get the destination address for IPV6_RECVPATHMTU From: itojun@iijlab.net Date: Sat, 18 Nov 2000 03:33:39 +0900 Message-ID: <23035.974486019@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > well, i'd like to know how far do we need to go. think of binary > compatibility with 32/64/128/256bit CPUs, i believe we cannot do > much here anyways. >=> no, my concern is binary compatibility for the same 32 bit CPU with >two different definitions of struct in6_addr. maybe i wrongly assumed that you are talking about sparc64. i still don't understand how generic your problem is... 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 Nov 17 11:28:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHJRGT14001 for ipng-dist; Fri, 17 Nov 2000 11:27:16 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHJR4j13994 for ; Fri, 17 Nov 2000 11:27:05 -0800 (PST) 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,v1.7) with ESMTP id LAA24160; Fri, 17 Nov 2000 11:26:59 -0800 (PST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18403; Fri, 17 Nov 2000 12:26:48 -0700 (MST) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id UAA00956; Fri, 17 Nov 2000 20:25:44 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id UAA04862; Fri, 17 Nov 2000 20:26:17 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Nov 2000 20:26:16 +0100 Message-ID: <158669A6D0F5D3119B940060086D94F55006CC@ULML202E> From: Metzler Jochen To: "'Ipng (E-Mail) '" , "'internet-drafts@ietf.org'" Cc: "'deering@cisco.com'" , "'Erik Nordmark'" , "'Bob Hinden'" , "'Thomas Narten'" Subject: New I-D: An end-to-end usage of the IPv6 flow label Date: Fri, 17 Nov 2000 20:26:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id eAHJR6j13995 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear all, please find my draft on an e-t-e usage of the IPv6 flow label field under: http://home.bn-ulm.de/~ulzoppo/draft-metzler-ipv6-flowlabel-00.txt Draft Name: An end-to-end usage of the IPv6 flow label File Name: I would like to discuss this issue with you on the distribution list as well as at the Meeting in San Diego. Best regards Jochen Metzler ------------------------------------------------------------------ Jochen Metzler Siemens AG Lise-Meitner-Straße 5, 89081 Ulm Phone: +49.(0)731.9533.390 Mobile Networks Fax : +49.(0)731.9533.336 ICM MN MR UR SE 2 mailto: jochen.metzler@icn.siemens.de -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 17 11:29:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHJS3914010 for ipng-dist; Fri, 17 Nov 2000 11:28:03 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHJRpj14003 for ; Fri, 17 Nov 2000 11:27:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA14242 for ; Fri, 17 Nov 2000 11:27:50 -0800 (PST) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09160 for ; Fri, 17 Nov 2000 11:27:48 -0800 (PST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 13wr3n-0007Zf-00; Fri, 17 Nov 2000 14:20:31 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA15659; Fri, 17 Nov 00 14:15:44 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id OAA19576; Fri, 17 Nov 2000 14:20:25 -0500 Message-Id: <3A1584F1.79185912@txc.com> Date: Fri, 17 Nov 2000 14:20:17 -0500 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Steve Deering Cc: Michael Thomas , Francis Dupont , Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <20001115190919.321B17EF9@starfruit.itojun.org> <200011160958.KAA90047@givry.rennes.enst-bretagne.fr> <14867.59850.899996.178063@thomasm-u1.cisco.com> <3A142DEE.AA44B45F@txc.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8B527E3D5BA19BEE2D31C2A0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms8B527E3D5BA19BEE2D31C2A0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve, > Steve Deering wrote: > > Alex, > > That is incorrect. You missed a component my argument. We are in fact talking about apples and oranges. Tunneling flows means creating COMPLETELY NEW flows, with completely different characteristics than the original flows: source, destination, etc..., with an important impact on the classification criteria that can be applied. > A router can aggregate flows by encapsulation > (similar to, but more powerful than, label stacks), and therefore > not need to rewrite flow IDs. > "More powerful" is relative: for routers that implement both, and for forwarding within the routing domains were both are supported, one could argue that it does not apply. Tunneling is more expensive and less efficient -- packet size issues, and encapsulation effort in terms of header pre pending. Furthermore, tunneling adds cost in terms of header processing, that is, forwarding is performed twice, once on the original packet, and second on the tunnel packet. Additionally, the costs of building such functions add to the costs of a fast forwarding engine. > A system that rewrites flow IDs to do aggregation is unable to > efficiently *de*aggregate at the other end of the aggregating path. > > Steve I disagree. De-aggregation of forwarded traffic based on the 'flow-id' of tunnel packets is not necessarily more efficient than de-aggregation of forwarded traffic based on "destination address" of original (non-tunnel) packets. Here is why: 1. - A tunnel packet "flow-id" based de-aggregation, requires - a forwarding of the tunnel packet, - decapsulation, and - a forwarding of the original packet. 2. - An original packet "destination address" based de-aggregation requires - a forwarding of the original packet This has implications on the costs of building a fast engine. Alex --------------ms8B527E3D5BA19BEE2D31C2A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKBgYJKoZIhvcNAQcCoIIJ9zCCCfMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICETCCAg0CAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDExMTcxOTIwMTlaMCMGCSqGSIb3DQEJBDEWBBQud1SruPhB6gJDPxil GhykaQaX7DAnBgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAfcRjP5fZ5fdlX+8sE0Bj18Wac2wjH5K4UAXB7gxaqCmWU74SOflxdKF3 ijcMvTnBiQt5hpivXFE1enbcIiMn5opXRgH9O/gbd0Z+RD1+XJOWGBqjrCdIkONnkUqJwKwV I/afTGFTs1EozFVrvnc54UK0cV58GqtfjG0DiH4aTvk= --------------ms8B527E3D5BA19BEE2D31C2A0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 17 13:21:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHLHx914162 for ipng-dist; Fri, 17 Nov 2000 13:17:59 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHLHfj14155 for ; Fri, 17 Nov 2000 13:17:47 -0800 (PST) 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,v1.7) with ESMTP id NAA14277 for ; Fri, 17 Nov 2000 13:17:38 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA28850 for ; Fri, 17 Nov 2000 14:17:36 -0700 (MST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA17091; Fri, 17 Nov 2000 13:08:51 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <3A1584F1.79185912@txc.com> References: <20001115190919.321B17EF9@starfruit.itojun.org> <200011160958.KAA90047@givry.rennes.enst-bretagne.fr> <14867.59850.899996.178063@thomasm-u1.cisco.com> <3A142DEE.AA44B45F@txc.com> <3A1584F1.79185912@txc.com> Date: Fri, 17 Nov 2000 13:08:49 -0800 To: Alex Conta From: Steve Deering Subject: Re: Usage of IPv6 flow label Cc: Michael Thomas , Francis Dupont , Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 2:20 PM -0500 11/17/00, Alex Conta wrote: >You missed a component my argument. We are in fact talking about apples >and oranges. I wasn't responding to your argument. (Debating the the pros and cons of MPLS, though one of my favorite topics, is out-of-scope for this mailing list). I was responding to your statement: >If flow IDs are used for fast forwarding, without the ability to rewrite >them, it seems to me that a router will not be able to aggregate flows. and pointing out that you were mistaken. >Tunneling flows means creating COMPLETELY NEW flows, with completely >different characteristics than the original flows: source, destination, >etc..., with an important impact on the classification criteria that can >be applied. Of course. An aggregate of flows usually has different properties than its component flows (like bandwidth, for one), so it makes sense to think of them as separate flows (big pipes with little pipes running through them, like the classic diagrams of ATM virtual circuits inside of virtual paths). It's a feature to be able to classify them separately. >"More powerful" is relative: for routers that implement both, and for >forwarding within the routing domains were both are supported, one could >argue that it does not apply. I was using "more powerful" in the sense of being a more general mechanism than can accomplish more than just what MPLS does. Sure, if all you care about is what you can do with MPLS, that extra "power" will not interest you, but it might be of interest to others. >Tunneling is more expensive and less efficient -- packet size issues, >and encapsulation effort in >terms of header pre pending. Furthermore, tunneling adds cost in terms >of header processing, that is, forwarding is performed twice, once on >the original packet, and second on the tunnel packet. Yes there are lots of little performance trade-offs and different people weigh their importance differently, and there are more efficient ways of implementing tunnel entry/exit than you imply. None of that has anything to do with your speculation that routers simply won't be able aggregate flows if they can't rewrite the flow ID. >Additionally, the costs of building such functions add to the costs of a >fast forwarding engine. I believe IP-in-IP tunneling has become a basic tool that routers need to support efficiently anyway, so I'd turn it around and ask if it's worth the additional (and nontrivial) costs of including all the MPLS machinery as well. But I won't, because as I said, it's out-of-scope for this list. 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 Fri Nov 17 14:47:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHMj4914331 for ipng-dist; Fri, 17 Nov 2000 14:45:04 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHMitj14324 for ; Fri, 17 Nov 2000 14:44:55 -0800 (PST) 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,v1.7) with ESMTP id OAA09104 for ; Fri, 17 Nov 2000 14:44:56 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA25165 for ; Fri, 17 Nov 2000 15:44:53 -0700 (MST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 17 Nov 2000 14:44:04 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Fri, 17 Nov 2000 14:44:52 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9BC9@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "'Robert Elz'" Cc: ipng@sunroof.eng.sun.com Subject: RE: default router selection based on network topology Date: Fri, 17 Nov 2000 14:44:36 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm not sure though that this belongs in RA - it is the kind of thing > which I suspect I'd prefer to have a user level application dealing > with, and so having it as a UDP protocol would have a lot of > advantages, > even if it currently does gain some advantages by sharing > quite a bit with > what RAs already offer at the more primitive level - and that most > likely a host would want to use only one method - this new > protocol, or > RAs as its method for finding routers. This is kind of a big > uncertainty in my mind. Don't some implementations process Router Advertisements in a user-level process, radvd? I think putting the information in Router Advertisements does not preclude user-level processing. > I'd probably make the routing info messages variable length though, > padded to whatever alignment needs to be enforced, but not necessarily > to the maximum address length (ie: sending a 128 bit address > to say 0::0/0 > seems a bit overboard). I wouldn't want to restrict the > prefixes that > can be advertised to max 64 bits though, that would be an overly > restrictive optimisation for future flexibility - hosts > should treat add > addresses as simply 128 bits masked (other than for autoconf purposes, > when that is enabled). Yes, I alluded to this idea (Dave Thaler also suggested it) in the draft. Here's a possibility: allow the Length field in the option to be 1, 2, or 3. If the Prefix Length is 0, then the Length field can be 1 and the option is only 8 bytes. If the Prefix field is <= 64, then the Length field can be 2 and the option is only 16 bytes. If the Prefix field is <= 128, then the Length field can be 3 and the option is 24 bytes. > That is, I think there needs to be a "blackhole" (or unreachable) > preference as well as "bad" "average" "good" (or low medium high). > > Without that, there's no way to subtract out a piece from a large > block, and you're left having to instead to form the address space > you want to reference from the union of a lot of smaller blocks, > which is error prone (though I guess it could be done in software > with a configuration language that includes a blackhole) and > generates much larger RAs (or whatever they turn out to be). > > For example, in your section 5.2, if router Y simply identifies itself > as a default router, then it is claiming that it can reach the > isolated corporate net that is really only reachable via X (which > it is assumed isn't connected to Y, or known to it). That's not > good. While X is alive, things work, as its more specific route > will be used instead of the default from Y. But when X is down, > there's nothing to stop traffic heading at Y. > > This may sound like not much of a problem, as if the corporate net > can't be reached at all (its only gateway being down) then > not reaching > it via Y might not seem like much of a problem - but it does mean that > what might be potentially sensitive corporate information, that wasn't > ever intended to go anywhere near Y (and who knows how much further > before the default routes end and the lack of a specific route is > detected) which is being dumped that direction (this could be > as simple > as SNMP traps from C - so there is no need to postulate the > establishment > of a TCP connection before any real data is sent). You have a point, but I think security is a weak argument. I'd hate to rely on routing for the mechanism that prevents my sensitive corporate information from leaving my network. > So, I would suggest allocating that final code as "unreachable", > with the interpretation by the host that after running the algorithm > the route selected is unreachable, then packets should simply be > discarded (with an appropriate error to the application). This would complicate the conceptual sending algorithm for host C somewhat. If I understand your intent, then your formulation isn't correct. For example with routes: ::/0 -> router X (Medium) 3ffe::/16 -> router X (Unreachable) ::/0 -> router Y (Medium) you'd want destination 3ffe::1 to be sent to router Y (only), not result in the packets being discarded because it matched the 3ffe::/16 route. If router Y is not reachable, then you do not want the packets sent to router X. Here's an attempt at modifying the conceptual sending algorithm to include Unreachable routes - is this what you meant? When host C does next-hop determination and consults its Routing Table for an off-link destination, it looks for routes in the Routing Table that match the destination (meaning the leading Prefix Length bits of the destination address and the Prefix are the same). If there is more than one such matching route, then the following rules are used to compare matching routes and select the best one: a) If one route has an unreachable next-hop router and the other route has a reachable next-hop router, prefer the route to the reachable next-hop router. b) If one route has a Preference value of -2 (Unreachable) and the other route as a larger Preferenc value (not Unreachable) and the two routes have different next-hop routers, prefer the route with the larger Preference value. c) If the routes have different Prefix Lengths, prefer the route with the larger Prefix Length. d) If the routes have different Preferences, prefer the route with the larger Preference value. If the best matching route has an unreachable next-hop router or a Preference value of -2 (Unreachable), then host C SHOULD round-robin among all routers matching the destination regardless of preference value or prefix length, except not including routers whose longest prefix route matching the destination has a Preference value of -2 (Unreachable). Thanks, 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 Fri Nov 17 15:02:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHN04D14377 for ipng-dist; Fri, 17 Nov 2000 15:00:04 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHMxsj14370 for ; Fri, 17 Nov 2000 14:59:54 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA06149 for ; Fri, 17 Nov 2000 14:59:54 -0800 (PST) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12806 for ; Fri, 17 Nov 2000 14:59:54 -0800 (PST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 13wuNF-0006YI-00; Fri, 17 Nov 2000 17:52:49 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA17495; Fri, 17 Nov 00 17:48:06 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id RAA25256; Fri, 17 Nov 2000 17:52:47 -0500 Message-Id: <3A15B6B2.D29AAED@txc.com> Date: Fri, 17 Nov 2000 17:52:34 -0500 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Steve Deering Cc: Michael Thomas , Francis Dupont , Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <20001115190919.321B17EF9@starfruit.itojun.org> <200011160958.KAA90047@givry.rennes.enst-bretagne.fr> <14867.59850.899996.178063@thomasm-u1.cisco.com> <3A142DEE.AA44B45F@txc.com> <3A1584F1.79185912@txc.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msBDF0D258F3DC0C1070017BB3" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msBDF0D258F3DC0C1070017BB3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Since the IPv6 flow label work started, two major efforts in IETF made significant progress on related topics: Diffserv and MPLS. As an extension of the Diffserv aggregation model, the flow label SHOULD be re-writable. If you think about extending your argument to Diffserv, then Diffserv aggregated flows should be always tunneled. Similarly to Diffserv, allowing re-write does not always mean that the flow label is going to be re-written, so the current specification, or usage would be in fact a subset. The argument boils down to **forcing "read-only" onto flow labels does not pay**. On the contrary. I think that the MPLS work is a significant progress on the concept, and mechanisms of labeling flows, and as you know [(-:], I think IPv6 should borrow from it, rather than going against, or going on a path that was started before the MPLS effort, but so far didn't go far enough to be sufficiently significant. Some of the weight, or basis, or the hidden reason, of your tunneling argument comes, I think, from the fact that as of now, a flow label defines uniquely a flow, only when associated with the source address. Because of the need of the 20 + 128 bits for flow identification, just re-writing the flow label would not do it: you need a new source address as well for the flow identification. But this (148 bits for uniquely identifying a flow), as well as re-writing, local, or global significance, unicity, etc... are all things that should be on the table for discussion. Aggregation implies that some elements of the flows being subject to aggregation are similar: QoS requirements, destination, etc... Your are right, tunneling is indeed the most general, and most comprehensive mechanism. But tunneling means changing all parameters. Is the cost always justified, or even when changing one parameter would be sufficient? In my opinion, the cost is not justified, in particular if a "flow label' of 20 bits, can define alone, uniquely, a traffic flow to the forwarding process. Rewriting only the flow label for aggregation, while leaving the rest of the packet's header's fields intact allows, like in DIffserv, applying criteria of classification to those fields, and the rest of the packet, similar to those applied to the original packet, that is, do not require changing, or additional classifications rules. Please note, and do not ignore the fact that, storing, deleting, updating and disseminating classification rules is in fact at least if not more expensive than similar operations done with forwarding table information. Alex --------------msBDF0D258F3DC0C1070017BB3 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKBgYJKoZIhvcNAQcCoIIJ9zCCCfMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICETCCAg0CAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDExMTcyMjUyMzdaMCMGCSqGSIb3DQEJBDEWBBQa0imhEdE3qArXyvQV CDpuxleuizAnBgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGASBccns7FlfGIscf+5x0K/TNvwXMQK4vrfhGcWDJjiaPBtT6PiWLvzjBR w7eldZeqMHekIzVkwHQ9wTg+aeQUI1bnIZwfiLOreb95RkpR+itP9kajZmI11xPSoXFwXDVu vUeq4g8YZiWtZEfCsjTfH2TvyFmRDMqSvgakCKHjj5E= --------------msBDF0D258F3DC0C1070017BB3-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 17 15:03:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAHN1sN14386 for ipng-dist; Fri, 17 Nov 2000 15:01:54 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAHN1hj14379 for ; Fri, 17 Nov 2000 15:01:43 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA02859 for ; Fri, 17 Nov 2000 15:01:44 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA23974 for ; Fri, 17 Nov 2000 15:01:42 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 17 Nov 2000 15:00:40 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 17 Nov 2000 15:01:21 -0800 (Pacific Standard Time) Received: from DF-MAX.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 17 Nov 2000 15:01:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4591.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: default router selection based on network topology Date: Fri, 17 Nov 2000 15:01:20 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657401D42D7D@DF-BOWWOW.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: default router selection based on network topology Thread-Index: AcBQ4v/OotnXld5hQe+IHOjOzaw2AAABvEPA From: "Dave Thaler" To: "Robert Elz" Cc: X-OriginalArrivalTime: 17 Nov 2000 23:01:21.0023 (UTC) FILETIME=[4CF778F0:01C050EA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id eAHN1ij14380 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > That is, I think there needs to be a "blackhole" (or unreachable) > preference as well as "bad" "average" "good" (or low medium high). [...] > So, I would suggest allocating that final code as "unreachable", > with the interpretation by the host that after running the algorithm > the route selected is unreachable, then packets should simply be > discarded (with an appropriate error to the application). I tend to agree with this, and we indeed talked about this possibility a while back while Rich and Balash were working on what should go in the draft. -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 Fri Nov 17 16:23:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAI0LVo14492 for ipng-dist; Fri, 17 Nov 2000 16:21:31 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAI0LJj14485 for ; Fri, 17 Nov 2000 16:21:20 -0800 (PST) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id eAI0LJB571664; Fri, 17 Nov 2000 16:21:19 -0800 (PST) Date: Fri, 17 Nov 2000 16:21:19 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPV6_USEMTU socket option To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , Yves Legrandgerard , ipng@sunroof.eng.sun.com, Francis Dupont 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 think this type of option can be useful, but I still think the > IPV6_USEMTU option (which allows an application to specify the path > MTU for an outgoing packet) is useful as well. And, if we take this > approach, prohibiting fragment can be implemented as a special case of > the option (i.e, setting a very large value as the MTU). What do you > think of this? If we want an IPV6_USEMTU option I think that needs to be separate from prohibiting fragmentation, since I think the overloading you propose would be confusing. If the path MTU is 2000 bytes and the interface MTU is 8000 bytes I would expect that an IPV6_USEMTU value between 2000 and 8000 would transmit an unfragmented packet. I assume your proposal is that when the IPv6_USEMTU value is set to a number larger than 8000 this would cause the packet to be dropped (and an IPV6_PATHMTU sent up as ancillary data if the socket had IPV6_RECVPATHMTU enabled). Thus setting IPV6_USEMTU to 2^^32-1 would be the same as disabling fragmentation. But when using IPV6_USEMTU as you propose would the MTU be for all destination addresses on the socket? Or would IPV6_USEMTU carry an address in addition to an mtu? Do you have an example of an application which might need such a feature? 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 Nov 17 16:29:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAI0SBB14514 for ipng-dist; Fri, 17 Nov 2000 16:28:11 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAI0S0j14507 for ; Fri, 17 Nov 2000 16:28:00 -0800 (PST) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id eAI0S0B572990; Fri, 17 Nov 2000 16:28:00 -0800 (PST) Date: Fri, 17 Nov 2000 16:28:00 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPV6_USEMTU socket option To: Yves Legrandgerard Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Francis Dupont , ipng@sunroof.eng.sun.com, Erik Nordmark 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 This is what I've edited together so far. Note that the IPV6_PATHMTU option is used both as ancillary data (when IPV6_RECVPATHMTU is enabled) and with getsockopt to retrieve the current path MTU value for a destination. Comments? Erik 11.1. Sending with the Minimum MTU Some applications might not want to incur the overhead of path MTU discovery, especially if the applications only send a single datagram to a destination. A potential example is a DNS server. This specification defines a mechanism to avoid path MTU discovery by sending at the minimum IPv6 MTU [RFC-2460]. If the packet is larger than the minimum MTU and this feature has been enabled the IP layer will fragment to the minimum MTU. This can be enabled using the IPV6_USE_MIN_MTU socket option. int on = 1; setsockopt(fd, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &on, sizeof(on)); By default, this socket option is disabled. Setting the value to 0 also disables the option. This option can also be sent as ancillary data. 11.2. Sending without fragmentation In order to provide for easy porting of existing UDP and raw socket applications IPv6 implementations will, when originating packets, automatically insert a fragment header in the packet if the packet is too big for the path MTU. Some applications might not want this behavior. An example is traceroute which might want to discover the actual path MTU. This specification defines a mechanism to turn off the automatic inserting of a fragment header for UDP and raw sockets. This can be enabled using the IPV6_DONTFRAG socket option. int on = 1; setsockopt(fd, IPPROTO_IPV6, IPV6_DONTFRAG, &on, sizeof(&on)); By default, this socket option is disabled. Setting the value to 0 also disables the option i.e. reverts to the default behavior of automatic inserting. This option can also be sent as ancillary data. 11.3. Path MTU Discovery and UDP UDP and raw socket applications need to be able to determine the "maximum send transport-message size" (Section 5.1 of [RFC-1981]) to a given destination so that those applications can participate in path MTU discovery. This lets those applications send smaller datagrams to the destination, avoiding fragmentation. This is accomplished using a new ancillary data item (IPV6_PATHMTU) which is delivered to recvmsg() without any actual data. The application enable the receipt of IPV6_PATHMTU ancillary data items by enabing IPV6_RECVPATHMTU. int on = 1; setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPATHMTU, &on, sizeof(on)); By default, this socket option is disabled. Setting the value to 0 also disables the option. When the application is sending packets too big for the path MTU recvmsg will return zero (indicating no data) but there will be a cmsghdr with cmsg_type set to IPV6_PATHMTU, and cmsg_len will indicate that cmsg_data is 4 bytes long. CMSG_DATA will point to a struct ip6_ carrying the path MTU to use together with the IPv6 destination address. struct ip6_mtuinfo { struct sockaddr_in6 ip6m_addr; /* dst IPv6 address including scope */ unsigned int ip6m_mtu; /* path MTU in host byte order */ }; XXX What about more complex paths e.g. when using a routing header? 11.4. Determining the current path MTU Some applications might need to determine the current path MTU e.g. applications using IPV6_RECVPATHMTU might want to pick a good starting value. This specification defines a socket option to retrieve the current path MTU value for a given destination address. If the IP layer does not have a cached path MTU value it will return the interface MTU for the interface that will be used when sending to the specified IPv6 address. This information is retrived using IPV6_PATHMTU. struct ip6_mtuinfo mtuinfo; mtuinfo.ip6m_addr = addr; /* address */ getsockopt(fd, IPPROTO_IPV6, IPV6_PATHMTU, &mtuinfo, sizeof(&mtuinfo)); -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 17 16:30:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAI0Thi14567 for ipng-dist; Fri, 17 Nov 2000 16:29:43 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAI0TUj14560 for ; Fri, 17 Nov 2000 16:29:30 -0800 (PST) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id eAI0TUB573213; Fri, 17 Nov 2000 16:29:30 -0800 (PST) Date: Fri, 17 Nov 2000 16:29:30 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPV6_USEMTU socket option To: Francis Dupont Cc: Yves Legrandgerard , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com, Erik Nordmark In-Reply-To: "Your message with ID" <200011171825.TAA99057@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => I agree, it should be a library function (still in advanced API > but not as a getsockopt()). > > Francis.Dupont@enst-bretagne.fr > > PS: on some systems getsockopt() is not supposed to have an argument > (ie. optval points only to a buffer for the result) then be careful. Good point. getsockopt only does a copyout from the kernel. Do you have a proposal for a name of a function which retrieves the path MTU for a destination/path? 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 Nov 17 16:44:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAI0hO014590 for ipng-dist; Fri, 17 Nov 2000 16:43:24 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAI0hFj14583 for ; Fri, 17 Nov 2000 16:43:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA02750 for ; Fri, 17 Nov 2000 16:43:15 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA07109 for ; Fri, 17 Nov 2000 16:43:14 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 17 Nov 2000 16:42:27 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 17 Nov 2000 16:43:06 -0800 (Pacific Standard Time) Received: from DF-MAX.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 17 Nov 2000 16:43:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4591.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: IPV6_USEMTU socket option Date: Fri, 17 Nov 2000 16:43:07 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657401D42D83@DF-BOWWOW.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPV6_USEMTU socket option Thread-Index: AcBQ9wrD6H2/PWbQSQmggyMIiqZ0+QAAQHpw From: "Dave Thaler" To: "Erik Nordmark" , "Francis Dupont" Cc: "Yves Legrandgerard" , "JINMEI Tatuya / ????" , X-OriginalArrivalTime: 18 Nov 2000 00:43:07.0593 (UTC) FILETIME=[84C41B90:01C050F8] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark writes: > > => I agree, it should be a library function (still in advanced API > > but not as a getsockopt()). > > > > Francis.Dupont@enst-bretagne.fr > > > > PS: on some systems getsockopt() is not supposed to have an argument > > (ie. optval points only to a buffer for the result) then be careful. > > Good point. getsockopt only does a copyout from the kernel. > > Do you have a proposal for a name of a function which retrieves the > path MTU for a destination/path? We ran into a similar problem with the multicast source filter API in http://www.ietf.org/internet-drafts/draft-ietf-idmr-msf-api-01.txt We decided to use ioctl() as a result, and the above draft includes the note: SIOCGIPMSFILTER could not be done with getsockopt(), since the group and interface must be passed down in order to retrieve the correct filter. This can, however, be done with an ioctl(), and hence for symmetry, both gets and sets are done with an ioctl. -Dave Thaler -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 17 17:43:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAI1fkO14618 for ipng-dist; Fri, 17 Nov 2000 17:41:46 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAI1faj14611 for ; Fri, 17 Nov 2000 17:41:37 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA14599 for ; Fri, 17 Nov 2000 17:41:37 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA17972 for ; Fri, 17 Nov 2000 17:41:36 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA07285; Fri, 17 Nov 2000 17:41:34 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <3A15B6B2.D29AAED@txc.com> References: <20001115190919.321B17EF9@starfruit.itojun.org> <200011160958.KAA90047@givry.rennes.enst-bretagne.fr> <14867.59850.899996.178063@thomasm-u1.cisco.com> <3A142DEE.AA44B45F@txc.com> <3A1584F1.79185912@txc.com> <3A15B6B2.D29AAED@txc.com> Date: Fri, 17 Nov 2000 17:41:32 -0800 To: Alex Conta From: Steve Deering Subject: Re: Usage of IPv6 flow label Cc: Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:52 PM -0500 11/17/00, Alex Conta wrote: >Since the IPv6 flow label work started, two major efforts in IETF made >significant progress on related topics: Diffserv and MPLS. Alex, Diffserv is in no way related to the Flow Label. IPv6 has the Traffic Class field for diffserv-style QoS. The Flow Label was intended to serve intserv-style QoS. >As an extension of the Diffserv aggregation model, the flow label SHOULD >be re-writable. If you think about extending your argument to Diffserv, >then Diffserv aggregated flows should be always tunneled. Intserv-style QoS, and the aggregation of intserv flows, is not an extension of the diffserv aggregation (do you mean reclassification?) model. If you want to do diffserv-style aggregation/reclassification, go ahead and use the IPv6 Traffic Class field, which is intended for that purpose. >The argument boils down to **forcing "read-only" onto flow labels does >not pay**. We arranged for the Flow Label to be excluded from the AH authentication function, precisely so it could safely be modified en-route, i.e., far from "forcing" it to be read only, we have gone out of our way to make it mutable. We patiently await a spec that says exactly how to use re-writable flow labels *including* how to allocate flow labels for multicast flows crossing multi-access links. It is the messiness and fragility of solutions to that latter problem that led to the initial end-to-end, instead of hop-by-hop, design of the Flow Label. > On the contrary. >I think that the MPLS work is a significant progress on the concept, and >mechanisms of labeling flows, and as you know [(-:], I think IPv6 >should borrow from it, rather than going against, or going on a path >that was started before the MPLS effort, but so far didn't go far enough >to be sufficiently significant. MPLS was not designed to address the same problems, across the same range of link types, as the Flow Label. (Granted, MPLS's purposes have kept changing over time, but it's still true today.) If you all you want is MPLS for IPv6, go ahead and use MPLS under IPv6. It works just fine (or rather, as well as it does for IPv4). >Some of the weight, or basis, or the hidden reason, of your tunneling >argument comes, I think, from the fact that as of now, a flow label >defines uniquely a flow, only when associated with the source address. >Because of the need of the 20 + 128 bits for flow identification, just >re-writing the flow label would not do it: you need a new source address >as well for the flow identification. No, my arguments for tunneling do not derive from the constraints of the Flow Label design, and would be the same whether the Flow Label were end-to-end or hop-by-hop. The end-to-end Flow Label design derived from the observed problems with doing label allocation for multi-access links. (Most of the complexity of the ST protocol, which has hop-by-hop, layer-3 flow labels/tags/VCIs, arose from trying to deal with that scenario.) The end-to-end design avoids those problems, at the cost of a somewhat more expensive look-up. Fortunately, router designers have gotten better with sophisticated look-up algorithms, so we no longer have to stick with small-integer indexing to get highest-speed forwarding (MPLS's original raison d'etre). >But this (148 bits for uniquely identifying a flow), as well as >re-writing, local, or global significance, unicity, etc... are all >things that should be on the table for discussion. They are on the table for discussion, and have been for years. That's why it's in an appendix of the spec. 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 Fri Nov 17 21:54:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAI5rIe14736 for ipng-dist; Fri, 17 Nov 2000 21:53:18 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAI5r6j14729 for ; Fri, 17 Nov 2000 21:53:07 -0800 (PST) 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,v1.7) with ESMTP id VAA13717 for ; Fri, 17 Nov 2000 21:53:05 -0800 (PST) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA26772 for ; Fri, 17 Nov 2000 22:53:04 -0700 (MST) Received: from ix.netcom.com (user-2inic04.dialup.mindspring.com [165.121.48.4]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id AAA19514; Sat, 18 Nov 2000 00:52:52 -0500 (EST) Message-ID: <3A1638FF.F072E677@ix.netcom.com> Date: Sat, 18 Nov 2000 00:08:32 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: JIM FLEMING CC: DOMAIN-POLICY@LISTS.NETSOL.COM, frezza@alum.mit.edu, "vinton g. cerf - ISOC" , ISI IPv6 list <6bone@ISI.EDU>, Internet Architecture Board , IPng List Subject: Re: Internet Protocol Version 6 Workshop References: <082801c0510b$4ba3f3e0$df00a8c0@vaio> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim and all, As you know Jim, and possibly you too Vint, I am on the WG for IPv6 and have been following some of the discussion and assisting where I have something to contribute. A little over a year ago, there was some heated debate (I was involved) regarding the Privacy concerns with IPv6. Most of this is do to two problems. One being the "Autoconfig" for implementation specification for IPv6, the other is the "Always On" feature of IPv6. The implementation (Autoconfig as default) was and remains that biggest problem with respect to Privacy issues. (Autoconfig) should not be default was my argument for implementation. I also suggested several changes to the Spec for Autoconfig for consideration. But the majority of the group felt that being able to track folks easily was more important. I found this astounding. As a consequence I was soon contacted by several members of the press and did a few interviews regarding the concerns of Privacy with IPv6 which raised quite a fuss with the IETF community at the time. JIM FLEMING wrote: > Vint, > > Will you be telling them about the IPv6 Privacy Problem? > > http://www.internetwk.com/columns/frezz100499.htm > > http://www.comsoc.org/confs/IPv6/ > Internet Protocol Version 6 Workshop > IPv6: The New Internet Tidal Wave > 27 November 2000 > Fairmont Hotel, San Francisco, CA USA > @@@@@@@@@@@@@@@@ > http://www.globecom2000.com/daireg/agenda.view.cfm?daiRegID=59&agendaGroupID > =10 > > Jim Fleming > http://www.unir.com/images/architech.gif > http://www.unir.com/images/address.gif > http://www.unir.com/images/headers.gif > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 112k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1800 x1894 or 9236 fwd's to home ph# Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 18 00:11:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAI89r914798 for ipng-dist; Sat, 18 Nov 2000 00:09:53 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAI89cj14790 for ; Sat, 18 Nov 2000 00:09:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA15393; Sat, 18 Nov 2000 00:09:37 -0800 (PST) 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 BAA28053; Sat, 18 Nov 2000 01:09:35 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id QAA15247; Sat, 18 Nov 2000 16:55:43 +0900 (JST) Date: Sat, 18 Nov 2000 16:15:34 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option In-Reply-To: In your message of "Fri, 17 Nov 2000 16:28:00 -0800 (PST)" References: User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 91 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 17 Nov 2000 16:28:00 -0800 (PST), >>>>> Erik Nordmark said: > This is what I've edited together so far. Thanks for the quick revise. Here are some comments: > 11.2. Sending without fragmentation We might have to clarify what happens if the application disables fragmentation, but sends a larger packet than the MTU of the outgoing interface. For example, just return an EMSGSIZE error, return an IPV6_PATHMTU ancillary data item (if the application sets IPV6_RECVPATHMTU beforehand), or both... > 11.3. Path MTU Discovery and UDP > UDP and raw socket applications need to be able to determine the > "maximum send transport-message size" (Section 5.1 of [RFC-1981]) to > a given destination so that those applications can participate in > path MTU discovery. This lets those applications send smaller > datagrams to the destination, avoiding fragmentation. > This is accomplished using a new ancillary data item (IPV6_PATHMTU) > which is delivered to recvmsg() without any actual data. The > application enable the receipt of IPV6_PATHMTU ancillary data items > by enabing IPV6_RECVPATHMTU. > int on = 1; > setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPATHMTU, &on, sizeof(on)); > By default, this socket option is disabled. Setting the value to 0 > also disables the option. > When the application is sending packets too big for the path MTU > recvmsg will return zero (indicating no data) but there will be a > cmsghdr with cmsg_type set to IPV6_PATHMTU, and cmsg_len will > indicate that cmsg_data is 4 bytes long. CMSG_DATA will point to a Now we define and use struct ip6_mtuinfo, thus the size of cmsg_data is not 4 bytes, but (at least) sizeof(struct ip6_mtuinfo). > struct ip6_ carrying the path MTU to use together with the IPv6 "mtuinfo" is missed after "ip6_". > destination address. > struct ip6_mtuinfo { > struct sockaddr_in6 ip6m_addr; /* dst IPv6 address including scope > */ > unsigned int ip6m_mtu; /* path MTU in host byte order */ Is "unsigned int" appropriate here (I'm just wondering, not sure on this)? > }; And, as I said in a pervious message, the draft should clearly state that this ancillary data should be passed to every socket that wants, even if the socket is non-connected. I'd propsose the following paragraph to be added. This cmsghdr will be passed to every socket that sets the IPV6_RECVPATHMTU socket option, even if the socket is non-connected. Note that this also means an application that sets the option may get the ancillary data upon a too big message sent from other applications to the same destination. An implementation may skip to deliver the data to sockets that connect a different foreign address from the destination address of the corresponding ip6_mtuinfo strucutre. This is based on the behavior of our implementation, but I don't stick to minor details (e.g. the last sentence). > XXX What about more complex paths e.g. when using a routing header? How about the following text? When an application sends packet with a routing header, the final destination stored in the ip6m_addr member does not necessarily contain complete information of the entire path. Thus, an implementation may append an additional data structure after ip6_mtuinfo to tell the application precise information of the entire path. This definition of the additinaol structure is beyond the scope of this document. 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 Nov 18 00:11:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAI89na14797 for ipng-dist; Sat, 18 Nov 2000 00:09:49 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAI89Yj14782 for ; Sat, 18 Nov 2000 00:09:34 -0800 (PST) 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,v1.7) with ESMTP id AAA00822; Sat, 18 Nov 2000 00:09:35 -0800 (PST) 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 BAA28041; Sat, 18 Nov 2000 01:09:32 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id QAA15244; Sat, 18 Nov 2000 16:55:38 +0900 (JST) Date: Sat, 18 Nov 2000 15:33:18 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option In-Reply-To: In your message of "Fri, 17 Nov 2000 16:21:19 -0800 (PST)" References: User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: multipart/mixed; boundary="Multipart_Sat_Nov_18_15:33:18_2000-1" X-Dispatcher: imput version 980905(IM100) Lines: 158 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Multipart_Sat_Nov_18_15:33:18_2000-1 Content-Type: text/plain; charset=US-ASCII >>>>> On Fri, 17 Nov 2000 16:21:19 -0800 (PST), >>>>> Erik Nordmark said: >> I think this type of option can be useful, but I still think the >> IPV6_USEMTU option (which allows an application to specify the path >> MTU for an outgoing packet) is useful as well. And, if we take this >> approach, prohibiting fragment can be implemented as a special case of >> the option (i.e, setting a very large value as the MTU). What do you >> think of this? > If we want an IPV6_USEMTU option I think that needs to be separate from > prohibiting fragmentation, since I think the overloading you propose would > be confusing. Hmm, okay, I agree. > If the path MTU is 2000 bytes and the interface MTU is 8000 bytes > I would expect that an IPV6_USEMTU value between 2000 and 8000 would > transmit an unfragmented packet. I assume your proposal is that when the > IPv6_USEMTU value is set to a number larger than 8000 this would cause > the packet to be dropped (and an IPV6_PATHMTU sent up as ancillary data > if the socket had IPV6_RECVPATHMTU enabled). Thus setting IPV6_USEMTU > to 2^^32-1 would be the same as disabling fragmentation. Yes, that was my intention, but I now agree with a separate socket option to disable fragmentation. > But when using IPV6_USEMTU as you propose would the MTU be for all > destination addresses on the socket? Or would IPV6_USEMTU carry > an address in addition to an mtu? Well, sorry, the wording was incorrect in the original message. I intended a new ancillary data item "IPV6_USEMTU" (not a socket option) for outgoing UDP or raw IPv6 packets, because I imagined an application which opens a singe, non-connected socket for multiple destinations. The IPV6_USEMTU item, of course, would affect the corresponding outgoing packet only. This also means that the actual data for IPV6_USEMTU contains the path MTU only (which may be a 32bit integer). > Do you have an example of an application which might need such a feature? Yes, please see the attached e-mail. As described in the message, NFS might not be a good example (due to the actual implementation issue). However, NetBSD's IPv6 NFS implementation has this kind of problem, and currently does not work if the path MTU is smaller than the MTU of the outgoing interface. I can easily imagine a same kind of prroblem can arise for "pure" user space applications, and, in fact, DHCPv6 server could be a practical example (as I said in the attached e-mail). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Sat_Nov_18_15:33:18_2000-1 Content-Type: message/rfc822 Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id WAA04941 for ; Thu, 16 Nov 2000 22:27:00 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id WAA26281 for ; Thu, 16 Nov 2000 22:40:53 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id WAA01223 for ; Thu, 16 Nov 2000 22:40:53 +0900 (JST) Received: from maltese.wide.toshiba.co.jp ([202.249.10.99]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with ESMTP id WAA28474 for ; Thu, 16 Nov 2000 22:40:52 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id WAA01219 for ; Thu, 16 Nov 2000 22:40:52 +0900 (JST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id WAA26277 for ; Thu, 16 Nov 2000 22:40:49 +0900 (JST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA12022; Thu, 16 Nov 2000 05:40:38 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA04455; Thu, 16 Nov 2000 05:40:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAGDcST10123 for ipng-dist; Thu, 16 Nov 2000 05:38:28 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAGDcJj10116 for ; Thu, 16 Nov 2000 05:38:19 -0800 (PST) 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,v1.7) with ESMTP id FAA04274 for ; Thu, 16 Nov 2000 05:38:20 -0800 (PST) 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 FAA06159 for ; Thu, 16 Nov 2000 05:38:19 -0800 (PST) Received: from localhost ([3ffe:501:100f:10c1:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id WAA04928 for ; Thu, 16 Nov 2000 22:24:24 +0900 (JST) Date: Thu, 16 Nov 2000 22:37:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option In-Reply-To: In your message of "Tue, 14 Nov 2000 09:42:19 +0100" <200011140842.JAA77413@givry.rennes.enst-bretagne.fr> References: <200011140842.JAA77413@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-UIDL: Bk)!!42m!!LMT!!B>>>> On Tue, 14 Nov 2000 09:42:19 +0100, >>>>> Francis Dupont said: > In your previous mail you wrote: > I'm now considering UDP applications that are sensitive to path MTU > (toward the destinations). I recalled a discussion about a new socket > option "IPV6_USEMTU", which allowed an application to specify an > appropriate path MTU for packets sent from the application. I checked > the archive of this list in April 2000, and, to my suprise, the > discussion suddenly disappeared without any consensus. > => today only IPV6_USE_MIN_MTU seems to be defined, implemented and > used (for instance by BIND and racoon, the KAME IKE daemon). > I don't know if IPV6_USEMTU as you define is very useful but the > getsockopt() counterpart (which gives the actual path MTU) *is* useful. > Perhaps the getsockopt() with a standard way to disable fragmentation > is enough (it should be enough for a traceroute_pmtu6)? My main concern is about UDP applications that can't divide outgoing data into multiple packets but do not want to fragment the packet in a (much) smaller size than the path MTU. Possible examples would be NFS and DHCP. I admit that NFS may not be a good example, because in UNIX systems, NFS is typically implemented in the kernel. 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 -------------------------------------------------------------------- --Multipart_Sat_Nov_18_15:33:18_2000-1-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 18 01:49:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAI9lfd14871 for ipng-dist; Sat, 18 Nov 2000 01:47:41 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAI9lUj14864 for ; Sat, 18 Nov 2000 01:47:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA24572; Sat, 18 Nov 2000 01:47:29 -0800 (PST) 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 CAA17003; Sat, 18 Nov 2000 02:47:27 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id SAA15411; Sat, 18 Nov 2000 18:33:35 +0900 (JST) Date: Sat, 18 Nov 2000 18:37:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option In-Reply-To: In your message of "Fri, 17 Nov 2000 16:28:00 -0800 (PST)" References: User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 32 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 17 Nov 2000 16:28:00 -0800 (PST), >>>>> Erik Nordmark said: > This is what I've edited together so far. > 11.3. Path MTU Discovery and UDP > UDP and raw socket applications need to be able to determine the > "maximum send transport-message size" (Section 5.1 of [RFC-1981]) to > a given destination so that those applications can participate in > path MTU discovery. This lets those applications send smaller > datagrams to the destination, avoiding fragmentation. > This is accomplished using a new ancillary data item (IPV6_PATHMTU) > which is delivered to recvmsg() without any actual data. The > application enable the receipt of IPV6_PATHMTU ancillary data items > by enabing IPV6_RECVPATHMTU. I have one more question about the option. What if the size of an outgoing packet is larger than the MTU of the outgoing interface on the sending node, when the application set the IPV6_RECVPATHMTU option? Should the kerenl pass the IPV6_PATHMTU ancillary data with the MTU of the outgoing interface? (BTW, our current implementation does not pass the ancillary data on the sending node. In such a case, it just fragment the packet using the MTU of the outgoing interface.) 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 Nov 18 06:57:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAIEtwW15009 for ipng-dist; Sat, 18 Nov 2000 06:55:58 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAIEtnj15002 for ; Sat, 18 Nov 2000 06:55:49 -0800 (PST) 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,v1.7) with ESMTP id GAA09030 for ; Sat, 18 Nov 2000 06:55:46 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28808 for ; Sat, 18 Nov 2000 06:55:45 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAIEt2b49240; Sat, 18 Nov 2000 15:55:05 +0100 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 PAA00615; Sat, 18 Nov 2000 15:55:01 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id PAA04438; Sat, 18 Nov 2000 15:57:21 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011181457.PAA04438@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jun-ichiro itojun Hagino cc: Tim Hartrick , ipng@sunroof.eng.sun.com Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU In-reply-to: Your message of Sat, 18 Nov 2000 01:18:01 +0900. <20001117161801.48FBF7EF9@starfruit.itojun.org> Date: Sat, 18 Nov 2000 15:57:21 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >PS: I've tried one day the 2*64 definition on a Sparc (ie. with 64 bit >alignment). It didn't work because of some details, for instance the >route structure (pointer + sockaddr) or IPv6 over ATM (32 bit difference >in alignment between unicast and multicast). I can't see a good reason >to add a new source of problems... for the latter case, you need __attribute__((__packed__)) (gcc-ism) for header declaration. to control structure packing. => don't joke with my stomach! Just put the fields in the best order. 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 Nov 18 07:15:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAIFDtu15036 for ipng-dist; Sat, 18 Nov 2000 07:13:55 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAIFDkj15029 for ; Sat, 18 Nov 2000 07:13:46 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA10106; Sat, 18 Nov 2000 07:13:44 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25431; Sat, 18 Nov 2000 07:13:43 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAIFDdb41469; Sat, 18 Nov 2000 16:13:39 +0100 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 QAA01169; Sat, 18 Nov 2000 16:13:38 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id QAA04572; Sat, 18 Nov 2000 16:16:03 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011181516.QAA04572@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Yves Legrandgerard , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option In-reply-to: Your message of Fri, 17 Nov 2000 16:28:00 PST. Date: Sat, 18 Nov 2000 16:16:03 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: This information is retrived using IPV6_PATHMTU. struct ip6_mtuinfo mtuinfo; mtuinfo.ip6m_addr = addr; /* address */ getsockopt(fd, IPPROTO_IPV6, IPV6_PATHMTU, &mtuinfo, sizeof(&mtuinfo)); => I am sorry but this tries to give some data (here the address) to the kernel via a getsockopt(). This is both not implementable on many kernels and not compliant with standard getsockopt() definition. For instance on my FreeBSD 3.x I have: GETSOCKOPT(2) FreeBSD System Calls Manual GETSOCKOPT(2) NAME getsockopt, setsockopt - get and set options on sockets SYNOPSIS #include #include int getsockopt(int s, int level, int optname, void *optval, int *optlen) int setsockopt(int s, int level, int optname, const void *optval, int optlen) DESCRIPTION ... The parameters optval and optlen are used to access option values for setsockopt(). For getsockopt() they identify a buffer in which the value for the requested option(s) are to be returned. For getsockopt(), optlen is a value-result parameter, initially containing the size of the buffer pointed to by optval, and modified on return to indicate the actual size of the value returned. If no option value is to be supplied or returned, optval may be NULL. I've looked at getsockopt() definition on some other OSs, the only difference is some say NULL, some say 0... Regards Francis.Dupont@enst-bretagne.fr PS: of course the connected option (not the #3) has not this problem. I believe the path MTU is a PCB property then for an unconnected PCB the path MTU should be the largest compatible interface MTU (or the specified MTU if IPV6_USE*MTU is set). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 18 07:33:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAIFWDx15064 for ipng-dist; Sat, 18 Nov 2000 07:32:13 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAIFW4j15057 for ; Sat, 18 Nov 2000 07:32:04 -0800 (PST) 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,v1.7) with ESMTP id HAA11402; Sat, 18 Nov 2000 07:32:03 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02991; Sat, 18 Nov 2000 07:32:01 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAIFVwb35494; Sat, 18 Nov 2000 16:31:58 +0100 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 QAA01680; Sat, 18 Nov 2000 16:31:51 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id QAA04623; Sat, 18 Nov 2000 16:34:18 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011181534.QAA04623@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Yves Legrandgerard , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option In-reply-to: Your message of Fri, 17 Nov 2000 16:29:30 PST. Date: Sat, 18 Nov 2000 16:34:18 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => I agree, it should be a library function (still in advanced API > but not as a getsockopt()). > > Francis.Dupont@enst-bretagne.fr > > PS: on some systems getsockopt() is not supposed to have an argument > (ie. optval points only to a buffer for the result) then be careful. Good point. getsockopt only does a copyout from the kernel. => and your precedent mail proposed something which doesn't work... Do you have a proposal for a name of a function which retrieves the path MTU for a destination/path? => getpathmtu() ? But see the postscriptum. Thanks Francis.Dupont@enst-bretagne.fr PS: I have changed my mind: Yves Legrandgerard convinced me that the whole stuff should have similar interfaces then a getsockopt() is better but should return only the MTU (32 bit unsigned integer) for connected sockets (or largest compatible interface MTU for unconnected sockets). Same for the ancillary data version (where the address is redundant). PPS: NetBSD has something similar named IP_ERRORMTU which gets (by a getsockopt()) the MTU to use at the last EMSGSIZE error. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 18 08:58:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAIGubZ15103 for ipng-dist; Sat, 18 Nov 2000 08:56:37 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAIGuMj15088 for ; Sat, 18 Nov 2000 08:56:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA21445 for ; Sat, 18 Nov 2000 08:56:21 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05439 for ; Sat, 18 Nov 2000 09:56:20 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAIGtdb41030; Sat, 18 Nov 2000 17:55:40 +0100 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 RAA04024; Sat, 18 Nov 2000 17:55:38 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id RAA05001; Sat, 18 Nov 2000 17:58:05 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011181658.RAA05001@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option In-reply-to: Your message of Sat, 18 Nov 2000 16:15:34 +0900. Date: Sat, 18 Nov 2000 17:58:05 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > 11.2. Sending without fragmentation We might have to clarify what happens if the application disables fragmentation, but sends a larger packet than the MTU of the outgoing interface. For example, just return an EMSGSIZE error, return an IPV6_PATHMTU ancillary data item (if the application sets IPV6_RECVPATHMTU beforehand), or both... => I don't understand: you can't get ancillary data from a sending system call then the only possibility is to return an EMSGSIZE error. Of course the kernel can/should keep the value of the MTU to use... And, as I said in a pervious message, the draft should clearly state that this ancillary data should be passed to every socket that wants, even if the socket is non-connected. => I don't understand what is non-connected with ancillary data. If you have ancillary data then addresses are available, non-connected is for get/setsockopt()... > XXX What about more complex paths e.g. when using a routing header? How about the following text? When an application sends packet with a routing header, the final destination stored in the ip6m_addr member does not necessarily contain complete information of the entire path. Thus, an implementation may append an additional data structure after ip6_mtuinfo to tell the application precise information of the entire path. This definition of the additinaol structure is beyond the scope of this document. => finally I believe the option #3 is too complex for its little utility... 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 Nov 18 09:13:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAIHC6b15130 for ipng-dist; Sat, 18 Nov 2000 09:12:06 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAIHBvj15123 for ; Sat, 18 Nov 2000 09:11:57 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA07887; Sat, 18 Nov 2000 09:11:56 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15037; Sat, 18 Nov 2000 09:11:53 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAIHBFb49179; Sat, 18 Nov 2000 18:11:15 +0100 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 SAA04448; Sat, 18 Nov 2000 18:11:13 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA05071; Sat, 18 Nov 2000 18:13:40 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011181713.SAA05071@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option In-reply-to: Your message of Sat, 18 Nov 2000 15:33:18 +0900. Date: Sat, 18 Nov 2000 18:13:40 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > But when using IPV6_USEMTU as you propose would the MTU be for all > destination addresses on the socket? Or would IPV6_USEMTU carry > an address in addition to an mtu? Well, sorry, the wording was incorrect in the original message. I intended a new ancillary data item "IPV6_USEMTU" (not a socket option) => I am in the principle strongly against something which is available only as an ancillary data and not a socket option. for outgoing UDP or raw IPv6 packets, because I imagined an application which opens a singe, non-connected socket for multiple destinations. The IPV6_USEMTU item, of course, would affect the corresponding outgoing packet only. This also means that the actual data for IPV6_USEMTU contains the path MTU only (which may be a 32bit integer). => with IPV6_USEMTU IPV6_USE_MIN_MTU is no more useful (it is IPV6_USEMTU with 1280). My main concern is about UDP applications that can't divide outgoing data into multiple packets but do not want to fragment the packet in a (much) smaller size than the path MTU. Possible examples would be NFS and DHCP. I admit that NFS may not be a good example, because in UNIX systems, NFS is typically implemented in the kernel. => I still can't see if IPV6_USEMTU is very useful. Why don't rely on the standard fragmentation when paths are stable and on IPV6_USE_MIN_MTU when they are unstable and this is very important to avoid the lost of first packets (the price of path MTU discovery). NFS is in the first category, the DNS and IKE in the second with perhaps off-link DHCP. 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 Sat Nov 18 09:20:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAIHJfU15149 for ipng-dist; Sat, 18 Nov 2000 09:19:41 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAIHJWj15142 for ; Sat, 18 Nov 2000 09:19:32 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA07587; Sat, 18 Nov 2000 09:19:30 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA17284; Sat, 18 Nov 2000 09:19:27 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAIHInb48654; Sat, 18 Nov 2000 18:18:50 +0100 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 SAA04663; Sat, 18 Nov 2000 18:18:48 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA05110; Sat, 18 Nov 2000 18:21:15 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011181721.SAA05110@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option In-reply-to: Your message of Sat, 18 Nov 2000 18:37:46 +0900. Date: Sat, 18 Nov 2000 18:21:15 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I have one more question about the option. What if the size of an outgoing packet is larger than the MTU of the outgoing interface on the sending node, when the application set the IPV6_RECVPATHMTU option? Should the kerenl pass the IPV6_PATHMTU ancillary data with the MTU of the outgoing interface? => I can't see the issue. The kernel doesn't return ancillary data on sending system calls. It will fragment the packet or return an EMSGSIZE if fragmentation is disable, and will return the path MTU (less or equal to the MTU of the outgoing interface) in an ancillary data on a receiving system call or a getsockopt(). (BTW, our current implementation does not pass the ancillary data on the sending node. In such a case, it just fragment the packet using the MTU of the outgoing interface.) => IPV6_RECVPATHMTU is not supposed to do something on the sending side, is it? 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 Nov 18 09:25:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAIHNju15167 for ipng-dist; Sat, 18 Nov 2000 09:23:45 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAIHNYj15160 for ; Sat, 18 Nov 2000 09:23:34 -0800 (PST) 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,v1.7) with ESMTP id JAA19936 for ; Sat, 18 Nov 2000 09:23:34 -0800 (PST) Received: from starfruit.itojun.org (ny-ppp001.iij-us.net [216.98.99.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14901 for ; Sat, 18 Nov 2000 09:23:32 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id E4EC47EF9; Sun, 19 Nov 2000 02:23:21 +0900 (JST) To: Francis Dupont Cc: Tim Hartrick , ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Sat, 18 Nov 2000 15:57:21 +0100. <200011181457.PAA04438@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: [advanced API] how to get the destination address for IPV6_RECVPATHMTU From: Jun-ichiro itojun Hagino Date: Sun, 19 Nov 2000 02:23:21 +0900 Message-Id: <20001118172321.E4EC47EF9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >PS: I've tried one day the 2*64 definition on a Sparc (ie. with 64 bit > >alignment). It didn't work because of some details, for instance the > >route structure (pointer + sockaddr) or IPv6 over ATM (32 bit difference > >in alignment between unicast and multicast). I can't see a good reason > >to add a new source of problems... > for the latter case, you need __attribute__((__packed__)) (gcc-ism) > for header declaration. to control structure packing. >=> don't joke with my stomach! Just put the fields in the best order. for packet format on the wire, you really need to control the alignment of structure members explicitly. you cannot just rely upon the compiler padding (or your code will not be future-proven). 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 Nov 18 12:36:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAIKYDW15251 for ipng-dist; Sat, 18 Nov 2000 12:34:13 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAIKY4j15244 for ; Sat, 18 Nov 2000 12:34:04 -0800 (PST) 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,v1.7) with ESMTP id MAA03744 for ; Sat, 18 Nov 2000 12:34:03 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04863 for ; Sat, 18 Nov 2000 12:34:03 -0800 (PST) Received: from vaio (as1-190.chi.il.dial.anet.com [198.92.156.190]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id OAA12752 for ; Sat, 18 Nov 2000 14:27:52 -0600 (CST) Message-ID: <102c01c0519e$1ca2fc60$df00a8c0@vaio> From: "JIM FLEMING" To: Subject: Fw: ICANN Leaders Promoting IPv6 and its PRIVACY PROBLEM Date: Sat, 18 Nov 2000 14:28:27 -0600 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: JIM FLEMING To: ; ; ; ; ; ; ; Cc: ; ; ; "vinton g. cerf" ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; < Sent: Saturday, November 18, 2000 2:21 PM Subject: ICANN Leaders Promoting IPv6 and its PRIVACY PROBLEM > http://www.ntia.doc.gov/ntiahome/press/2000/joint102000.htm > C. Lee Peeler, > Associate Director, Division of Advertising > Practices, Federal Trade Commission > > Michael Horowitz, > Chief of Staff for the Assistant Attorney > General to the Criminal Division, > Department of Justice > > Gregory L. Rohde > Assistant Secretary for Communications and Information and > Administrator, National Telecommunications and > Information Administration, Department of Commerce > > "The record of the COPA hearings makes clear that significant efforts have > been made to respond to this challenge of protecting children online. > ...Instead, government and industry need to work together to devise an > improved "safety net" of protections -- coupling improved technology with > new self-regulatory standards -- to reduce children's exposure to commercial > pornography and other sexually explicit materials online." > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > > > Please note, while the U.S. Department of Commerce spends its time > trying to develop policies to protect children (and hopefully also adults), > other people (including ICANN leaders) are running around promoting > IPv6 which has a Privacy Problem, which will EXPOSE children and adults, > when they do not know it.[1] > > [1] http://www.internetwk.com/columns/frezz100499.htm > > > http://www.comsoc.org/confs/IPv6/ > Internet Protocol Version 6 Workshop > IPv6: The New Internet Tidal Wave > 27 November 2000 > Fairmont Hotel, San Francisco, CA USA > @@@@@@@@@@@@@@@@ > http://www.globecom2000.com/daireg/agenda.view.cfm?daiRegID=59&agendaGroupID > =10 > > > Jim Fleming > http://www.unir.com/images/architech.gif > http://www.unir.com/images/address.gif > http://www.unir.com/images/headers.gif > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 19 07:34:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAJFWNZ15858 for ipng-dist; Sun, 19 Nov 2000 07:32:23 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAJFWDj15851 for ; Sun, 19 Nov 2000 07:32:13 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA13910 for ; Sun, 19 Nov 2000 07:32:13 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA05238 for ; Sun, 19 Nov 2000 07:32:12 -0800 (PST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id XC97AXG3; Sun, 19 Nov 2000 16:32:15 +0100 Reply-To: From: "Thomas Eklund" To: "'Steve Deering'" , "Alex Conta" Cc: "Michael Thomas" , "Metzler Jochen" , "Ipng \(E-Mail\)" Subject: RE: Usage of IPv6 flow label Date: Sun, 19 Nov 2000 16:32:13 +0100 Message-ID: <31A473DBB655D21180850008C71E251A02949277@mail.kebne.se> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Steve, > I believe IP-in-IP tunneling has become a basic tool that > routers need to > support efficiently anyway, so I'd turn it around and ask if > it's worth > the additional (and nontrivial) costs of including all the > MPLS machinery > as well. But I won't, because as I said, it's out-of-scope > for this list. The way I see it is that it is very similar function in the traffic plane of the router: - daisy chain of mpls headers - daisy chain of ipv6 extension headers Note I'NOT saying they are doing the same things BUT if you want to do layer 4 classification (for stateful inspection, ingress/egress filtering and qos etc) for v6 with its extension headers it even worse than a mpls-label stacked packet operation... Then as we have seen we can argue for a long time whether is it useful or not..:-) In fact mpls is much more light weigth tunneling protocol than ip in ip tunneling... And it could serve as a very nice transition/tunneling mechanism of an ipv6 based vpn.. MPLS solves one problem: traffic engineering - which is very nice to have in the backbone for an ISP and the MECHANISMS that mpls have introduced is very nice... But when it's run over an ipv6 environment it can be more efficient and utilize the flowlabel in the core for LSP's and do TE on them but to be more efficient running over IPv6 and utilize the flow label instead of a new l2 protocol and get better link utilazation... -- 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 Sun Nov 19 07:35:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAJFY6f15867 for ipng-dist; Sun, 19 Nov 2000 07:34:06 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAJFXoj15860 for ; Sun, 19 Nov 2000 07:33:50 -0800 (PST) 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,v1.7) with ESMTP id HAA14229 for ; Sun, 19 Nov 2000 07:33:48 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06420 for ; Sun, 19 Nov 2000 08:33:47 -0700 (MST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id XC97AXGQ; Sun, 19 Nov 2000 16:33:51 +0100 Reply-To: From: "Thomas Eklund" To: "'Alex Conta'" , "'Steve Deering'" Cc: "'Michael Thomas'" , "'Francis Dupont'" , "'Jun-ichiro itojun Hagino'" , "'Hesham Soliman \(EPA\)'" , "'Metzler Jochen'" , "'Ipng \(E-Mail\)'" Subject: RE: Usage of IPv6 flow label Date: Sun, 19 Nov 2000 16:33:49 +0100 Message-ID: <31A473DBB655D21180850008C71E251A02949278@mail.kebne.se> 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 CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <31A473DBB655D21180850008C71E251A02EE1CC1@mail.kebne.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Alex, > The argument boils down to **forcing "read-only" onto flow labels does > not pay**. On the contrary. > I think that the MPLS work is a significant progress on the > concept, and > mechanisms of labeling flows, and as you know [(-:], I think IPv6 > should borrow from it, rather than going against, or going on a path > that was started before the MPLS effort, but so far didn't go > far enough > to be sufficiently significant. > I agree with you Alex. And I also think that IPv6 should "borrow the mechanisms". An I would like to see a combine model for use of the flow-label where the "intserv"/per flow model would exist in the access and that a aggregated/"differv"/"mpls" like model with possibility to re-write the flow label would exist... -- 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 Sun Nov 19 10:06:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAJI56515984 for ipng-dist; Sun, 19 Nov 2000 10:05:06 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAJI4fj15961 for ; Sun, 19 Nov 2000 10:04:41 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA08306; Sun, 19 Nov 2000 10:04:40 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16323; Sun, 19 Nov 2000 10:04:39 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA19398; Mon, 20 Nov 2000 02:50:32 +0900 (JST) Date: Mon, 20 Nov 2000 02:25:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option In-Reply-To: In your message of "Sat, 18 Nov 2000 17:58:05 +0100" <200011181658.RAA05001@givry.rennes.enst-bretagne.fr> References: <200011181658.RAA05001@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 60 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sat, 18 Nov 2000 17:58:05 +0100, >>>>> Francis Dupont said: > In your previous mail you wrote: >> 11.2. Sending without fragmentation > We might have to clarify what happens if the application disables > fragmentation, but sends a larger packet than the MTU of the outgoing > interface. For example, just return an EMSGSIZE error, return an > IPV6_PATHMTU ancillary data item (if the application sets > IPV6_RECVPATHMTU beforehand), or both... > => I don't understand: you can't get ancillary data from a sending > system call then the only possibility is to return an EMSGSIZE error. > Of course the kernel can/should keep the value of the MTU to use... I meant that the output routine put the ancillary data into the receive queue of the sending packet. > And, as I said in a pervious message, the draft should clearly state > that this ancillary data should be passed to every socket that wants, > even if the socket is non-connected. > => I don't understand what is non-connected with ancillary data. > If you have ancillary data then addresses are available, non-connected > is for get/setsockopt()... Sorry, I don't understand what you meant here. BTW: my proposal is just from Erik's intention: >>>>> On Mon, 6 Nov 2000 13:11:07 -0800 (PST), >>>>> Erik Nordmark said: >> 1. this option has its meaning for a connected socket only. The >> destination is the foreign address of the socket. (snip) > The spec is clearly incomplete in this area. > I do think we want this to work for unconnected datagram sockets i.e. 1 is > not an option. >> XXX What about more complex paths e.g. when using a routing header? > How about the following text? > When an application sends packet with a routing header, the final > destination stored in the ip6m_addr member does not necessarily > contain complete information of the entire path. Thus, an > implementation may append an additional data structure after > ip6_mtuinfo to tell the application precise information of the > entire path. This definition of the additinaol structure is beyond > the scope of this document. > => finally I believe the option #3 is too complex for its little utility... Okay, then how do we pass the destination address to non-noconnected socket? 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 Sun Nov 19 10:06:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAJI58f15986 for ipng-dist; Sun, 19 Nov 2000 10:05:08 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAJI4hj15966 for ; Sun, 19 Nov 2000 10:04:43 -0800 (PST) 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,v1.7) with ESMTP id KAA21478; Sun, 19 Nov 2000 10:04:41 -0800 (PST) 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 KAA13122; Sun, 19 Nov 2000 10:04:40 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA19401; Mon, 20 Nov 2000 02:50:36 +0900 (JST) Date: Mon, 20 Nov 2000 02:32:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option In-Reply-To: In your message of "Sat, 18 Nov 2000 18:21:15 +0100" <200011181721.SAA05110@givry.rennes.enst-bretagne.fr> References: <200011181721.SAA05110@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 36 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sat, 18 Nov 2000 18:21:15 +0100, >>>>> Francis Dupont said: > I have one more question about the option. What if the size of an > outgoing packet is larger than the MTU of the outgoing interface on > the sending node, when the application set the IPV6_RECVPATHMTU > option? Should the kerenl pass the IPV6_PATHMTU ancillary data with > the MTU of the outgoing interface? > => I can't see the issue. The kernel doesn't return ancillary data > on sending system calls. It will fragment the packet or return an > EMSGSIZE if fragmentation is disable, and will return the path MTU > (less or equal to the MTU of the outgoing interface) in an ancillary > data on a receiving system call or a getsockopt(). > (BTW, our current implementation does not pass the ancillary data on > the sending node. In such a case, it just fragment the packet using > the MTU of the outgoing interface.) > => IPV6_RECVPATHMTU is not supposed to do something on the sending side, > is it? I think you and I said the same thing, but there may be some misunderstanding due to my poor explanation (sorry). My intention was, What if the size of an outgoing packet is larger than the MTU of the outgoing interface on the sending node, when the application set the IPV6_RECVPATHMTU option? Should the application receive an IPV6_PATHMTU ancillary data item in a succeeding recvmsg call? and your answer is "yes". Am I clear enough now? 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 Sun Nov 19 10:07:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAJI57G15985 for ipng-dist; Sun, 19 Nov 2000 10:05:07 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAJI4hj15967 for ; Sun, 19 Nov 2000 10:04:44 -0800 (PST) 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,v1.7) with ESMTP id KAA21482; Sun, 19 Nov 2000 10:04:42 -0800 (PST) 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 KAA13127; Sun, 19 Nov 2000 10:04:40 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA19406; Mon, 20 Nov 2000 02:50:47 +0900 (JST) Date: Mon, 20 Nov 2000 03:04:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option In-Reply-To: In your message of "Sat, 18 Nov 2000 18:13:40 +0100" <200011181713.SAA05071@givry.rennes.enst-bretagne.fr> References: <200011181713.SAA05071@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 58 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sat, 18 Nov 2000 18:13:40 +0100, >>>>> Francis Dupont said: > In your previous mail you wrote: >> But when using IPV6_USEMTU as you propose would the MTU be for all >> destination addresses on the socket? Or would IPV6_USEMTU carry >> an address in addition to an mtu? > Well, sorry, the wording was incorrect in the original message. I > intended a new ancillary data item "IPV6_USEMTU" (not a socket option) > => I am in the principle strongly against something which is available > only as an ancillary data and not a socket option. A setsockopt equivalent of this ancillary data item is also available (especially for connected sockets). However, my main concern here is about non-connected UDP server applications, where ancillary data would be more suitable than a sticky socket option. > for outgoing UDP or raw IPv6 packets, because I imagined an > application which opens a singe, non-connected socket for multiple > destinations. The IPV6_USEMTU item, of course, would affect the > corresponding outgoing packet only. This also means that the actual > data for IPV6_USEMTU contains the path MTU only (which may be a 32bit > integer). > => with IPV6_USEMTU IPV6_USE_MIN_MTU is no more useful (it is IPV6_USEMTU > with 1280). Correct. So, IPV6_USEMTU would obsolete IPV6_USE_MIN_MTU. > My main concern is about UDP applications that can't divide outgoing > data into multiple packets but do not want to fragment the packet in a > (much) smaller size than the path MTU. Possible examples would be NFS > and DHCP. I admit that NFS may not be a good example, because in UNIX > systems, NFS is typically implemented in the kernel. > => I still can't see if IPV6_USEMTU is very useful. Why don't rely > on the standard fragmentation when paths are stable and on IPV6_USE_MIN_MTU > when they are unstable and this is very important to avoid the lost > of first packets (the price of path MTU discovery). NFS is in the first > category, the DNS and IKE in the second with perhaps off-link DHCP. Because we can't always rely on the kernel performing path MTU discovery when there's no connected PCB. The latest version of NetBSD is an example of not performing path MTU discovery without a corresponding connected PCB (for a security reason)[*]. I agree that we don't need the IPV6_USEMTU ancillary data (and socket option) if all kernel implementations surely perform path MTU discovery regardless of existence of a connected PCB. ([*]there are some other conditions, but they are not really related to this discussion, so I just omitted them.) 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 Sun Nov 19 15:20:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAJNJSI16117 for ipng-dist; Sun, 19 Nov 2000 15:19:28 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAJNJIj16110 for ; Sun, 19 Nov 2000 15:19:19 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA22947 for ; Sun, 19 Nov 2000 15:19:19 -0800 (PST) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20532 for ; Sun, 19 Nov 2000 15:19:18 -0800 (PST) Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id eAJNJH316784 for ; Mon, 20 Nov 2000 00:19:17 +0100 (MET) Received: from extmail.urz.uni-heidelberg.de (extmail.urz.uni-heidelberg.de [129.206.100.140]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with SMTP id AAA43918 for ; Mon, 20 Nov 2000 00:19:16 +0100 Received: (qmail 7981 invoked by uid 0); 19 Nov 2000 23:17:39 -0000 Received: from unknown (HELO tapir) (unknown) by unknown with SMTP; 19 Nov 2000 23:17:39 -0000 From: "Enno Rey" To: Subject: Sample config for cisco routers Date: Mon, 20 Nov 2000 00:19:31 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I'm currently preparing a presentation about IPv6. For the practical part, there will be a either a 2503 (running c2500-p-mz.v6) or a 3620 (running c3620-tipv6-mz.19990308) involved. I'm not able to find any sample configuration on cco. Anybody got any pointers? Thanks & regards, Enno Rey ereyix.urz.uni-heidelberg.de PGP 74C0 C7E1 3875 E4EB 9B75 8B9D 5E2D 3178 685B F222 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 20 01:55:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAK9sWk16689 for ipng-dist; Mon, 20 Nov 2000 01:54:32 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAK9sNj16682 for ; Mon, 20 Nov 2000 01:54:24 -0800 (PST) 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,v1.7) with ESMTP id BAA14595; Mon, 20 Nov 2000 01:54:18 -0800 (PST) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA05618; Mon, 20 Nov 2000 01:54:17 -0800 (PST) Received: from godel.logique.jussieu.fr (root@godel.logique.jussieu.fr [134.157.19.1]) by shiva.jussieu.fr (8.10.0/jtpda-5.3.3) with ESMTP id eAK9s3t32498 ; Mon, 20 Nov 2000 10:54:03 +0100 (CET) Received: from bernays.logique.jussieu.fr (bernays.logique.jussieu.fr [134.157.19.71]) by godel.logique.jussieu.fr (8.9.3/jtpda-5.3.1) with ESMTP id KAA25240 ; Mon, 20 Nov 2000 10:53:39 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200011181713.SAA05071@givry.rennes.enst-bretagne.fr> Date: Mon, 20 Nov 2000 10:59:24 +0100 (CET) From: Yves Legrandgerard To: Francis Dupont Subject: Re: IPV6_USEMTU socket option Cc: ipng@sunroof.eng.sun.com, Erik Nordmark , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 18-Nov-00 Francis Dupont wrote: > => with IPV6_USEMTU IPV6_USE_MIN_MTU is no more useful (it is IPV6_USEMTU > with 1280). We could also add an another special case in the more general option IPV6_USEMTU: IPV6_USEMTU with null MTU which would mean we want to use outgoing MTU. ---------------------------------- Yves Legrandgérard E-Mail: ylg@logique.jussieu.fr Date: 20-Nov-00 Time: 10:52:04 ---------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 20 02:39:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAKAc9A16719 for ipng-dist; Mon, 20 Nov 2000 02:38:09 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAKAc0j16712 for ; Mon, 20 Nov 2000 02:38:00 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA02030; Mon, 20 Nov 2000 02:37:58 -0800 (PST) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA05618; Mon, 20 Nov 2000 02:37:51 -0800 (PST) Received: from godel.logique.jussieu.fr (root@godel.logique.jussieu.fr [134.157.19.1]) by shiva.jussieu.fr (8.10.0/jtpda-5.3.3) with ESMTP id eAKAbUt48046 ; Mon, 20 Nov 2000 11:37:30 +0100 (CET) Received: from bernays.logique.jussieu.fr (bernays.logique.jussieu.fr [134.157.19.71]) by godel.logique.jussieu.fr (8.9.3/jtpda-5.3.1) with ESMTP id LAA25527 ; Mon, 20 Nov 2000 11:37:05 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 20 Nov 2000 11:42:51 +0100 (CET) From: Yves Legrandgerard To: Erik Nordmark Subject: Re: IPV6_USEMTU socket option Cc: ipng@sunroof.eng.sun.com, Francis Dupont , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 18-Nov-00 Erik Nordmark wrote: > > This is what I've edited together so far. > Note that the IPV6_PATHMTU option is used both as ancillary data (when > IPV6_RECVPATHMTU is enabled) and with getsockopt to retrieve the > current path MTU value for a destination. > > Comments? > Erik > > > 11.1. Sending with the Minimum MTU > [ylg]=> I would prefer to replace this option by the more general one IPV6_USEMTU (IPV6_USE_MIN_MTU <=> (IPV6_USEMTU, 1280)) and add the particular case (IPV6_USEMTU, 0) to say to the application to use the outgoing MTU (case which is not covered in your proposal, see below 11.4) > 11.2. Sending without fragmentation > [ylg]=> That's OK. And, as you wrote in a previous message, I think this stuff must be keeped separate from preceding paragraph 11.1. > 11.4. Determining the current path MTU > > path MTU value for a given destination address. If the IP layer does > not have a cached path MTU value it will return the interface MTU for > the interface that will be used when sending to the specified IPv6 > address. [ylg]=> It does not solve the problem to get/use the MTU of outgoing interface because you need the path MTU for the destination to be uncached (unless, of course, the route is deleted before). ---------------------------------- Yves Legrandgérard E-Mail: ylg@logique.jussieu.fr Date: 20-Nov-00 Time: 11:18:14 ---------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 20 02:44:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAKAhNL16745 for ipng-dist; Mon, 20 Nov 2000 02:43:23 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAKAhEj16738 for ; Mon, 20 Nov 2000 02:43:14 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA02317 for ; Mon, 20 Nov 2000 02:43:13 -0800 (PST) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07543 for ; Mon, 20 Nov 2000 02:43:12 -0800 (PST) Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id eAKAhC326293 for ; Mon, 20 Nov 2000 11:43:12 +0100 (MET) Received: from extmail.urz.uni-heidelberg.de (extmail.urz.uni-heidelberg.de [129.206.100.140]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with SMTP id LAA31448 for ; Mon, 20 Nov 2000 11:43:06 +0100 Received: (qmail 8518 invoked by uid 0); 20 Nov 2000 10:41:29 -0000 Received: from unknown (HELO tapir) (unknown) by unknown with SMTP; 20 Nov 2000 10:41:29 -0000 From: "Enno Rey" To: Subject: Re: Sample config for cisco routers Date: Mon, 20 Nov 2000 11:43:22 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, thanks to all who replied. I think I got enough input to get them up & running. As I said: Thanks & regards, Enno Rey erey@ix.urz.uni-heidelberg.de PGP 74C0 C7E1 3875 E4EB 9B75 8B9D 5E2D 3178 685B F222 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 20 03:18:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAKBGWg16778 for ipng-dist; Mon, 20 Nov 2000 03:16:32 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAKBGLj16771 for ; Mon, 20 Nov 2000 03:16:22 -0800 (PST) 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,v1.7) with ESMTP id DAA21030 for ; Mon, 20 Nov 2000 03:16:20 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA14283 for ; Mon, 20 Nov 2000 04:16:19 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04956; Mon, 20 Nov 2000 06:16:19 -0500 (EST) Message-Id: <200011201116.GAA04956@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-kitamura-ipv6-record-route-00.txt Date: Mon, 20 Nov 2000 06:16:18 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Record Route for IPv6 (RR6) Hop-by-Hop Option Extension Author(s) : H. Kitamura Filename : draft-kitamura-ipv6-record-route-00.txt Pages : 15 Date : 17-Nov-00 This document proposes a 'Record Route for IPv6 (RR6)' mechanism. It is composed of one new IPv6 hop-by-hop option (RR6 option) extension. The RR6 mechanism is redesigned to establish an optimized record route mechanism for IPv6. Two types of new features are introduced. 1. In order to prevent scalability problems and to make the mechanism flexible, the beginning and ending points of the data recording range are controlled by using their specifiers. 2. In order to record long IPv6 addresses efficiently, a simple address compression method is introduced. Since the compression is achieved by utilizing characteristics of recorded IPv6 addresses effectively, the mechanism is efficient and optimized for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kitamura-ipv6-record-route-00.txt 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-kitamura-ipv6-record-route-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-kitamura-ipv6-record-route-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: <20001117145555.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kitamura-ipv6-record-route-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kitamura-ipv6-record-route-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001117145555.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 Mon Nov 20 03:53:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAKBplw16820 for ipng-dist; Mon, 20 Nov 2000 03:51:47 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAKBpcj16813 for ; Mon, 20 Nov 2000 03:51:38 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA23069 for ; Mon, 20 Nov 2000 03:51:37 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.12.73.37]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03205 for ; Mon, 20 Nov 2000 03:51:32 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id eAKBnld18625; Mon, 20 Nov 2000 18:49:56 +0700 (ICT) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Robert Elz To: Francis Dupont cc: ipng@sunroof.eng.sun.com Subject: Re: Mutable fields and the Hop-by-Hop and Destination Options headers In-reply-to: Your message of "Wed, 15 Nov 2000 14:35:51 +0100." <200011151335.OAA84548@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Nov 2000 18:49:47 +0700 Message-ID: <18623.974720987@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 15 Nov 2000 14:35:51 +0100 From: Francis Dupont Message-ID: <200011151335.OAA84548@givry.rennes.enst-bretagne.fr> | => can you explain how you express this (for instance the | interpretation of a header depends upon where it is found) | in an API? Not the way you're expecting no. But that's because the current APIs are more like assembler level programming - the application says exactly what it wants, but other than building the packet in user space and simply telling the kernel to send it, the API doesn't have the generality to express much useful. Basically the current API provides an interface where the application builds the packet (conceptually) but has the kernel (the thing under the API, which could also be library routines) do all the bookkeeping and grunge work. A better API would allow the application to express its intent at a higher level - rather than "add fragmentation header" it would say something more like "I want to send unit packets N bytes long", and then the kernel might determine that that required a fragmentation header to be added (or not, in a particular case). With a less packet specific API, the application expresses its desire and the kernel (stack) implements it - and if to do that means putting options in the hop by hop header, then fine, or if it can be done by sticking them in DO1, then fine, or if it can be done by sticking them in DO2, also fine - of if sticking a DO header between ESP and AH is what achieves the goal, that's just fine as well, or putting it between the routing header and the frag header achieves it, fine too. The latter might be appropriate for an option that was intended to be parsed before reassembly, but only at the final destination - perhaps one to control how reassembly should proceed - maybe timer setting or something, and the API would be "reassemble in 10ms or drop" from the application to the stack. 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 Nov 20 06:50:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAKElJw17131 for ipng-dist; Mon, 20 Nov 2000 06:47:19 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAKEl9j17124 for ; Mon, 20 Nov 2000 06:47:10 -0800 (PST) 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,v1.7) with ESMTP id GAA06953 for ; Mon, 20 Nov 2000 06:47:06 -0800 (PST) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25934 for ; Mon, 20 Nov 2000 07:47:05 -0700 (MST) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id JAA01145; Mon, 20 Nov 2000 09:46:24 -0500 Message-Id: <200011201446.JAA01145@hygro.adsl.duke.edu> To: Jeff Williams cc: JIM FLEMING , DOMAIN-POLICY@LISTS.NETSOL.COM, frezza@alum.mit.edu, "vinton g. cerf - ISOC" , ISI IPv6 list <6bone@ISI.EDU>, Internet Architecture Board , IPng List Subject: Re: Internet Protocol Version 6 Workshop In-Reply-To: Message from Jeff Williams of "Sat, 18 Nov 2000 00:08:32 PST." <3A1638FF.F072E677@ix.netcom.com> Date: Mon, 20 Nov 2000 09:46:24 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff Williams writes: > A little over a year ago, there was some heated debate (I was > involved) regarding the Privacy concerns with IPv6. Most of this > is do to two problems. One being the "Autoconfig" for implementation > specification for IPv6, the other is the "Always On" feature of IPv6. > The implementation (Autoconfig as default) was and remains that > biggest problem with respect to Privacy issues. (Autoconfig) should > not be default was my argument for implementation. I also suggested > several changes to the Spec for Autoconfig for consideration. But > the majority of the group felt that being able to track folks easily > was more important. I found this astounding. This characterization of past IPng WG discussions is most definitely false and at best a gross distortion of past discussions. At no time that I can recall has the WG ever argued that "tracking folks" is a desirable goal. It is also completely inconsistent with the WG's recent decision to recommend that the IESG publish draft-ietf-ipngwg-addrconf-privacy-03.txt as a Proposed Standard. 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 Nov 20 08:42:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAKGeSv17295 for ipng-dist; Mon, 20 Nov 2000 08:40:28 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAKGeJj17288 for ; Mon, 20 Nov 2000 08:40:19 -0800 (PST) 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,v1.7) with ESMTP id IAA01008 for ; Mon, 20 Nov 2000 08:40:19 -0800 (PST) Received: from ns1.tjack.net (node-d8e94585.powerinter.net [216.233.69.133]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA19584 for ; Mon, 20 Nov 2000 09:40:18 -0700 (MST) Received: from IBM (node-d8e94582.powerinter.net [216.233.69.130]) by ns1.tjack.net (8.9.3/8.9.3) with ESMTP id JAA08962; Mon, 20 Nov 2000 09:41:10 -0800 Message-Id: <5.0.0.25.2.20001120083403.043a97b0@216.233.69.133> X-Sender: tj@216.233.69.133 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 20 Nov 2000 08:35:38 -0800 To: "Enno Rey" From: "Thomas J. Ackermann (TJACK)" Subject: Re: Sample config for cisco routers Cc: ipng@sunroof.eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_38185557==_.ALT" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --=====================_38185557==_.ALT Content-Type: text/plain; charset="us-ascii" Hi Enno, could you post your sample config to this group? I can imagine that would be of interest to many of us ;-) Thanks, Thomas At 02:43 AM 11/20/2000, you wrote: >Hi, > >thanks to all who replied. I think I got enough input to get them up & >running. >[..] Thomas J. Ackermann Internet Architect *** you don't get what you deserve, you get what you negotiate *** [this was my internet e-mail signature used in the late 80's and early 90's which I re-discovered - and how true] E-Mail: tj@tjack.com --- same e-mail address since 1987 Personal WebSite www.tjack.com/ --- Company WebSite: www.tjackcorp.com Email-2-Pager: mailto:page-tj@tjack.com Cell: 214-403-5368 Office: 888-4MELIOR Home TX: 936-441-8208 Home CA: 925-706-1205 e-Fax: 801-720-9890 Office Fax: 888-TOFAXUS Public Calendar: http://calendar.yahoo.com/public/tjackermann --=====================_38185557==_.ALT Content-Type: text/html; charset="us-ascii"
Hi Enno,

could you post your sample config to this group?

I can imagine that would be of interest to many of us ;-)

Thanks,
Thomas

At 02:43 AM 11/20/2000, you wrote:
Hi,

thanks to all who replied. I think I got enough input to get them up &
running.
[..]


Thomas J. Ackermann
Internet Architect

*** you don't get what you deserve, you get what you negotiate ***
[this was my internet e-mail signature used in the late 80's and early 90's which I re-discovered - and how true]

E-Mail: tj@tjack.com --- same e-mail address since 1987
Personal WebSite www.tjack.com/ --- Company WebSite: www.tjackcorp.com

Email-2-Pager:  mailto:page-tj@tjack.com
Cell:           214-403-5368
Office:                 888-4MELIOR
Home TX:        936-441-8208
Home CA:        925-706-1205
e-Fax:          801-720-9890
Office Fax:     888-TOFAXUS
Public Calendar:        http://calendar.yahoo.com/public/tjackermann
--=====================_38185557==_.ALT-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 20 09:43:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAKHfmB17466 for ipng-dist; Mon, 20 Nov 2000 09:41:48 -0800 (PST) Received: from locked.eng.sun.com (locked [129.146.85.189]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAKHfbj17459 for ; Mon, 20 Nov 2000 09:41:38 -0800 (PST) Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id eAKHeVI09621; Mon, 20 Nov 2000 09:40:31 -0800 (PST) Date: Mon, 20 Nov 2000 09:40:31 -0800 (PST) From: Mohan Parthasarathy Message-Id: <200011201740.eAKHeVI09621@locked.eng.sun.com> To: Francis.Dupont@enst-bretagne.fr Subject: draft-dupont-destoptupd-00.txt Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, In section 4, you tried giving names to the various option headers and i think it can be a bit more clearer. How about the following : 1) The option header before routing header (called as destination options (1) in rfc2460) can be called as routing option header as this appears only with routing header. 2) The new place that occurs between routing header and fragment header can be called as Intermediate option header. 3) The final one that appears after IPsec can be called as Destination option header. They all can have different types assigned by IANA to keep it simple. In section (5), you have argued that mutable options existing after the routing header does not make sense. But with tunnel encapsulation limit present in the intrmediate position, the limit needs change as it passes through tunnels. So, it is mutable. Could you clarify ? -mohan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 20 09:45:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAKHhtp17484 for ipng-dist; Mon, 20 Nov 2000 09:43:55 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAKHhij17477 for ; Mon, 20 Nov 2000 09:43:44 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA10621 for ; Mon, 20 Nov 2000 09:43:26 -0800 (PST) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26497 for ; Mon, 20 Nov 2000 09:43:25 -0800 (PST) Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id eAKHhO312205 for ; Mon, 20 Nov 2000 18:43:24 +0100 (MET) Received: from extmail.urz.uni-heidelberg.de (extmail.urz.uni-heidelberg.de [129.206.100.140]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with SMTP id SAA30672 for ; Mon, 20 Nov 2000 18:43:23 +0100 Received: (qmail 9491 invoked by uid 0); 20 Nov 2000 17:41:42 -0000 Received: from unknown (HELO hermes) (unknown) by unknown with SMTP; 20 Nov 2000 17:41:42 -0000 Message-ID: <013e01c05319$4eb55b90$0c60a8c0@hermes> From: "Enno Rey" To: "Thomas J. Ackermann \(TJACK\)" Cc: References: <5.0.0.25.2.20001120083403.043a97b0@216.233.69.133> Subject: Re: Sample config for cisco routers Date: Mon, 20 Nov 2000 18:42:36 +0100 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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, > could you post your sample config to this group? > I can imagine that would be of interest to many of us ;-) I won't be able to finish this work before the very end of this year. I will then post my configs & some details about the network, the tunnels etc. Regards, Enno Rey erey@ix.urz.uni-heidelberg.de PGP 74C0 C7E1 3875 E4EB 9B75 8B9D 5E2D 3178 685B F222 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 20 10:34:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAKIWZL17639 for ipng-dist; Mon, 20 Nov 2000 10:32:35 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAKIWPj17632 for ; Mon, 20 Nov 2000 10:32:26 -0800 (PST) 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,v1.7) with ESMTP id KAA14668 for ; Mon, 20 Nov 2000 10:32:12 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15061 for ; Mon, 20 Nov 2000 10:32:11 -0800 (PST) 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 KAA21387; Mon, 20 Nov 2000 10:32:11 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eAKIW9K06940; Mon, 20 Nov 2000 10:32:09 -0800 X-Virus-Scanned: Mon, 20 Nov 2000 10:32:09 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdpJIHeh; Mon, 20 Nov 2000 10:32:05 PST Message-Id: <4.3.2.7.2.20001120102756.0212d858@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Nov 2000 10:30:06 -0800 To: Thomas Narten From: Bob Hinden Subject: Re: Internet Protocol Version 6 Workshop Cc: DOMAIN-POLICY@LISTS.NETSOL.COM, "vinton g. cerf - ISOC" , ISI IPv6 list <6bone@ISI.EDU>, Internet Architecture Board , IPng List In-Reply-To: <200011201446.JAA01145@hygro.adsl.duke.edu> References: <3A1638FF.F072E677@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just to add that the "Statement on IPv6 Address Privacy" can be found at: http://playground.sun.com/ipng/specs/ipv6-address-privacy.html Bob At 09:46 AM 11/20/2000 -0500, Thomas Narten wrote: >Jeff Williams writes: > > > A little over a year ago, there was some heated debate (I was > > involved) regarding the Privacy concerns with IPv6. Most of this > > is do to two problems. One being the "Autoconfig" for implementation > > specification for IPv6, the other is the "Always On" feature of IPv6. > > The implementation (Autoconfig as default) was and remains that > > biggest problem with respect to Privacy issues. (Autoconfig) should > > not be default was my argument for implementation. I also suggested > > several changes to the Spec for Autoconfig for consideration. But > > the majority of the group felt that being able to track folks easily > > was more important. I found this astounding. > >This characterization of past IPng WG discussions is most definitely >false and at best a gross distortion of past discussions. At no time >that I can recall has the WG ever argued that "tracking folks" is a >desirable goal. It is also completely inconsistent with the WG's >recent decision to recommend that the IESG publish >draft-ietf-ipngwg-addrconf-privacy-03.txt as a Proposed Standard. > >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 Nov 20 10:47:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAKIjgI17666 for ipng-dist; Mon, 20 Nov 2000 10:45:42 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAKIjWj17659 for ; Mon, 20 Nov 2000 10:45:32 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA24535 for ; Mon, 20 Nov 2000 10:45:30 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA26420 for ; Mon, 20 Nov 2000 10:45:28 -0800 (PST) Received: from ValuedSonyCustomer (as1b-234.chi.il.dial.anet.com [198.92.157.234]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id MAA14422; Mon, 20 Nov 2000 12:39:00 -0600 (CST) Message-ID: <0d0b01c05321$47467580$df00a8c0@ValuedSonyCustomer> From: "JIM FLEMING" To: "Thomas Narten" , "Bob Hinden" Cc: , "vinton g. cerf - ISOC" , "ISI IPv6 list" <6bone@ISI.EDU>, "Internet Architecture Board" , "IPng List" References: <3A1638FF.F072E677@ix.netcom.com> <4.3.2.7.2.20001120102756.0212d858@mailhost.iprg.nokia.com> Subject: Re: Internet Protocol Version 6 Workshop Date: Mon, 20 Nov 2000 12:39:53 -0600 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [1] http://www.ripe.net/ripe/mail-archives/ipv6-wg/20000701-20001001/msg00038.ht ml IAB/IESG Recommendations on IPv6 Address Allocations September 1, 2000 ... Examples of obvious choices of host number (IEEE Mac Address, E.164 number, E.214 IMSI, etc) suggest that no assumption should be made that bits may be stolen from that range for subnet numbering; current generation MAC layers and E.164 numbers specify up to 64 bit objects. ... @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ [2] @@@@@ http://www.apnic.net/mailing-lists/apnic-talk/0009/msg00001.html ----- Original Message ----- From: Bob Hinden To: Thomas Narten Cc: ; vinton g. cerf - ISOC ; ISI IPv6 list <6bone@ISI.EDU>; Internet Architecture Board ; IPng List Sent: Monday, November 20, 2000 12:30 PM Subject: Re: Internet Protocol Version 6 Workshop > Just to add that the "Statement on IPv6 Address Privacy" can be found at: > > http://playground.sun.com/ipng/specs/ipv6-address-privacy.html > > Bob > > At 09:46 AM 11/20/2000 -0500, Thomas Narten wrote: > >Jeff Williams writes: > > > > > A little over a year ago, there was some heated debate (I was > > > involved) regarding the Privacy concerns with IPv6. Most of this > > > is do to two problems. One being the "Autoconfig" for implementation > > > specification for IPv6, the other is the "Always On" feature of IPv6. > > > The implementation (Autoconfig as default) was and remains that > > > biggest problem with respect to Privacy issues. (Autoconfig) should > > > not be default was my argument for implementation. I also suggested > > > several changes to the Spec for Autoconfig for consideration. But > > > the majority of the group felt that being able to track folks easily > > > was more important. I found this astounding. > > > >This characterization of past IPng WG discussions is most definitely > >false and at best a gross distortion of past discussions. At no time > >that I can recall has the WG ever argued that "tracking folks" is a > >desirable goal. It is also completely inconsistent with the WG's > >recent decision to recommend that the IESG publish > >draft-ietf-ipngwg-addrconf-privacy-03.txt as a Proposed Standard. > > > >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 Nov 20 14:14:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAKMCZR17947 for ipng-dist; Mon, 20 Nov 2000 14:12:35 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAKMCQj17940 for ; Mon, 20 Nov 2000 14:12:26 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA25835 for ; Mon, 20 Nov 2000 14:12:26 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14832 for ; Mon, 20 Nov 2000 14:12:25 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id OAA62436; Mon, 20 Nov 2000 14:09:56 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA15954; Mon, 20 Nov 2000 14:12:22 -0800 Message-ID: <3A199D9D.34399FA9@hursley.ibm.com> Date: Mon, 20 Nov 2000 15:54:37 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: Metzler Jochen , "'Francis Dupont'" , "Hesham Soliman (EPA)" , "Ipng (E-Mail)" Subject: Re: AW: Usage of IPv6 flow label References: <20001116211416.329F47EF9@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino wrote: > > >As far as I know neither diffserv nor intserv/RSVP know anything > >about the flow label field. > > RSVP has a reference to flow label, in RFC2205 section A.9. Wow. So it does, in defining the possible fields for a FilterSpec. That still doesn't help us use it though. Incidentally there is a bug in RFC 2205 - it still has the flow label 24 bits long, instead of 20. 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 Nov 20 14:33:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAKMWCn18006 for ipng-dist; Mon, 20 Nov 2000 14:32:12 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAKMW3j17999 for ; Mon, 20 Nov 2000 14:32:03 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA23216 for ; Mon, 20 Nov 2000 14:32:02 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA15476 for ; Mon, 20 Nov 2000 14:32:02 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id OAA129724; Mon, 20 Nov 2000 14:29:33 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA15968; Mon, 20 Nov 2000 14:32:00 -0800 Message-ID: <3A19A212.D96A8720@hursley.ibm.com> Date: Mon, 20 Nov 2000 16:13:38 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <20001115190919.321B17EF9@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino wrote: ... > flow label field is not part of AH calculation, but as RSVP already > requires it to be end-to-end (not hop-by-hop) i think we shouldn't > rewrite it in transit. Only if you choose to specify it as part of a Filter Spec. I don't think this is a convincing argument. 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 Nov 20 14:51:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAKMnKp18086 for ipng-dist; Mon, 20 Nov 2000 14:49:21 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAKMn1j18071 for ; Mon, 20 Nov 2000 14:49:01 -0800 (PST) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id eAKMn0B898561; Mon, 20 Nov 2000 14:49:00 -0800 (PST) Date: Mon, 20 Nov 2000 11:48:58 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPV6_USEMTU socket option To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , 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 > We might have to clarify what happens if the application disables > fragmentation, but sends a larger packet than the MTU of the outgoing > interface. For example, just return an EMSGSIZE error, return an > IPV6_PATHMTU ancillary data item (if the application sets > IPV6_RECVPATHMTU beforehand), or both... I'll add this. > > struct ip6_mtuinfo { > > struct sockaddr_in6 ip6m_addr; /* dst IPv6 address including scope > > */ > > unsigned int ip6m_mtu; /* path MTU in host byte order */ > > Is "unsigned int" appropriate here (I'm just wondering, not sure on > this)? What would you like to see instead? uint32_t? uint16_t? > This cmsghdr will be passed to every socket that sets the > IPV6_RECVPATHMTU socket option, even if the socket is > non-connected. Note that this also means an application that sets > the option may get the ancillary data upon a too big message sent > from other applications to the same destination. An implementation > may skip to deliver the data to sockets that connect a different > foreign address from the destination address of the corresponding > ip6_mtuinfo strucutre. I'll add the above. THanks for the text. > This is based on the behavior of our implementation, but I don't stick > to minor details (e.g. the last sentence). > > > XXX What about more complex paths e.g. when using a routing header? > > How about the following text? > > When an application sends packet with a routing header, the final > destination stored in the ip6m_addr member does not necessarily > contain complete information of the entire path. Thus, an > implementation may append an additional data structure after > ip6_mtuinfo to tell the application precise information of the > entire path. This definition of the additinaol structure is beyond > the scope of this document. I can add this unless somebody has any concerns about essentially making this implementation specific. 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 Nov 20 14:51:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAKMnNe18087 for ipng-dist; Mon, 20 Nov 2000 14:49:23 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAKMn4j18079 for ; Mon, 20 Nov 2000 14:49:04 -0800 (PST) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id eAKMn1B898574; Mon, 20 Nov 2000 14:49:01 -0800 (PST) Date: Mon, 20 Nov 2000 11:53:48 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPV6_USEMTU socket option To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , 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 have one more question about the option. What if the size of an > outgoing packet is larger than the MTU of the outgoing interface on > the sending node, when the application set the IPV6_RECVPATHMTU > option? Should the kerenl pass the IPV6_PATHMTU ancillary data with > the MTU of the outgoing interface? My assumption was that it would send up an IPV6_PATHMTU and also fragment and send the packet. Erik > (BTW, our current implementation does not pass the ancillary data on > the sending node. In such a case, it just fragment the packet using > the MTU of the outgoing interface.) > > 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 Nov 20 14:56:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAKMtVt18150 for ipng-dist; Mon, 20 Nov 2000 14:55:31 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAKMtLj18143 for ; Mon, 20 Nov 2000 14:55:22 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA08483 for ; Mon, 20 Nov 2000 14:55:21 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29354 for ; Mon, 20 Nov 2000 14:55:19 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id OAA120620; Mon, 20 Nov 2000 14:52:50 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA27456; Mon, 20 Nov 2000 14:55:17 -0800 Message-ID: <3A19A76B.3DA48095@hursley.ibm.com> Date: Mon, 20 Nov 2000 16:36:27 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Alex Conta CC: Steve Deering , Michael Thomas , Francis Dupont , Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <20001115190919.321B17EF9@starfruit.itojun.org> <200011160958.KAA90047@givry.rennes.enst-bretagne.fr> <14867.59850.899996.178063@thomasm-u1.cisco.com> <3A142DEE.AA44B45F@txc.com> <3A1584F1.79185912@txc.com> <3A15B6B2.D29AAED@txc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, Alex Conta wrote: > > Since the IPv6 flow label work started, two major efforts in IETF made > significant progress on related topics: Diffserv and MPLS. Steve's already said this but I want to say it again: no! The Flow Label is totally orthogonal to diffserv, which has no need of it, since it has its own mutable 6-bit field (more than enough). The Flow Label is totally orthogonal to the MPLS Shim, which is at a lower layer and is edge-to-edge, not end-to-end. As has been observed, the Flow Label is accommodated neatly by the IntServ model. 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 Nov 20 14:57:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAKMuig18165 for ipng-dist; Mon, 20 Nov 2000 14:56:44 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAKMuRj18156 for ; Mon, 20 Nov 2000 14:56:28 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA20702 for ; Mon, 20 Nov 2000 14:56:23 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29922 for ; Mon, 20 Nov 2000 14:56:22 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id OAA38976; Mon, 20 Nov 2000 14:53:53 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA15980; Mon, 20 Nov 2000 14:56:21 -0800 Message-ID: <3A19A7A9.FD30FE91@hursley.ibm.com> Date: Mon, 20 Nov 2000 16:37:29 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Hesham Soliman (EPA)" CC: "'Michael Thomas'" , "'Ipng (E-Mail) '" Subject: Re: Usage of IPv6 flow label References: <4B6BC00CD15FD2119E5F0008C7A419A50C613E0F@eaubrnt018.epa.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham, Please tell us who in 3GPP to ask about this. Thanks Brian "Hesham Soliman (EPA)" wrote: > > > Hesham Soliman (EPA) writes: > > > > > Er, by what protocol does it inform the router? > > > > > > > > > => A 3GPP protocol. > > > > > > Which is different from an IETF protocol? > > > > > > => Yes. Otherwise it would not be a 3GPP protocol ;) > > > > Is there some compelling reason why RSVP is not > > that protocol, or is this yet another case of > > the parochial "our layer 2 is _so_ different we > > can't possibly use widely accepted and standards > > based protocols." > > > => You have to ask someone from 3GPP who worked > on that protocol. There are some reasons for their > chioces, whether you agree with it or not it's a different > story. You can get more detail if you ask the people > who invented these protocols. Anyway this is getting > outside this mailing list's interest. > > Hesham > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.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 Mon Nov 20 15:28:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAKNQkB18279 for ipng-dist; Mon, 20 Nov 2000 15:26:46 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAKNQcj18272 for ; Mon, 20 Nov 2000 15:26:38 -0800 (PST) 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,v1.7) with ESMTP id PAA28132 for ; Mon, 20 Nov 2000 15:26:38 -0800 (PST) Received: from onoe2.sm.sony.co.jp (onoe2.sm.sony.co.jp [133.138.10.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02334 for ; Mon, 20 Nov 2000 15:26:36 -0800 (PST) Received: from duplo.sm.sony.co.jp (onoe@localhost) by onoe2.sm.sony.co.jp (8.9.0/3.7W) with ESMTP id IAA18427; Tue, 21 Nov 2000 08:26:34 +0900 (JST) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.11.1/8.10.2) id eAKNQSW01266; Tue, 21 Nov 2000 08:26:28 +0900 (JST) Date: Tue, 21 Nov 2000 08:26:28 +0900 (JST) From: Atsushi Onoe Message-Id: <200011202326.eAKNQSW01266@duplo.sm.sony.co.jp> To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipngwg-1394-00.txt In-Reply-To: Your message of "Wed, 15 Nov 2000 06:40:09 -0500" <200011151140.GAA00642@ietf.org> References: <200011151140.GAA00642@ietf.org> X-Mailer: Cue version 0.6 (000830-2124/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We submitted the new WG draft recently. This is updated draft for draft-fujisawa-ip1394-ipv6-04.txt, which I presented at last IETF. Changes from the previous version are: - make IPng working group draft - remove "Open Issues" - add "Security Considerations" - add "IANA Considerations" - some editorial fixes Since there are no significant issues noticed for the previous version, we think it's ready to request WG last call for Proposed Standard. Note that there are two (possibly not independent, though) interoperable implementations. One is Sony's proprietery implementation on FreeBSD/KAME which passed interoperability test event for IEEE1394 over IPv4 at the ip1394 WG. The other was recently introduced to NetBSD current by me. NetBSD current still lacks of the IRM capability, which is mandatory to share a bus among IPv4/IPv6 and Digital Vidio, etc. But the requirement for IRM capability is exactly same between IPv4 and IPv6, so we are sure that there are no interoperability issues. Regards, Atsushi Onoe > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPNG Working Group of the IETF. > > Title : Transmission of IPv6 Packets over IEEE 1394 Networks > Author(s) : K. Fujisawa, A. Onoe > Filename : draft-ietf-ipngwg-1394-00.txt > Pages : 7 > Date : 14-Nov-00 > > IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. > This document describes the frame format for transmission of IPv6 > [IPV6] packets and the method of forming IPv6 link-local addresses > and statelessly autoconfigured addresses on IEEE1394 networks. > It also describes the content of the Source/Target Link-layer Address > option used in Neighbor Discovery [DISC] when the messages are > transmitted on an IEEE1394 network. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 20 16:22:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAL0KCN18313 for ipng-dist; Mon, 20 Nov 2000 16:20:12 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAL0Jwj18306 for ; Mon, 20 Nov 2000 16:19:58 -0800 (PST) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id eAL0JnB919240; Mon, 20 Nov 2000 16:19:50 -0800 (PST) Date: Mon, 20 Nov 2000 16:19:41 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU To: Francis Dupont Cc: Tim Hartrick , itojun@iijlab.net, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200011171614.RAA97968@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > PS: I've tried one day the 2*64 definition on a Sparc (ie. with 64 bit > alignment). It didn't work because of some details, for instance the > route structure (pointer + sockaddr) or IPv6 over ATM (32 bit difference > in alignment between unicast and multicast). I can't see a good reason > to add a new source of problems... We tried the same thing a while back (thinking it would be trivial). Turned out that the embedded in6_addr structures in various places (ancillary data which gets mapping into TPI option buffers, socket options, etc) made the introduction of 64 bit alignment non-trivial. So we punted for the time being. 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 Nov 20 18:53:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAL2pPr18439 for ipng-dist; Mon, 20 Nov 2000 18:51:25 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAL2p9j18432 for ; Mon, 20 Nov 2000 18:51:10 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA06065 for ; Mon, 20 Nov 2000 18:51:03 -0800 (PST) Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23816 for ; Mon, 20 Nov 2000 18:51:01 -0800 (PST) Received: from ix.netcom.com (user-2inic7l.dialup.mindspring.com [165.121.48.245]) by mclean.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id VAA29260; Mon, 20 Nov 2000 21:50:50 -0500 (EST) Message-ID: <3A1A02D3.58EF7E4D@ix.netcom.com> Date: Mon, 20 Nov 2000 21:06:27 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Thomas Narten CC: JIM FLEMING , DOMAIN-POLICY@LISTS.NETSOL.COM, frezza@alum.mit.edu, "vinton g. cerf - ISOC" , ISI IPv6 list <6bone@ISI.EDU>, Internet Architecture Board , IPng List Subject: Re: Internet Protocol Version 6 Workshop References: <200011201446.JAA01145@hygro.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas and all, I am sorry I must respectfully disagree with you here Thomas. I specifically had a running debate with two members of the Ipng list members discussing this issue. Thomas Narten wrote: > Jeff Williams writes: > > > A little over a year ago, there was some heated debate (I was > > involved) regarding the Privacy concerns with IPv6. Most of this > > is do to two problems. One being the "Autoconfig" for implementation > > specification for IPv6, the other is the "Always On" feature of IPv6. > > The implementation (Autoconfig as default) was and remains that > > biggest problem with respect to Privacy issues. (Autoconfig) should > > not be default was my argument for implementation. I also suggested > > several changes to the Spec for Autoconfig for consideration. But > > the majority of the group felt that being able to track folks easily > > was more important. I found this astounding. > > This characterization of past IPng WG discussions is most definitely > false and at best a gross distortion of past discussions. At no time > that I can recall has the WG ever argued that "tracking folks" is a > desirable goal. It is also completely inconsistent with the WG's > recent decision to recommend that the IESG publish > draft-ietf-ipngwg-addrconf-privacy-03.txt as a Proposed Standard. > > Thomas Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 112k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1800 x1894 or 9236 fwd's to home ph# Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 20 20:11:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAL4A3B18502 for ipng-dist; Mon, 20 Nov 2000 20:10:03 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAL49qj18495 for ; Mon, 20 Nov 2000 20:09:52 -0800 (PST) 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,v1.7) with ESMTP id UAA07189 for ; Mon, 20 Nov 2000 20:09:51 -0800 (PST) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA21740 for ; Mon, 20 Nov 2000 21:09:50 -0700 (MST) Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14]) by east.isi.edu (8.9.2/8.9.2) with SMTP id XAA09321; Mon, 20 Nov 2000 23:10:01 -0500 (EST) Posted-Date: Mon, 20 Nov 2000 23:13:34 -0500 Message-Id: <10011210413.AA18840@maia.east.isi.edu> Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6) id ; Mon, 20 Nov 00 23:13:35 EST To: narten@raleigh.ibm.com, richdr@microsoft.com Cc: ipng@sunroof.eng.sun.com Subject: Comments on the Privacy Extensions draft Reply-To: mankin@east.isi.edu Date: Mon, 20 Nov 2000 23:13:34 -0500 From: Allison Mankin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [These are comments that were sent to the authors at the end of the IETF Last Call. A new rev soon to appear will reflect these comments and since they were extensive, it was deemed useful for the WG to see them] I reviewed draft-ietf-ipngwg-addconf-privacy-03.txt carefully and I have a number of small and larger comments. I found the draft to be strong (parts of it very strong) but I thought it could use a new thorough review. There is a pressing need for this spec so I strongly support its publication when these comments have been addressed. In addition to this draft getting published as a standard, I'd like to urge that work be done on the API for use of the privacy extensions. Allison ------------------ Typo ---- Sec 3.5 applications are used by end users. Thus the default value given of one week (ANON_PREFERRED_LIFETIME) may not be appropriate in all environments. Implementations should provide end users with the ability to override both of these default values. s/ANON_PREFERRED_LIFETIME/ANON_VALID_LIFETIME Detailed comments ----------------- Sec 1 By design, the interface identifier is globally unique when generated in this fashion. The interface identifier is in turn appended to a prefix to form a 128-bit IPv6 address. Since RFC2462 doesn't allow counting on the EUI-64 interface id being unique even on the link (MUST do DAD on the generated link-local address) this bit of intro is too strong. A more accurate wording would be: "There is an expectation that the interface identifier generated in this way will be globally unique, and that this might be a valuable property for future approaches to hierarchical routing, as explained in [ADDRARCH]." Or more simply: s/is globally unique/is likely to be globally unique/ described may also apply to interfaces with other types of globally unique and persistent identifiers. This is good, but should say "globally unique and/or persistent" This document discusses concerns associated with the embedding of non-changing interface identifiers within IPv6 addresses and describes extensions to stateless address autoconfiguration that can help mitigate those concerns in environments where such concerns are significant. Nit: the last phrase sounds like a diminution of likelihood of such concerns existing. An alternative phrasing that implies a bit more concern for privacy: "help mitigate those concerns for individual users and in environments where such concerns are significant" Sec 2.1 serves as a similar identifier. Although the DNS name associated with an address is more work to obtain (it may require a DNS query) the information is often readily available. In such cases, changing the address on a machine over time would do little to address the concern raised in this document, as the DNS name would become the correlating identifier. Instead of the "would do little..." final sentence, which suggests that anonymous addresses are defeated by inverse DNS, this paragraph should send with a sentence like "In such cases, nodes using anonymous addresses might also use some form of anonymous DNS names (see Section 4)". Sec 2.2 Sec 2.2's first paragraph begs for a comparison with the Intel PIII serial number. It seems to me that it would be best to be up-front about the problems being comparable. Sec 2.2 (cont) Many network services require that the client authenticate itself to the server before gaining access to a resource. The authentication step binds the activity (e.g., TCP connection) to a specific entity (e.g., an end user). In such cases, a server already has the ability to track usage by an individual, independent of the address they happen to use. Indeed, such tracking is an important part of accounting. This paragraph undercuts the whole purpose of the draft and ought to be rewritten. Sec 2.2 in fact sends an undercutting message: becasue identification and tracking goes on, therefore don't worry about your IP addresses being trackable. A better message from the section (and one more appropriate to the draft) would be: don't undermine higher level technologies for improving the privacy of applications by leaving every packet trackable at low level. Examples of attempts to improve privacy at higher level that could be undercut by trackable packets: 1. varying one's registrations at a web-based service 2. rejecting persistent cookies and only allowing session cookies It is possible to avoid persistent higher level identifiers. People create changing or multiple identities per site or for different sites. Even sites where registration is an email address can be given varied inputs by using multiple free email accounts. Credit card registration is the subject of a US mandate to go to one-time credit card numbers. However, all of these kinds of anonymizing are undermined by having a trackable IP address. Sec 2.3 In such environments, one may need multiple addresses: a "public" (i.e., non-secret) server address, registered in the DNS, that is used to accept incoming connection requests from other machines, and (possibly) an "anonymous" address used to shield the identity of the Nit: sentence already has "may," so why add further distance with the "(possibly)"? To make it difficult to make educated guesses as to whether two different interface identifiers belong to the same node, the algorithm for generating alternate identifiers must include input that has an unpredictable component from the perspective of the outside entities that are collecting information. Picking identifiers from a pseudo-random sequence suffices, so long as the specific sequence cannot be determined by an outsider examining just the identifiers that appear in addresses or are otherwise readily available (e.g., a node's link-layer address). It's bad news if the node's link-layer address is "readily available" to arbitrary remote peers - the last parenthesis doesn't make sense in this draft about not embedding link-layer addresses in packet addresses.... Sec 3.1 The algorithm also assumes that for a given anonymous address, one can determine the corresponding public address. Who does "one" refer to? I think this sentence must intend to say "The algorithm also assumes that there is an internal data structure available to address autoconfiguration matching a given anonymous address to its corresponding public address", but it can be read as saying there's an algorithmic conversion from the anonymous back to the public. Finally, this document assumes that when a node initiates outgoing communication, anonymous addresses can be given preference over other public addresses. Delete "other". This can mean that all outgoing connections use anonymous addresses by default, or that applications individually indicate whether they prefer to use anonymous or public addresses. Replace "outgoing connections" with "connections initiated by the node". Mention somewhere that applications indicating their preference for an anonymous address is one example of API work that is needed in conjunction with this spec. Sec 3.2 a randomized interface identifier may need to be generated at random. Repetitive. s/at random/without previous state/ Sec 3.5 This can be achieved automatically by generating a new randomized interface identifier at least once every (ANON_PREFERRED_LIFETIME - REGEN_ADVANCE) time units. As described above, generating a new anonymous address REGEN_ADVANCE time units before an anonymous address becomes deprecated produces addresses with a preferred lifetime no larger than ANON_PREFERRED_LIFETIME. I think this should have the same mechanism of desynchronizing the nodes that RFC2461 has, because nodes that start up after a power failure could have their new randomized interface timers synch up and cause a daily DAD flood. Sec 4 The IPv6 addressing architecture goes to great lengths to ensure that interface identifiers are globally unique. s/great lengths/some lengths/ s/are globally unique/may be globally unique/ The sentence is too strong, compared with the address architecture RFC (even the new i-d). And as before, saying the EUI-64's are surely globally unique is contradicted by Addrconf requiring DAD on them. During the IPng discussions of the GSE proposal [GSE], it was felt that keeping interface identifiers globally unique in practice might prove useful to future transport protocols. Usage of the algorithms in this document would eliminate that future flexibility. I disagree that the anonymous addresses would eliminate a GSE-like future scheme, any more than using any addresses where the u/l bit is unset is doing so already. There are other ways that a GSE-like future scheme might be work, for instance, using global interface ids as input to a cryptographic registry that would return an anonymized interface id to use in the address. Wording suggestion: s/eliminate that future flexibility/possibly complicate that future flexibility/ DNS name (if non-changing) serves as a constant identifier. If the extension described in this document becomes widely deployed, servers will likely need to change their behavior to not require every address be in the DNS. Another alternative is to register anonymous addresses in DNS using random names (for example a string version of the address itself). Sweeping changes to server behavior are unlikely/hard to drive. The prospect of anonymized DNS names (as mentioned next) is better. Perhaps change the last two sentences to be both more realistic and more constructive: The wide deployment of the extension described in this document could challenge the practice of inverse-DNS-based "authentication," which is has little validity, though it is widely implemented. In order to meet server challenges, nodes could register anonymous addresses in DNS using random names (for example a string version of the random address itself). Sec 6 Use of the extensions defined in this document is likely to make debugging and other operational troubleshooting activities more difficult. Not certain - when the troubleshooting regards nodes that are in LAN segments controlled by an administrator, it should be possible to register and identify nodes by their layer 2 addresses (RMON can give access to that sort of trace). If the troubleshooting regards distant nodes, it's already the case that the addresses won't give much help (e.g. in DDos). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 20 20:42:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAL4f0718534 for ipng-dist; Mon, 20 Nov 2000 20:41:01 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAL4epj18527 for ; Mon, 20 Nov 2000 20:40:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA24395 for ; Mon, 20 Nov 2000 20:40:50 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17021 for ; Mon, 20 Nov 2000 20:40:50 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id B5D86B9B9; Mon, 20 Nov 2000 23:40:39 -0500 (EST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 53853B664; Mon, 20 Nov 2000 23:34:03 -0500 (EST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id XAA0000561591; Mon, 20 Nov 2000 23:33:42 -0500 (EST) From: Jim Bound Message-Id: <200011210433.XAA0000561591@anw.zk3.dec.com> To: Alex Conta Cc: Thomas Narten , Metzler Jochen , "Ipng (E-Mail)" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Thu, 16 Nov 2000 14:23:15 EST." <3A143423.1ED00F6A@txc.com> Date: Mon, 20 Nov 2000 23:33:41 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, RSVP uses the flow label in IPv6. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 20 21:20:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAL5IvW18574 for ipng-dist; Mon, 20 Nov 2000 21:18:57 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAL5Imj18567 for ; Mon, 20 Nov 2000 21:18:48 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA18663; Mon, 20 Nov 2000 21:18:40 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA25159; Mon, 20 Nov 2000 21:18:38 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id OAA28205; Tue, 21 Nov 2000 14:04:54 +0900 (JST) Date: Tue, 21 Nov 2000 14:18:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option In-Reply-To: In your message of "Mon, 20 Nov 2000 11:48:58 -0800 (PST)" References: User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 21 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 20 Nov 2000 11:48:58 -0800 (PST), >>>>> Erik Nordmark said: >> > struct ip6_mtuinfo { >> > struct sockaddr_in6 ip6m_addr; /* dst IPv6 address including scope >> > */ >> > unsigned int ip6m_mtu; /* path MTU in host byte order */ >> >> Is "unsigned int" appropriate here (I'm just wondering, not sure on >> this)? > What would you like to see instead? > uint32_t? uint16_t? I would (personally) like uint32_t, because icmp6_hdr.icmp6_mtu has the same type. 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 Nov 20 21:20:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAL5JCi18583 for ipng-dist; Mon, 20 Nov 2000 21:19:12 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAL5Ixj18576 for ; Mon, 20 Nov 2000 21:19:00 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA12841 for ; Mon, 20 Nov 2000 21:18:58 -0800 (PST) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA07542 for ; Mon, 20 Nov 2000 21:18:58 -0800 (PST) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id 881E02DE0; Mon, 20 Nov 2000 23:18:57 -0600 (CST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 5317B2C47; Mon, 20 Nov 2000 23:18:56 -0600 (CST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id AAA0000564672; Tue, 21 Nov 2000 00:18:16 -0500 (EST) From: Jim Bound Message-Id: <200011210518.AAA0000564672@anw.zk3.dec.com> To: Alex Conta Cc: Steve Deering , Michael Thomas , Francis Dupont , Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Fri, 17 Nov 2000 17:52:34 EST." <3A15B6B2.D29AAED@txc.com> Date: Tue, 21 Nov 2000 00:18:15 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk the flow label should be guranteed e-2-e. clients should set it. routers should leave it alone. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 20 21:31:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAL5Tkd18634 for ipng-dist; Mon, 20 Nov 2000 21:29:46 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAL5Taj18627 for ; Mon, 20 Nov 2000 21:29:37 -0800 (PST) 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,v1.7) with ESMTP id VAA13955 for ; Mon, 20 Nov 2000 21:29:35 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA28581 for ; Mon, 20 Nov 2000 22:29:35 -0700 (MST) Received: from ValuedSonyCustomer (as1b-234.chi.il.dial.anet.com [198.92.157.234]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id XAA08728; Mon, 20 Nov 2000 23:19:56 -0600 (CST) Message-ID: <066501c0537a$d943f940$df00a8c0@ValuedSonyCustomer> From: "JIM FLEMING" To: "Jim Bound" , "Alex Conta" Cc: "Steve Deering" , "Michael Thomas" , "Francis Dupont" , "Jun-ichiro itojun Hagino" , "Hesham Soliman (EPA)" , "Metzler Jochen" , "Ipng (E-Mail)" , References: <200011210518.AAA0000564672@anw.zk3.dec.com> Subject: Re: Usage of IPv6 flow label Date: Mon, 20 Nov 2000 23:21:02 -0600 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In my opinion, the IPv4 TOS should also be "e-2-e"... ...clients should set it....routers should leave it alone.... Jim Fleming http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp ----- Original Message ----- From: Jim Bound To: Alex Conta Cc: Steve Deering ; Michael Thomas ; Francis Dupont ; Jun-ichiro itojun Hagino ; Hesham Soliman (EPA) ; Metzler Jochen ; Ipng (E-Mail) ; Sent: Monday, November 20, 2000 11:18 PM Subject: Re: Usage of IPv6 flow label > the flow label should be guranteed e-2-e. clients should set it. > routers should leave it alone. > > /jim > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 20 21:32:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAL5VKq18646 for ipng-dist; Mon, 20 Nov 2000 21:31:20 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAL5V4j18637 for ; Mon, 20 Nov 2000 21:31:04 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA14096 for ; Mon, 20 Nov 2000 21:31:03 -0800 (PST) Received: from zcamail01.zca.compaq.com (zcamail01.zca.compaq.com [161.114.32.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA11797 for ; Mon, 20 Nov 2000 21:31:02 -0800 (PST) Received: by zcamail01.zca.compaq.com (Postfix, from userid 12345) id 7FA6C1498; Mon, 20 Nov 2000 21:32:16 -0800 (PST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zcamail01.zca.compaq.com (Postfix) with ESMTP id 64B5D14E7; Mon, 20 Nov 2000 21:32:15 -0800 (PST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id AAA0000565660; Tue, 21 Nov 2000 00:30:48 -0500 (EST) From: Jim Bound Message-Id: <200011210530.AAA0000565660@anw.zk3.dec.com> To: Cc: "'Alex Conta'" , "'Steve Deering'" , "'Michael Thomas'" , "'Francis Dupont'" , "'Jun-ichiro itojun Hagino'" , "'Hesham Soliman (EPA)'" , "'Metzler Jochen'" , "'Ipng (E-Mail)'" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Sun, 19 Nov 2000 16:33:49 +0100." <31A473DBB655D21180850008C71E251A02949278@mail.kebne.se> Date: Tue, 21 Nov 2000 00:30:48 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >And I also think that IPv6 should "borrow the mechanisms". An I would like >to see a combine model for use of the flow-label where the "intserv"/per >flow model would exist in the access and that a aggregated/"differv"/"mpls" >like model with possibility to re-write the flow label would exist... The only way I for one would support what your saying is if we also defined the first bit of the flowlabel to denote it can be rewritable. That first bit set or not is decided by the client or the clients network (meaning a zone within which the client exists authoritatively). If this bit is set then any e-2-e predications are lost and users would need to understand that. The other option is to use the traffic class bits. But I also think the flowlabel can be used when defined by the client and set by the client to assist greatly the evolution of the ECN model and help with increasing bandwidth efficiency with TCP to notify a client with a fast path for the search to find the clients entry in the table. So I will argue what the router folks have done with MPLS will need to be done by those wanting faster searches for congestion and lost packets with TCP. Steve's position is par excellence and I would like to see your response to Steve as Alex has? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 20 22:07:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAL66Od18701 for ipng-dist; Mon, 20 Nov 2000 22:06:24 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAL66Fj18694 for ; Mon, 20 Nov 2000 22:06:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA17292 for ; Mon, 20 Nov 2000 22:06:13 -0800 (PST) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA22166 for ; Mon, 20 Nov 2000 22:06:12 -0800 (PST) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id EC3251CED; Tue, 21 Nov 2000 00:05:52 -0600 (CST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 3A18D1EEB; Tue, 21 Nov 2000 00:05:51 -0600 (CST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id BAA0000568203; Tue, 21 Nov 2000 01:04:05 -0500 (EST) From: Jim Bound Message-Id: <200011210604.BAA0000568203@anw.zk3.dec.com> To: Brian E Carpenter Cc: Jun-ichiro itojun Hagino , Metzler Jochen , "'Francis Dupont'" , "Hesham Soliman (EPA)" , "Ipng (E-Mail)" , bound@zk3.dec.com Subject: Re: AW: Usage of IPv6 flow label In-reply-to: Your message of "Mon, 20 Nov 2000 15:54:37 CST." <3A199D9D.34399FA9@hursley.ibm.com> Date: Tue, 21 Nov 2000 01:04:04 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk brian, what is very cool in our implementation is we don't need the filter spec just the flow spec. also no having to look in the packet for ipv6, and its part of the sockaddr_in6, and it works with our OTB IPv6 base api. I would like to encourage all vendors to show up at Sun connectathon with an IPv6 RSVP implementation to test. The stuff works. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 20 22:56:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAL6tUa18753 for ipng-dist; Mon, 20 Nov 2000 22:55:30 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAL6tLj18746 for ; Mon, 20 Nov 2000 22:55:21 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA00706 for ; Mon, 20 Nov 2000 22:55:22 -0800 (PST) Received: from mail1.beijingnet.com ([202.136.254.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA15592 for ; Mon, 20 Nov 2000 22:55:19 -0800 (PST) Received: from hmobile ([210.76.98.252]) by mail1.beijingnet.com (8.8.8+2.7Wbeta7/3.6W) with SMTP id PAA02234 for ; Tue, 21 Nov 2000 15:03:15 +0800 (CST) Message-ID: <00fd01c05389$12ae6d60$fc624cd2@hmobile> From: "huaning\(bii\)" To: Subject: Re: Sample config for cisco routers Date: Tue, 21 Nov 2000 15:02:52 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id eAL6tMj18747 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi , all . This is a sample config on my Cisco router (7507), including Tunnel , BGP+ , IPv6 Addr. I would be very happy if it can make any help. ! version 12.0 no service pad service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname 7507B ! boot system flash:rsp-pv-mz.19991126 enable secret 5 $1$TG5.$kdmpBGQVLdebrKWwDJi./0 ! username 7507A password 7 104D000A061843 ! ! ! ! ip subnet-zero ip cef ip name-server 202.112.10.37 ! ipv6 unicast-routing ! ! interface Tunnel100 description tunnel100 7507B g0/0/0 no ip address no ip directed-broadcast ipv6 enable ipv6 address 3FFE:510:0:FFFF::4/127 tunnel source GigabitEthernet0/0/0 tunnel destination 203.128.134.1 tunnel mode ipv6ip ! interface Tunnel101 description tunnel101 no ip address no ip directed-broadcast ipv6 enable ipv6 address 3FFE:510:FFFF::1/126 tunnel source GigabitEthernet0/0/0 tunnel destination 203.178.140.204 tunnel mode ipv6ip ! interface Tunnel1010 no ip address no ip directed-broadcast ! interface GigabitEthernet0/0/0 ip address 202.204.22.193 255.255.255.192 no ip directed-broadcast no ip route-cache distributed no ip mroute-cache load-interval 30 negotiation auto ipv6 enable ipv6 address 3FFE:510:1::/64 ! interface GigabitEthernet1/0/0 no ip address no ip directed-broadcast no ip route-cache distributed no ip mroute-cache load-interval 30 shutdown negotiation auto ! interface FastEthernet4/0/0 ip address 202.112.42.90 255.255.255.252 no ip directed-broadcast no ip route-cache distributed no ip mroute-cache half-duplex ! interface Serial4/1/0 no ip address no ip directed-broadcast encapsulation frame-relay no ip route-cache distributed no ip mroute-cache no keepalive no fair-queue no arp frame-relay ! interface Serial4/1/0.16 point-to-point ip address 203.128.132.2 255.255.255.252 no ip directed-broadcast no ip mroute-cache no arp frame-relay frame-relay interface-dlci 16 ! interface Serial4/1/1 no ip address no ip directed-broadcast no ip route-cache distributed no ip mroute-cache shutdown ! interface Serial4/1/2 no ip address no ip directed-broadcast no ip route-cache distributed no ip mroute-cache shutdown ! interface Serial4/1/3 no ip address no ip directed-broadcast no ip route-cache distributed no ip mroute-cache shutdown ! router bgp 10109 neighbor 3FFE:510:FFFF::2 remote-as 2500 no neighbor 3FFE:510:FFFF::2 activate ! address-family ipv6 neighbor 3FFE:510:FFFF::2 activate neighbor 3FFE:510:FFFF::2 prefix-list bii-in in neighbor 3FFE:510:FFFF::2 prefix-list bii-filter1 out network 3FFE:510:1::/64 aggregate-address 3FFE:510::/32 summary-only exit-address-family ! ip classless ip route 0.0.0.0 0.0.0.0 202.112.42.89 ip route 203.128.128.0 255.255.224.0 203.128.132.1 no ip http server ! ! ! line con 0 exec-timeout 0 0 password 7 07032458430C100B47 login transport input none line aux 0 line vty 0 5 exec-timeout 0 0 password 7 011F0310560E0F0172 login ! end _________________________________________________ Hua Ning BII Group Holdings Ltd, 11F China Merchants Tower, No.2 Dong Huan Nan Lu, Chao Yang District, Beijing,China Zip Code: 100022 Tel:+86-10-65660290-223 Fax:+86-10-65660297 _________________________________________________ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 08:29:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eALGRR419045 for ipng-dist; Tue, 21 Nov 2000 08:27:27 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eALGRHj19038 for ; Tue, 21 Nov 2000 08:27:17 -0800 (PST) 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,v1.7) with ESMTP id IAA17276 for ; Tue, 21 Nov 2000 08:27:16 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08411 for ; Tue, 21 Nov 2000 09:27:13 -0700 (MST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id XC97BGBK; Tue, 21 Nov 2000 17:27:16 +0100 Reply-To: From: "Thomas Eklund" To: "'JIM FLEMING'" , "'Jim Bound'" , "'Alex Conta'" Cc: "'Steve Deering'" , "'Michael Thomas'" , "'Francis Dupont'" , "'Jun-ichiro itojun Hagino'" , "'Hesham Soliman \(EPA\)'" , "'Metzler Jochen'" , "'Ipng \(E-Mail\)'" , Subject: RE: Usage of IPv6 flow label Date: Tue, 21 Nov 2000 17:27:04 +0100 Message-ID: <31A473DBB655D21180850008C71E251A02949289@mail.kebne.se> 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) In-Reply-To: <31A473DBB655D21180850008C71E251A02F3C8B3@mail.kebne.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In my opinion, the IPv4 TOS should also be "e-2-e"... > ...clients should set it....routers should leave it alone.... IPv4 ToS or IPv6 Traffic Class field is 8 bits and today most routers use 6 bits for them for diffserv (DSCP) and then it is per defintion PER hop behaviour and having possibility to re-write it at ingrees/egress router to your domain .. -- 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 Nov 21 08:29:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eALGRxX19054 for ipng-dist; Tue, 21 Nov 2000 08:27:59 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eALGRmj19047 for ; Tue, 21 Nov 2000 08:27:48 -0800 (PST) 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,v1.7) with ESMTP id IAA03214 for ; Tue, 21 Nov 2000 08:27:47 -0800 (PST) Received: from zcamail01.zca.compaq.com (zcamail01.zca.compaq.com [161.114.32.101]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16714 for ; Tue, 21 Nov 2000 08:27:47 -0800 (PST) Received: by zcamail01.zca.compaq.com (Postfix, from userid 12345) id B1F531668; Tue, 21 Nov 2000 08:29:01 -0800 (PST) Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4]) by zcamail01.zca.compaq.com (Postfix) with ESMTP id 5442615B1 for ; Tue, 21 Nov 2000 08:29:01 -0800 (PST) Received: by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id LAA0001183221; Tue, 21 Nov 2000 11:27:37 -0500 (EST) Date: Tue, 21 Nov 2000 11:27:37 -0500 (EST) From: Jack McCann Message-Id: <200011211627.LAA0001183221@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> > struct ip6_mtuinfo { >> > struct sockaddr_in6 ip6m_addr; /* dst IPv6 address including scope */ >> > unsigned int ip6m_mtu; /* path MTU in host byte order */ >> >> Is "unsigned int" appropriate here (I'm just wondering, not sure on >> this)? > >What would you like to see instead? >uint32_t? uint16_t? An observation: both icmp6_mtu and nd_opt_mtu_mtu are uint32_t. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 08:49:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eALGm8i19091 for ipng-dist; Tue, 21 Nov 2000 08:48:08 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eALGlwj19084 for ; Tue, 21 Nov 2000 08:47:59 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA28424 for ; Tue, 21 Nov 2000 08:47:58 -0800 (PST) Received: from zrtps06s.us.nortel.com ([47.140.48.50]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11753 for ; Tue, 21 Nov 2000 08:47:57 -0800 (PST) Received: from zbl6c016.corpeast.baynetworks.com by zrtps06s.us.nortel.com; Tue, 21 Nov 2000 10:18:04 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id W8KSPD2D; Tue, 21 Nov 2000 07:54:44 -0500 Received: from nortelnetworks.com (deathvalley.corpeast.baynetworks.com [132.245.252.116]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id XJ54TCS4; Tue, 21 Nov 2000 07:54:44 -0500 Message-ID: <3A1A705C.86B8000D@nortelnetworks.com> Date: Tue, 21 Nov 2000 07:53:48 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Williams CC: Thomas Narten , JIM FLEMING , DOMAIN-POLICY@LISTS.NETSOL.COM, frezza@alum.mit.edu, "vinton g. cerf - ISOC" , ISI IPv6 list <6bone@ISI.EDU>, Internet Architecture Board , IPng List Subject: Re: Internet Protocol Version 6 Workshop References: <200011201446.JAA01145@hygro.adsl.duke.edu> <3A1A02D3.58EF7E4D@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff, Make up your mind. Is it two members of the mailing list OR a majority of the working group? BIG difference. Brian Haberman Jeff Williams wrote: > > Thomas and all, > > I am sorry I must respectfully disagree with you here Thomas. > I specifically had a running debate with two members of the Ipng > list members discussing this issue. > > Thomas Narten wrote: > > > Jeff Williams writes: > > > > > A little over a year ago, there was some heated debate (I was > > > involved) regarding the Privacy concerns with IPv6. Most of this > > > is do to two problems. One being the "Autoconfig" for implementation > > > specification for IPv6, the other is the "Always On" feature of IPv6. > > > The implementation (Autoconfig as default) was and remains that > > > biggest problem with respect to Privacy issues. (Autoconfig) should > > > not be default was my argument for implementation. I also suggested > > > several changes to the Spec for Autoconfig for consideration. But > > > the majority of the group felt that being able to track folks easily > > > was more important. I found this astounding. > > > > This characterization of past IPng WG discussions is most definitely > > false and at best a gross distortion of past discussions. At no time > > that I can recall has the WG ever argued that "tracking folks" is a > > desirable goal. It is also completely inconsistent with the WG's > > recent decision to recommend that the IESG publish > > draft-ietf-ipngwg-addrconf-privacy-03.txt as a Proposed Standard. > > > > Thomas > > Regards, > > -- > Jeffrey A. Williams > Spokesman INEGroup (Over 112k members strong!) > CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. > Information Network Eng. Group. INEG. INC. > E-Mail jwkckid1@ix.netcom.com > Contact Number: 972-447-1800 x1894 or 9236 fwd's to home ph# > Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 21 09:01:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eALH0IP19110 for ipng-dist; Tue, 21 Nov 2000 09:00:18 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eALH08j19102 for ; Tue, 21 Nov 2000 09:00:08 -0800 (PST) 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,v1.7) with ESMTP id JAA00962 for ; Tue, 21 Nov 2000 09:00:08 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29123 for ; Tue, 21 Nov 2000 09:00:06 -0800 (PST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id XC97BGJ9; Tue, 21 Nov 2000 18:00:07 +0100 Reply-To: From: "Thomas Eklund" To: "'Jim Bound'" Cc: "'Alex Conta'" , "'Steve Deering'" , "'Michael Thomas'" , "'Francis Dupont'" , "'Jun-ichiro itojun Hagino'" , "'Hesham Soliman \(EPA\)'" , "'Metzler Jochen'" , "'Ipng \(E-Mail\)'" Subject: RE: Usage of IPv6 flow label Date: Tue, 21 Nov 2000 17:59:55 +0100 Message-ID: <31A473DBB655D21180850008C71E251A0294928B@mail.kebne.se> 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) In-Reply-To: <31A473DBB655D21180850008C71E251A02F3C8A1@mail.kebne.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, > The only way I for one would support what your saying is if we also > defined the first bit of the flowlabel to denote it can be rewritable. > That first bit set or not is decided by the client or the clients > network (meaning a zone within which the client exists > authoritatively). Yes, I agree here in fact I'm writing a draft on this topic and the way I have intended to see it (then we can debate if people agree) is that we should have a dual-semantics of the flowlabel and inside the flow-label have one bit telling if the flowlabel is globally unique and possibly one bit telling if its ESP encrypted (see earlier discussion about changing the length field to ip header length field) > > If this bit is set then any e-2-e predications are lost and > users would > need to understand that. Agree. > > The other option is to use the traffic class bits. If the bit is not set, you mean? If so of course - I agree. > > But I also think the flowlabel can be used when defined by the client > and set by the client to assist greatly the evolution of the ECN model > and help with increasing bandwidth efficiency with TCP to notify a > client with a fast path for the search to find the clients > entry in the > table. Why do you think we need to take extra bits from the flow-label? The way I thougth most people saw it was to use to two unassigned bits in IPv4 ToS/IPv6 Traffic Class field for ecn?? > So I will argue what the router folks have done with MPLS will > need to be done by those wanting faster searches for > congestion and lost > packets with TCP. But why not use the extra two bits for ECN and use the flowlabel with dual semantics: 1) intserv/per flow identification set by the client in the access 2) mpls like semantics in the core with a possibility to do mpls-like TE (I say mpls like since it should be the same management software operating on a different traffic plane - v6 header instead of mpls header) -- 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 Nov 21 09:52:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eALHpO819138 for ipng-dist; Tue, 21 Nov 2000 09:51:24 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eALHpEj19131 for ; Tue, 21 Nov 2000 09:51:14 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA09123 for ; Tue, 21 Nov 2000 09:51:08 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22884 for ; Tue, 21 Nov 2000 09:51:07 -0800 (PST) Received: from ValuedSonyCustomer (as1b-234.chi.il.dial.anet.com [198.92.157.234]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id LAA02197; Tue, 21 Nov 2000 11:44:30 -0600 (CST) Message-ID: <0b3001c053e2$dd6d0e40$df00a8c0@ValuedSonyCustomer> From: "JIM FLEMING" To: "'Alex Conta'" , "'Jim Bound'" , Cc: , , "'Ipng (E-Mail)'" , "'Metzler Jochen'" , "'Hesham Soliman (EPA)'" , "'Jun-ichiro itojun Hagino'" , "'Francis Dupont'" , "'Michael Thomas'" , "'Steve Deering'" References: <31A473DBB655D21180850008C71E251A02949289@mail.kebne.se> Subject: IPv4HT - Re: Usage of IPv6 flow label Date: Tue, 21 Nov 2000 11:45:36 -0600 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thank you for your comment. In my opinion, there is a difference between a "service" and a bunch of routers, which may be in service or not. If the NANOG people want to focus on the "service" of having an end-to-end network with SIMPLE IPv4 (i.e. TOS not changed in transit)**, then they should be able to point out to people which companies (deploying the service, not building routers), abide by the policy of allowing a user to insert any 8 bit value into the IPv4 TOS field, and have that same value emerge on the other side of the cloud that NANOG claims to collectively "operate". Furthermore, I would think that companies engaged in deploying the "service" would want to make sure they point out to their customers that they provide, true, end-to-end, IPv4 IP Header Transport [IPv4HT]. (let's leave TCP and UDP out of this). I would also think that companies NOT providing this service would realize that there may be no motivation for those companies that do provide the service to deal with the headaches that non-conforming companies create. In short, they should stop routing to them. Also, I would think that the sales people from companies that DO provide IPv4HT, would want to point out to the current customers of those companies who do not, that they are using a NotWork, as opposed to a NetWork. As a service to the community, NANOG can easily run some tests to see which companies provide IP4HT and which do not. I have been personally surprised that some large companies, do not even know what their global policy is. As an aside, one could consider other fields of data communications, and consider what would happen if people walked up after the fact and "re-wrote the rules". Most people are probably familiar with 8-bit PCM voice streams, imagine an end-to-end "service" where for years people were able to get a clear-channel 8-bit PCM stream. Imagine, that everything worked fine, they place a 5 in one end and a 5 comes out the other end, they place the next sample, a 67 in one end and a 67 comes out the other. Now, imagine some equipment that comes along and randomly changes the 5 to a 6 or a 4, and the 67 to a 68 or a 66. Imagine what would happen if people had built software assuming a 5 in one end comes out a 5 at the other, not a 6 or a 4. Don't you think that network operators would come together and collectively realize that they have a major mess on their hands if they continue to change the values of the data stream that the CUSTOMER was told will be delivered, end-to-end, with a best effort, and not be changed from what the customer supplied ? There are not really that many bits in an IPv4 header. In my opinion, companies should FIRST focus on making sure they have a global cloud that can reliably transport the bits in the IPv4 header from "end-to-end". I think it is up to technologists to make sure that sales people know that they need to inform their customers that they provide IPv4HT, and if that differentiates them from another company that changes the customer's bits in transit, then so be it. At some point, it seems to me that we should be able to identify a collection of vendors who provide IPv4HT. For people that want IPv4HT service, I can not imagine why they would not want to use those vendors. Why by a "service" from companies who do not provide the service ? ** [Yes, folks...I know TTL and checksum change, please do not send me private mail describing your recent "ta-da" revelation, that those fields "change".] Jim Fleming http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp ----- Original Message ----- From: Thomas Eklund To: 'JIM FLEMING' ; 'Jim Bound' ; 'Alex Conta' Cc: 'Steve Deering' ; 'Michael Thomas' ; 'Francis Dupont' ; 'Jun-ichiro itojun Hagino' ; 'Hesham Soliman (EPA)' ; 'Metzler Jochen' ; 'Ipng (E-Mail)' ; Sent: Tuesday, November 21, 2000 10:27 AM Subject: RE: Usage of IPv6 flow label > > In my opinion, the IPv4 TOS should also be "e-2-e"... > > ...clients should set it....routers should leave it alone.... > > IPv4 ToS or IPv6 Traffic Class field is 8 bits and today most routers use 6 > bits for them for diffserv (DSCP) and then it is per defintion PER hop > behaviour and having possibility to re-write it at ingrees/egress router to > your domain > .. > > -- 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 Tue Nov 21 10:26:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eALIOwd19217 for ipng-dist; Tue, 21 Nov 2000 10:24:58 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eALIOmj19210 for ; Tue, 21 Nov 2000 10:24:48 -0800 (PST) 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,v1.7) with ESMTP id KAA04907 for ; Tue, 21 Nov 2000 10:24:47 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24272 for ; Tue, 21 Nov 2000 11:24:45 -0700 (MST) Received: from ValuedSonyCustomer (as1b-234.chi.il.dial.anet.com [198.92.157.234]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id MAA14210; Tue, 21 Nov 2000 12:15:18 -0600 (CST) Message-ID: <0b7a01c053e7$2a15dac0$df00a8c0@ValuedSonyCustomer> From: "JIM FLEMING" To: , "'Jim Bound'" Cc: "'Alex Conta'" , "'Steve Deering'" , "'Michael Thomas'" , "'Francis Dupont'" , "'Jun-ichiro itojun Hagino'" , "'Hesham Soliman (EPA)'" , "'Metzler Jochen'" , "'Ipng (E-Mail)'" References: <31A473DBB655D21180850008C71E251A0294928B@mail.kebne.se> Subject: What "unassigned bits" in IPv4 TOS ? Date: Tue, 21 Nov 2000 12:16:24 -0600 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: Thomas Eklund > Why do you think we need to take extra bits from the flow-label? The way I > thougth most people saw it was to use to two unassigned bits in IPv4 > ToS/IPv6 Traffic Class field for ecn?? > What "unassigned bits" in IPv4 TOS ? Next, are we going to see that 0100 is the version number "4" and clearly those 0's are not being used for much, so they are "unassigned" ? If so, let's make them 0101 (i.e. 5) and hope that the unassigned bit makes it to the other "end", (as in end-to-end)...let's see how far the IPv4 header gets with a 0101 in the first few bits....?...what fun... Jim Fleming http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 10:36:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eALIZ8x19240 for ipng-dist; Tue, 21 Nov 2000 10:35:08 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eALIYxj19233 for ; Tue, 21 Nov 2000 10:34:59 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA05349 for ; Tue, 21 Nov 2000 10:34:54 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05446 for ; Tue, 21 Nov 2000 10:34:54 -0800 (PST) Received: from ValuedSonyCustomer (as1b-234.chi.il.dial.anet.com [198.92.157.234]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id MAA21002; Tue, 21 Nov 2000 12:28:20 -0600 (CST) Message-ID: <0b8c01c053e8$fbc0ab80$df00a8c0@ValuedSonyCustomer> From: "JIM FLEMING" To: "Christian Kuhtz" , Cc: References: Subject: Re: good grief (RE: IPv4HT - Re: Usage of IPv6 flow label) Date: Tue, 21 Nov 2000 12:29:26 -0600 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks.... Just so we are clear, are you saying that it is a global Bell South policy NOT to provide (clear-channel) (end-to-end) IPv4 TOS field transport ? ...IPv4HT OR....are you saying that Bell South does provide IPv4HT, but a special service order is required ?...and additional costs ? Lastly, if we look at the tiny, 32-bit, legacy IPv4 address space, can we identify blocks (ranges) of addresses which Bell South uses to provide IPv4HT ? ...if people routing IPv4HT traffic to Bell South, only route based on those blocks, will that be OK ?... Jim Fleming http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp ----- Original Message ----- From: Christian Kuhtz To: Cc: Sent: Tuesday, November 21, 2000 12:11 PM Subject: good grief (RE: IPv4HT - Re: Usage of IPv6 flow label) > > > Jim, > > SP's use the IP ToS Precendence bits for marking traffic from their customers, > and treating it appropriately inside their cores. As such, IP ToS Precendence > may and will be overwritten unless you have special arrangements with that SP > as specified by your contract. More than likely, you'll be required to have > both ends of the path (where you care that IP ToS Precendence be preserved) on > the same SP cloud. > > Of an SP uses IP ToS Precendence to mark traffic so that it can be queued > properly, it must rewrite/policy IP ToS Precendence. In fact, it couldn't > meet the guarantees it may have contracts signed for unless it did so. And at > that point, your claims go out the window unless you have such a contract. > Tough luck. Can we move on now? > > At that point, you probably are a prime candidate for a VPN anyway. If you > for some crazy reason rely on IP ToS Precendence arriving the way you sent > them, use a VPN. And if you don't like that policy, use a VPN. Use a VPN. > And use a VPN. And you should still use a VPN. VPN, 'k? > > That's the IPv4 reality. Tough cookies. Old news. > > IMHO, anyone (that does include you, Jim) *relying* on IP ToS Precendence to > go anywhere unchanged -- without having made special provisions for it -- > needs to get their head checked. And, to trust IP ToS Precendence outside a > controlled environment is just as insane. > > PS: Quit addressing me as 'NANOG people'. And NANOG operates or ownes *zip* > in that regard. And please keep the Cc: list down. Thanks. Good grief, Jim, > you can't be serious, can you? Although, that straight jacket does look quite > fashionable, I must admit. > > PPS: Alright, so, this was a flame. Sorry if innocent bystanders were hurt. > ;-) > > -- > Christian Kuhtz -wk, -hm > Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. > "I speak for myself only." > > > -----Original Message----- > > From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > > JIM FLEMING > > Sent: Tuesday, November 21, 2000 12:46 PM > > To: 'Alex Conta'; 'Jim Bound'; thomas.eklund@xelerated.com > > Cc: nanog@nanog.org; bound@zk3.dec.com; 'Ipng (E-Mail)'; 'Metzler > > Jochen'; 'Hesham Soliman (EPA)'; 'Jun-ichiro itojun Hagino'; 'Francis > > Dupont'; 'Michael Thomas'; 'Steve Deering' > > Subject: IPv4HT - Re: Usage of IPv6 flow label > > > [.. noise removed ..] > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 10:49:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eALIljv19290 for ipng-dist; Tue, 21 Nov 2000 10:47:45 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eALIlaj19283 for ; Tue, 21 Nov 2000 10:47:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA09238 for ; Tue, 21 Nov 2000 10:47:35 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA09933 for ; Tue, 21 Nov 2000 11:47:28 -0700 (MST) Received: from ValuedSonyCustomer (as1b-234.chi.il.dial.anet.com [198.92.157.234]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id MAA25098; Tue, 21 Nov 2000 12:40:31 -0600 (CST) Message-ID: <0bca01c053ea$af65a220$df00a8c0@ValuedSonyCustomer> From: "JIM FLEMING" To: "Christian Kuhtz" , Cc: References: Subject: Re: good grief (RE: IPv4HT - Re: Usage of IPv6 flow label) Date: Tue, 21 Nov 2000 12:41:37 -0600 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have not found 800 numbers to be very helpful when it comes to policies. Wayne may be a better person to ask. CEO: F. Wayne Ackerman Industry: Telecommunications Headquarters: 1155 Peachtree St. NE | Atlanta, GA. 30367 Telephone: 404-249-2000 Web Site: www.bellsouth.com Employees: - Stock Symbol BLS (Investment Profile) Jim Fleming http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp ----- Original Message ----- From: Christian Kuhtz To: Cc: Sent: Tuesday, November 21, 2000 12:36 PM Subject: RE: good grief (RE: IPv4HT - Re: Usage of IPv6 flow label) > > > Read the sig, Jim. > > For all other product related questions, call 1-800-4-DOTNET. > > -- > Christian Kuhtz -wk, -hm > Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. > "I speak for myself only." > > > -----Original Message----- > > From: JIM FLEMING [mailto:jfleming@anet.com] > > Sent: Tuesday, November 21, 2000 1:29 PM > > To: Christian Kuhtz; nanog@nanog.org > > Cc: ipng@sunroof.eng.sun.com > > Subject: Re: good grief (RE: IPv4HT - Re: Usage of IPv6 flow label) > > > > > > Thanks.... > > > > Just so we are clear, are you saying that it is a global Bell South policy > > NOT to provide (clear-channel) (end-to-end) IPv4 TOS field transport ? > > ...IPv4HT > > > > OR....are you saying that Bell South does provide IPv4HT, but a special > > service > > order is required ?...and additional costs ? > > > > Lastly, if we look at the tiny, 32-bit, legacy IPv4 address space, can we > > identify > > blocks (ranges) of addresses which Bell South uses to provide IPv4HT ? > > > > ...if people routing IPv4HT traffic to Bell South, only route based on those > > blocks, will > > that be OK ?... > > > > Jim Fleming > > http://www.unir.com/images/architech.gif > > http://www.unir.com/images/address.gif > > http://www.unir.com/images/headers.gif > > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > > http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp > > > [.. noise removed ..] > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 12:31:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eALKU2Z19399 for ipng-dist; Tue, 21 Nov 2000 12:30:02 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eALKTrj19392 for ; Tue, 21 Nov 2000 12:29:53 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA07721 for ; Tue, 21 Nov 2000 12:29:52 -0800 (PST) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09815 for ; Tue, 21 Nov 2000 12:29:52 -0800 (PST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 13yK32-0007Qs-00; Tue, 21 Nov 2000 15:29:48 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA09831; Tue, 21 Nov 00 15:25:03 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id PAA13474; Tue, 21 Nov 2000 15:29:53 -0500 Message-Id: <3A1ADB3A.75A72E2A@txc.com> Date: Tue, 21 Nov 2000 15:29:46 -0500 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: Re: Usage of IPv6 flow label References: <20001115190919.321B17EF9@starfruit.itojun.org> <200011160958.KAA90047@givry.rennes.enst-bretagne.fr> <14867.59850.899996.178063@thomasm-u1.cisco.com> <3A142DEE.AA44B45F@txc.com> <3A1584F1.79185912@txc.com> <3A15B6B2.D29AAED@txc.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms03462E4CD30B762B3331FEFB" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms03462E4CD30B762B3331FEFB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve, Thank you for the elaborate clarifications. The dialog is certainly helping in dissipating confusion. The process is asymptotic though, on some of the points we are parallel rather than intersecting. For instance, my reference to diffserv was relative to aggregation. Your reference to 'intserv', I think is not. Intserv's "teething" problem was scalability, and "aggregation" was the solution proposed. But, to be short, all I am saying, is that in terms of the "mechanics" of aggregation, the solutions should not be inconsistent, or disjoint. In other words, tunneling should be optional, not mandatory. I feel relieved by your reminding that AH ignores the flow label, to allow the rewriting en-route, which is an important premise. As I followed closely the design of the IPv6 flow label, I am in complete agreement with you, that the reasoning, motivations, and choices made, were optimal several years ago, when this design took place. However -- and please excuse me if I repeat myself - circumstances changed since, if not in the complexity of the problem(s), in the availability of solutions, that is, architectures and protocols, which can be entirely, or partially, adopted, or IPv6 can be made easier to work with. You are absolutely right that the MPLS work had an emphasis on ATM, nevertheless, support for other relevant links, such as Frame Relay, PPP, and LANs was provided since day one, and generic encapsulation (PPP and LANs) is a basic building block for MPLS forwarding. As I recall vividly the discussions in the SIPP WG, and later in the IPng WG on the role and placing of the flow label within the IPv6 header, to facilitate fast forwarding, and/or filtering, I would argue that the set of problems that MPLS and IPv6 flow label attempt to resolve, are not, or do not have to be disjoint. In fact, since MPLS provides a simple mechanism for destination based, QoS, multicast, etc... forwarding, and traffic engineering, one could argue that the set of problems that it resolves is a superset. You are right that the emphasis "dans la raison d'etre" of MPLS has changed, because the research improved drastically the availability of solutions for IPv4 longest prefix match fast (or wire speed) forwarding. But if you believe, or imply, that just because of that, the IPv6-ers should no longer worry, and should no-longer search for mechanisms that would enrich IPv6 forwarding with simpler and cheaper solutions, or simplify or improve the existent mechanisms, then I should raise a flag of warning !!! If you look to "L-C tries", or "binary search on levels", or "controlled prefix expansion", to mention a few, their complexity is so much higher than the simple, fixed size label based forwarding, that in fairness. one can only put their AVAILABILITY ON A PAR, BUT NOT THEIR COST. Adding the need for additional engines for QoS, and multicasting, is not making these solutions any cheaper. 1Gps, and soon 10Gps will be the norm. At 10Gps, within 51 nano-seconds per packet time constraint, the length of the IPv6 address -- which is a given, and not argued here -- makes, unfortunately, the applicability of some of the IPv4 wire speed longest prefix match forwarding solutions, both in terms of lookup, and updating forwarding tables, quite problematic, thus reducing the number of choices, and making the task of forwarding engines designers not easier. Warning flag down, Alex Steve Deering wrote: > > At 5:52 PM -0500 11/17/00, Alex Conta wrote: > >Since the IPv6 flow label work started, two major efforts in IETF made > >significant progress on related topics: Diffserv and MPLS. > > Alex, > > Diffserv is in no way related to the Flow Label. IPv6 has the Traffic > Class field for diffserv-style QoS. The Flow Label was intended to > serve intserv-style QoS. > > >As an extension of the Diffserv aggregation model, the flow label SHOULD > >be re-writable. If you think about extending your argument to Diffserv, > >then Diffserv aggregated flows should be always tunneled. > > Intserv-style QoS, and the aggregation of intserv flows, is not an > extension of the diffserv aggregation (do you mean reclassification?) > model. If you want to do diffserv-style aggregation/reclassification, > go ahead and use the IPv6 Traffic Class field, which is intended for > that purpose. > > >The argument boils down to **forcing "read-only" onto flow labels does > >not pay**. > > We arranged for the Flow Label to be excluded from the AH authentication > function, precisely so it could safely be modified en-route, i.e., far > from "forcing" it to be read only, we have gone out of our way to make it mutable. We patiently await a spec that says exactly how to use > re-writable flow labels *including* how to allocate flow labels for > multicast flows crossing multi-access links. It is the messiness and > fragility of solutions to that latter problem that led to the initial > end-to-end, instead of hop-by-hop, design of the Flow Label. > > > On the contrary. > >I think that the MPLS work is a significant progress on the concept, and > >mechanisms of labeling flows, and as you know [(-:], I think IPv6 > >should borrow from it, rather than going against, or going on a path > >that was started before the MPLS effort, but so far didn't go far enough > >to be sufficiently significant. > > MPLS was not designed to address the same problems, across the same range > of link types, as the Flow Label. (Granted, MPLS's purposes have kept > changing over time, but it's still true today.) If you all you want is > MPLS for IPv6, go ahead and use MPLS under IPv6. It works just fine > (or rather, as well as it does for IPv4). > > >Some of the weight, or basis, or the hidden reason, of your tunneling > >argument comes, I think, from the fact that as of now, a flow label > >defines uniquely a flow, only when associated with the source address. > >Because of the need of the 20 + 128 bits for flow identification, just > >re-writing the flow label would not do it: you need a new source address > >as well for the flow identification. > > No, my arguments for tunneling do not derive from the constraints of > the Flow Label design, and would be the same whether the Flow Label > were end-to-end or hop-by-hop. > > The end-to-end Flow Label design derived from the observed problems > with doing label allocation for multi-access links. (Most of the > complexity of the ST protocol, which has hop-by-hop, layer-3 flow > labels/tags/VCIs, arose from trying to deal with that scenario.) > The end-to-end design avoids those problems, at the cost of a somewhat > more expensive look-up. Fortunately, router designers have gotten > better with sophisticated look-up algorithms, so we no longer have > to stick with small-integer indexing to get highest-speed forwarding > (MPLS's original raison d'etre). > > >But this (148 bits for uniquely identifying a flow), as well as > >re-writing, local, or global significance, unicity, etc... are all > >things that should be on the table for discussion. > > They are on the table for discussion, and have been for years. That's > why it's in an appendix of the spec. > > Steve --------------ms03462E4CD30B762B3331FEFB Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKBgYJKoZIhvcNAQcCoIIJ9zCCCfMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICETCCAg0CAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDExMjEyMDI5NDhaMCMGCSqGSIb3DQEJBDEWBBTIvd5M+oTntTJd/33h VH/AGGaMGzAnBgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAQTNUZbWaWGCliwECloZp7l2bZyvLjkycHpFzxKpWWFLviY139g2jDj1w /1mRyJfskc6VTY8mqHAZ1x3Eh+OzM7zK8TRQe1/vlm5Azyg+Qg6ZVjIX5HOBBF/hBsdOv2Fe Q3bVfO7npxCkS2nPyBSzQipGfO3DIjCWHmQOTcZWfwk= --------------ms03462E4CD30B762B3331FEFB-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 12:51:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eALKf5f19430 for ipng-dist; Tue, 21 Nov 2000 12:41:05 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eALKeoj19423 for ; Tue, 21 Nov 2000 12:40:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA26910 for ; Tue, 21 Nov 2000 12:40:49 -0800 (PST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13741 for ; Tue, 21 Nov 2000 12:40:48 -0800 (PST) Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id D067C240280F; Tue, 21 Nov 2000 21:40:42 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id VAA16570; Tue, 21 Nov 2000 21:40:42 +0100 (MET) To: mankin@east.isi.edu Cc: narten@raleigh.ibm.com, richdr@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: Comments on the Privacy Extensions draft References: <10011210413.AA18840@maia.east.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 21 Nov 2000 21:40:42 +0100 In-Reply-To: Allison Mankin's message of "Mon, 20 Nov 2000 23:13:34 -0500" Message-ID: Lines: 49 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Allison Mankin writes: > To make it difficult to make educated guesses as to whether two > different interface identifiers belong to the same node, the > algorithm for generating alternate identifiers must include input > that has an unpredictable component from the perspective of the > outside entities that are collecting information. Picking identifiers > from a pseudo-random sequence suffices, so long as the specific > sequence cannot be determined by an outsider examining just the > identifiers that appear in addresses or are otherwise readily > available (e.g., a node's link-layer address). > > It's bad news if the node's link-layer address is "readily > available" to arbitrary remote peers - the last parenthesis > doesn't make sense in this draft about not embedding link-layer > addresses in packet addresses.... If also non-anonymous adresses, based on the link-level address, are used, som knowledge about the address are leaked. For instance, consider a link with a few dozen nodes, each of them having (i) a globally unique addess, constructed as prefix + EUI-64, (ii) link-level address, also based on the same EUI-64 id, (iii) a bunch of anonymous addresses based on, say, md5(EUI-64 + small counter), using the same prefix as the global address If you connect somewhere using an anonymous address, and the server has a list of previously observed global addresses, the server can lookup the global addresses that happened to match your prefix. Next, the EUI-64 ids for the matching addresses are extracted, and a reasonably small search will tell if any of those identifiers match your anonymous address, and if so, which one. There may also be other means of getting network-card addresses (imagine a customer database listing the customers and serial numbers of all purchased hardware). Perhaps I'm missing something, but it seems wise to me not to assume that link local addresses or network serial numbers and similar data are secret. You probably also don't want to assume that the "arbitrary remote peer" isn't cooperating with other less arbitrary and more determined peers. /Niels -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 12:52:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eALKnpK19466 for ipng-dist; Tue, 21 Nov 2000 12:49:51 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eALKn8j19459 for ; Tue, 21 Nov 2000 12:49:29 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA14940 for ; Tue, 21 Nov 2000 12:49:00 -0800 (PST) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17418 for ; Tue, 21 Nov 2000 12:48:59 -0800 (PST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 13yKHr-0002i3-00; Tue, 21 Nov 2000 15:45:07 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA09960; Tue, 21 Nov 00 15:40:20 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id PAA13921; Tue, 21 Nov 2000 15:45:09 -0500 Message-Id: <3A1ADED2.68D558E8@txc.com> Date: Tue, 21 Nov 2000 15:45:06 -0500 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Jim Bound Cc: Steve Deering , Michael Thomas , Francis Dupont , Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <200011210518.AAA0000564672@anw.zk3.dec.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6ABB7CA29A08F007F50FC19F" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms6ABB7CA29A08F007F50FC19F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I would agree with that only of flow label's role is an end-to-end, or host-to-host processing. But then why bother to carry it in the IPv6 main header, which is a header that is for hop-by-hop processing? Alex Jim Bound wrote: > > the flow label should be guranteed e-2-e. clients should set it. > routers should leave it alone. > > /jim --------------ms6ABB7CA29A08F007F50FC19F Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKBgYJKoZIhvcNAQcCoIIJ9zCCCfMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICETCCAg0CAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDExMjEyMDQ1MDhaMCMGCSqGSIb3DQEJBDEWBBQeuTwJ8wJ+Ir5Bt7Q1 P54kp8hOozAnBgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAdhgmvSJm/rBrrfz/JcUERSbGtOG+zn8oTk3kZzYkIH4/UdVQJ4TrHZkz UJqnHnQl7mF55bOA83dMhM/pXzEvJ27DSbjkw/HEV+Ig0t1vOrVsMLM3RXgKZfh9EsxXVbLy QE99w4dtJBusYppr8J8E4c4kRuWbRYilfzEL1SGhyDI= --------------ms6ABB7CA29A08F007F50FC19F-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 12:52:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eALKmxN19457 for ipng-dist; Tue, 21 Nov 2000 12:48:59 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eALKmYj19450 for ; Tue, 21 Nov 2000 12:48:36 -0800 (PST) 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,v1.7) with ESMTP id MAA28516 for ; Tue, 21 Nov 2000 12:48:07 -0800 (PST) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23326 for ; Tue, 21 Nov 2000 13:48:07 -0700 (MST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 13yKE9-00021O-00; Tue, 21 Nov 2000 15:41:18 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA09923; Tue, 21 Nov 00 15:36:19 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id PAA13797; Tue, 21 Nov 2000 15:41:07 -0500 Message-Id: <3A1ADDE0.6005FC3@txc.com> Date: Tue, 21 Nov 2000 15:41:04 -0500 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Jim Bound Cc: Thomas Narten , Metzler Jochen , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <200011210433.XAA0000561591@anw.zk3.dec.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msB578FD6F78BE5F5EAB46AEBA" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msB578FD6F78BE5F5EAB46AEBA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jim, As there were a good number of messages on this topic, I am not sure what particular message is your message in reference to, and what you meant to say. My guess could be wrong, nevertheless, if you meant to say that some RSVP messages may carry the IPv6 flow label, I could add that some and perhaps same RSVP messages may carry MPLS labels. Alex Jim Bound wrote: > > Alex, > > RSVP uses the flow label in IPv6. > > /jim --------------msB578FD6F78BE5F5EAB46AEBA Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKBgYJKoZIhvcNAQcCoIIJ9zCCCfMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICETCCAg0CAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDExMjEyMDQxMDVaMCMGCSqGSIb3DQEJBDEWBBR3Pyy1X5HLoniE9jbs iFigKF+CUjAnBgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAC7gULuKEg2HNerPJjMq59ohP0ISMp8OuD/EDHjF0yLHD/UXZJI1u+Vqm F9jzu8Z+y5xZrRi7FOCzaxc0wKEtGdoT/xYe44BaP9coy6tmvhqxwNmKj/wmpyCkInSt+Gfd uLdGRRhdJUi4zygVCL6JYKIkn8J7Z2e/Dw/z823UUdM= --------------msB578FD6F78BE5F5EAB46AEBA-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 13:14:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eALLCU719724 for ipng-dist; Tue, 21 Nov 2000 13:12:30 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eALLCPj19717 for ; Tue, 21 Nov 2000 13:12:26 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id eALLBLn05784 for ipng@sunroof.eng.sun.com; Tue, 21 Nov 2000 13:11:21 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eALICwj19162 for ; Tue, 21 Nov 2000 10:12:58 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA01639 for ; Tue, 21 Nov 2000 10:12:57 -0800 (PST) Received: from ns1.arch.bellsouth.net (ns1.arch.bellsouth.net [205.152.173.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA07625 for ; Tue, 21 Nov 2000 10:12:56 -0800 (PST) Received: from bar (ckhome [24.31.106.30]) by ns1.arch.bellsouth.net (8.9.1a/8.9.1) with SMTP id NAA28334; Tue, 21 Nov 2000 13:12:30 -0500 (EST) From: "Christian Kuhtz" To: Cc: Subject: good grief (RE: IPv4HT - Re: Usage of IPv6 flow label) Date: Tue, 21 Nov 2000 13:11:57 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <0b3001c053e2$dd6d0e40$df00a8c0@ValuedSonyCustomer> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, SP's use the IP ToS Precendence bits for marking traffic from their customers, and treating it appropriately inside their cores. As such, IP ToS Precendence may and will be overwritten unless you have special arrangements with that SP as specified by your contract. More than likely, you'll be required to have both ends of the path (where you care that IP ToS Precendence be preserved) on the same SP cloud. Of an SP uses IP ToS Precendence to mark traffic so that it can be queued properly, it must rewrite/policy IP ToS Precendence. In fact, it couldn't meet the guarantees it may have contracts signed for unless it did so. And at that point, your claims go out the window unless you have such a contract. Tough luck. Can we move on now? At that point, you probably are a prime candidate for a VPN anyway. If you for some crazy reason rely on IP ToS Precendence arriving the way you sent them, use a VPN. And if you don't like that policy, use a VPN. Use a VPN. And use a VPN. And you should still use a VPN. VPN, 'k? That's the IPv4 reality. Tough cookies. Old news. IMHO, anyone (that does include you, Jim) *relying* on IP ToS Precendence to go anywhere unchanged -- without having made special provisions for it -- needs to get their head checked. And, to trust IP ToS Precendence outside a controlled environment is just as insane. PS: Quit addressing me as 'NANOG people'. And NANOG operates or ownes *zip* in that regard. And please keep the Cc: list down. Thanks. Good grief, Jim, you can't be serious, can you? Although, that straight jacket does look quite fashionable, I must admit. PPS: Alright, so, this was a flame. Sorry if innocent bystanders were hurt. ;-) -- Christian Kuhtz -wk, -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only." > -----Original Message----- > From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > JIM FLEMING > Sent: Tuesday, November 21, 2000 12:46 PM > To: 'Alex Conta'; 'Jim Bound'; thomas.eklund@xelerated.com > Cc: nanog@nanog.org; bound@zk3.dec.com; 'Ipng (E-Mail)'; 'Metzler > Jochen'; 'Hesham Soliman (EPA)'; 'Jun-ichiro itojun Hagino'; 'Francis > Dupont'; 'Michael Thomas'; 'Steve Deering' > Subject: IPv4HT - Re: Usage of IPv6 flow label > [.. noise removed ..] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 13:14:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eALLD9C19733 for ipng-dist; Tue, 21 Nov 2000 13:13:09 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eALLD4j19726 for ; Tue, 21 Nov 2000 13:13:04 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id eALLC0k05813 for ipng@sunroof.eng.sun.com; Tue, 21 Nov 2000 13:12:00 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eALIb1j19244 for ; Tue, 21 Nov 2000 10:37:02 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA06056 for ; Tue, 21 Nov 2000 10:37:00 -0800 (PST) Received: from ns1.arch.bellsouth.net (ns1.arch.bellsouth.net [205.152.173.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06268 for ; Tue, 21 Nov 2000 10:36:59 -0800 (PST) Received: from bar (ckhome [24.31.106.30]) by ns1.arch.bellsouth.net (8.9.1a/8.9.1) with SMTP id NAA28688; Tue, 21 Nov 2000 13:36:51 -0500 (EST) From: "Christian Kuhtz" To: Cc: Subject: RE: good grief (RE: IPv4HT - Re: Usage of IPv6 flow label) Date: Tue, 21 Nov 2000 13:36:17 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <0b8c01c053e8$fbc0ab80$df00a8c0@ValuedSonyCustomer> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Read the sig, Jim. For all other product related questions, call 1-800-4-DOTNET. -- Christian Kuhtz -wk, -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only." > -----Original Message----- > From: JIM FLEMING [mailto:jfleming@anet.com] > Sent: Tuesday, November 21, 2000 1:29 PM > To: Christian Kuhtz; nanog@nanog.org > Cc: ipng@sunroof.eng.sun.com > Subject: Re: good grief (RE: IPv4HT - Re: Usage of IPv6 flow label) > > > Thanks.... > > Just so we are clear, are you saying that it is a global Bell South policy > NOT to provide (clear-channel) (end-to-end) IPv4 TOS field transport ? > ...IPv4HT > > OR....are you saying that Bell South does provide IPv4HT, but a special > service > order is required ?...and additional costs ? > > Lastly, if we look at the tiny, 32-bit, legacy IPv4 address space, can we > identify > blocks (ranges) of addresses which Bell South uses to provide IPv4HT ? > > ...if people routing IPv4HT traffic to Bell South, only route based on those > blocks, will > that be OK ?... > > Jim Fleming > http://www.unir.com/images/architech.gif > http://www.unir.com/images/address.gif > http://www.unir.com/images/headers.gif > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp > [.. noise removed ..] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 15:20:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eALNJOf19893 for ipng-dist; Tue, 21 Nov 2000 15:19:24 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eALNJCj19886 for ; Tue, 21 Nov 2000 15:19:12 -0800 (PST) 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,v1.7) with ESMTP id PAA24424 for ; Tue, 21 Nov 2000 15:19:12 -0800 (PST) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA19212 for ; Tue, 21 Nov 2000 16:19:09 -0700 (MST) Received: from ix.netcom.com (user-2inic64.dialup.mindspring.com [165.121.48.196]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id SAA20451; Tue, 21 Nov 2000 18:18:51 -0500 (EST) Message-ID: <3A1B22A1.4D7E9008@ix.netcom.com> Date: Tue, 21 Nov 2000 17:34:25 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Brian Haberman CC: Thomas Narten , JIM FLEMING , DOMAIN-POLICY@LISTS.NETSOL.COM, frezza@alum.mit.edu, "vinton g. cerf - ISOC" , ISI IPv6 list <6bone@ISI.EDU>, Internet Architecture Board , IPng List Subject: Re: Internet Protocol Version 6 Workshop References: <200011201446.JAA01145@hygro.adsl.duke.edu> <3A1A02D3.58EF7E4D@ix.netcom.com> <3A1A705C.86B8000D@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian and all, If you read my previous response carefully I said two (2) other members of the list. (See below) Your point? Big difference from WHAT? >;) I never said anything about the majority of the WG. I responded that this subject WAS actually discussed in some detail and at some length, which disagreed with the response from Thomas (Also below). Brian Haberman wrote: > Jeff, > Make up your mind. Is it two members of the mailing list OR > a majority of the working group? BIG difference. > > Brian Haberman > > Jeff Williams wrote: > > > > Thomas and all, > > > > I am sorry I must respectfully disagree with you here Thomas. > > I specifically had a running debate with two members of the Ipng > > list members discussing this issue. > > > > Thomas Narten wrote: > > > > > Jeff Williams writes: > > > > > > > A little over a year ago, there was some heated debate (I was > > > > involved) regarding the Privacy concerns with IPv6. Most of this > > > > is do to two problems. One being the "Autoconfig" for implementation > > > > specification for IPv6, the other is the "Always On" feature of IPv6. > > > > The implementation (Autoconfig as default) was and remains that > > > > biggest problem with respect to Privacy issues. (Autoconfig) should > > > > not be default was my argument for implementation. I also suggested > > > > several changes to the Spec for Autoconfig for consideration. But > > > > the majority of the group felt that being able to track folks easily > > > > was more important. I found this astounding. > > > > > > This characterization of past IPng WG discussions is most definitely > > > false and at best a gross distortion of past discussions. At no time > > > that I can recall has the WG ever argued that "tracking folks" is a > > > desirable goal. It is also completely inconsistent with the WG's > > > recent decision to recommend that the IESG publish > > > draft-ietf-ipngwg-addrconf-privacy-03.txt as a Proposed Standard. > > > > > > Thomas > > > > Regards, > > > > -- > > Jeffrey A. Williams > > Spokesman INEGroup (Over 112k members strong!) > > CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. > > Information Network Eng. Group. INEG. INC. > > E-Mail jwkckid1@ix.netcom.com > > Contact Number: 972-447-1800 x1894 or 9236 fwd's to home ph# > > Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 112k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1800 x1894 or 9236 fwd's to home ph# Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 15:54:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eALNr5A19930 for ipng-dist; Tue, 21 Nov 2000 15:53:05 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eALNqtj19923 for ; Tue, 21 Nov 2000 15:52:56 -0800 (PST) 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,v1.7) with ESMTP id PAA19681 for ; Tue, 21 Nov 2000 15:52:55 -0800 (PST) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06826 for ; Tue, 21 Nov 2000 15:52:54 -0800 (PST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 13yNDZ-0003m4-00; Tue, 21 Nov 2000 18:52:53 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA11577; Tue, 21 Nov 00 18:48:08 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id SAA18781; Tue, 21 Nov 2000 18:52:59 -0500 Message-Id: <3A1B0AD7.C1EB94AD@txc.com> Date: Tue, 21 Nov 2000 18:52:55 -0500 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Brian E Carpenter Cc: Steve Deering , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <20001115190919.321B17EF9@starfruit.itojun.org> <200011160958.KAA90047@givry.rennes.enst-bretagne.fr> <14867.59850.899996.178063@thomasm-u1.cisco.com> <3A142DEE.AA44B45F@txc.com> <3A1584F1.79185912@txc.com> <3A15B6B2.D29AAED@txc.com> <3A19A76B.3DA48095@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms472B1156351852B59AA7A3A6" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms472B1156351852B59AA7A3A6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian, Please re-examine. My point was that both Diffserv, and MPLS, deal with QoS topics, as the IPv6 flow label does. Therefore, orthogonality, if I understand you correctly, as independence from each other, and the rest, has little relevance to my point. In contradiction to earlier calls, and statements on this list, your message seem to suggest that the flow label is well defined, and its role well determined... If that is the case, I should say I am sorry: this is rather a waste of everybody's time.... Alex Brian E Carpenter wrote: > > Alex, > > Alex Conta wrote: > > > > Since the IPv6 flow label work started, two major efforts in IETF made > > significant progress on related topics: Diffserv and MPLS. > > Steve's already said this but I want to say it again: no! > > The Flow Label is totally orthogonal to diffserv, which has no need > of it, since it has its own mutable 6-bit field (more than enough). > > The Flow Label is totally orthogonal to the MPLS Shim, which is at a lower > layer and is edge-to-edge, not end-to-end. > > As has been observed, the Flow Label is accommodated neatly by the IntServ > model. > > Brian --------------ms472B1156351852B59AA7A3A6 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKBgYJKoZIhvcNAQcCoIIJ9zCCCfMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICETCCAg0CAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDExMjEyMzUyNThaMCMGCSqGSIb3DQEJBDEWBBTVAWP7nGhaQMCVAUB2 0BSkjro9zDAnBgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAYAycURwe9R4BvBo8ol2SWDy6LjdsLpAK1koVWkHggl3N3m/kS3YEwanB WPksbe4xGv/Mlek6BdB39CnKKvKjVy89YcJKHZaP9zfqHVJxPdMH9WwJSbYWd7VizUmc6Ikh Ak2gxst8Q+95Cht0oT+CZvWnbAxHc7/zCyCY4ipp8f8= --------------ms472B1156351852B59AA7A3A6-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 16:01:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAM00wQ19949 for ipng-dist; Tue, 21 Nov 2000 16:00:58 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAM00mj19942 for ; Tue, 21 Nov 2000 16:00:48 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA18571 for ; Tue, 21 Nov 2000 16:00:48 -0800 (PST) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA21503 for ; Tue, 21 Nov 2000 16:00:47 -0800 (PST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 13yNEH-0003r5-00; Tue, 21 Nov 2000 18:53:37 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA11580; Tue, 21 Nov 00 18:48:40 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id SAA18790; Tue, 21 Nov 2000 18:53:30 -0500 Message-Id: <3A1B0AF7.69D8B7D5@txc.com> Date: Tue, 21 Nov 2000 18:53:27 -0500 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Jim Bound Cc: thomas.eklund@xelerated.com, "'Steve Deering'" , "'Michael Thomas'" , "'Francis Dupont'" , "'Jun-ichiro itojun Hagino'" , "'Hesham Soliman (EPA)'" , "'Metzler Jochen'" , "'Ipng (E-Mail)'" Subject: Re: Usage of IPv6 flow label References: <200011210530.AAA0000565660@anw.zk3.dec.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms83BC822A2B42FAE8D3A976D5" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms83BC822A2B42FAE8D3A976D5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jim, So, you would not support Thomas's solution, if the second bit would denote that the label is rewritable? [Just kidding (-:....] Seriously now... if labels are entities known and stored by routers, as part of a flow state, whether that is part of a forwarding table, or classification rules table, then, carrying a "read-only/write" bit of information in each and every packet's header is not necessary. I have difficulties parsing your second part of the message.... Alex Jim Bound wrote: > > Thomas, > > >And I also think that IPv6 should "borrow the mechanisms". An I would like > >to see a combine model for use of the flow-label where the "intserv"/per > >flow model would exist in the access and that a aggregated/"differv"/"mpls" > >like model with possibility to re-write the flow label would exist... > > The only way I for one would support what your saying is if we also > defined the first bit of the flowlabel to denote it can be rewritable. > That first bit set or not is decided by the client or the clients > network (meaning a zone within which the client exists authoritatively). > > If this bit is set then any e-2-e predications are lost and users would > need to understand that. > > The other option is to use the traffic class bits. > > But I also think the flowlabel can be used when defined by the client > and set by the client to assist greatly the evolution of the ECN model > and help with increasing bandwidth efficiency with TCP to notify a > client with a fast path for the search to find the clients entry in the > table. So I will argue what the router folks have done with MPLS will > need to be done by those wanting faster searches for congestion and lost > packets with TCP. > > Steve's position is par excellence and I would like to see your response > to Steve as Alex has? > > /jim --------------ms83BC822A2B42FAE8D3A976D5 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKBgYJKoZIhvcNAQcCoIIJ9zCCCfMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICETCCAg0CAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDExMjEyMzUzMjlaMCMGCSqGSIb3DQEJBDEWBBRlRHhHOL7bY0sbUwlT idtBqFyQ1jAnBgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAlnx6qasDYhAy74kH6ApDeyNYoQpR3jSd3g3SS9mr13zTH9/ArOou53yo W21GQ3QUnza4RjkVn3LXxlPwp+JI3SxfDKAttqEbT24JoIx+rYrpgOM2qvmPUE4C38xtu6A3 3gkWPm7GPj1RulwCL2NYq6hc+pxOw4DZwvWmffcAbtc= --------------ms83BC822A2B42FAE8D3A976D5-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 16:36:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAM0Yug19984 for ipng-dist; Tue, 21 Nov 2000 16:34:56 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAM0Ylj19977 for ; Tue, 21 Nov 2000 16:34:47 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA29676 for ; Tue, 21 Nov 2000 16:34:46 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06746 for ; Tue, 21 Nov 2000 16:34:45 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 1B58F5B56; Tue, 21 Nov 2000 19:34:45 -0500 (EST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 658F75A48; Tue, 21 Nov 2000 19:34:44 -0500 (EST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id TAA0000658150; Tue, 21 Nov 2000 19:34:27 -0500 (EST) From: Jim Bound Message-Id: <200011220034.TAA0000658150@anw.zk3.dec.com> To: Cc: "'Jim Bound'" , "'Alex Conta'" , "'Steve Deering'" , "'Michael Thomas'" , "'Francis Dupont'" , "'Jun-ichiro itojun Hagino'" , "'Hesham Soliman (EPA)'" , "'Metzler Jochen'" , "'Ipng (E-Mail)'" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Tue, 21 Nov 2000 17:59:55 +0100." <31A473DBB655D21180850008C71E251A0294928B@mail.kebne.se> Date: Tue, 21 Nov 2000 19:34:26 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Thomas, >> The only way I for one would support what your saying is if we also >> defined the first bit of the flowlabel to denote it can be rewritable. >> That first bit set or not is decided by the client or the clients >> network (meaning a zone within which the client exists >> authoritatively). >Yes, I agree here in fact I'm writing a draft on this topic and the way I >have intended to see it (then we can debate if people agree) is that we >should have a dual-semantics of the flowlabel and inside the flow-label have >one bit telling if the flowlabel is globally unique and possibly one bit >telling if its ESP encrypted (see earlier discussion about changing the >length field to ip header length field) OK I will read it. But I don't support changing the header length field at all. >> The other option is to use the traffic class bits. >If the bit is not set, you mean? If so of course - I agree. Yes. >> But I also think the flowlabel can be used when defined by the client >> and set by the client to assist greatly the evolution of the ECN model >> and help with increasing bandwidth efficiency with TCP to notify a >> client with a fast path for the search to find the clients >> entry in the >> table. >Why do you think we need to take extra bits from the flow-label? The way I >thougth most people saw it was to use to two unassigned bits in IPv4 >ToS/IPv6 Traffic Class field for ecn?? Because the diff serv bits are too precious rather take one from 20 than the few left in tos/class. But I am not convinced this is the correct technical answer but might be the only answer. I got at least 4 different inputs in the customer base for four different uses of the flowlabel. But the good news is the needs all aggregate to I hope two solutions we are discussing now. >> So I will argue what the router folks have done with MPLS will >> need to be done by those wanting faster searches for >> congestion and lost >> packets with TCP. > >But why not use the extra two bits for ECN and use the flowlabel with dual >semantics: >1) intserv/per flow identification set by the client in the access >2) mpls like semantics in the core with a possibility to do mpls-like TE (I >say mpls like since it should be the same management software operating on a >different traffic plane - v6 header instead of mpls header) Think I answered above on why not the tos/class field. I suppose if we can bit-twiddle the ECN bits to do what they need to do and get a differentiation for flowlabel that would be cool. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 16:41:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAM0eIp20006 for ipng-dist; Tue, 21 Nov 2000 16:40:18 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAM0e9j19999 for ; Tue, 21 Nov 2000 16:40:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA07563 for ; Tue, 21 Nov 2000 16:40:08 -0800 (PST) Received: from zcamail02.zca.compaq.com (zcamail02.zca.compaq.com [161.114.32.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA26109 for ; Tue, 21 Nov 2000 17:40:08 -0700 (MST) Received: by zcamail02.zca.compaq.com (Postfix, from userid 12345) id 98AF87484; Tue, 21 Nov 2000 16:40:09 -0800 (PST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zcamail02.zca.compaq.com (Postfix) with ESMTP id D98917430; Tue, 21 Nov 2000 16:40:08 -0800 (PST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id TAA0000658260; Tue, 21 Nov 2000 19:39:39 -0500 (EST) From: Jim Bound Message-Id: <200011220039.TAA0000658260@anw.zk3.dec.com> To: Alex Conta Cc: Jim Bound , Thomas Narten , Metzler Jochen , "Ipng (E-Mail)" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Tue, 21 Nov 2000 15:41:04 EST." <3A1ADDE0.6005FC3@txc.com> Date: Tue, 21 Nov 2000 19:39:39 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Alex, >As there were a good number of messages on this topic, I am not sure >what particular message is your message in reference to, and what you >meant to say. >My guess could be wrong, nevertheless, if you meant to say that some >RSVP messages may carry the IPv6 flow label, I could add that some and >perhaps same RSVP messages may carry MPLS labels. Agreed on MPLS for RSVP. I was responding to the general notion that we no longer need e2e from client to client immutable flowlabel. I strongly disagree and in fact market expectation is now in fact we will have that with IPv6 especially around 3GPP deployment. Now if we can figure out away to set a bit to say in this case the flowlabel is mutable, though I find this disgusting, I can see how I for one would compromise and go along with it. See my response to Thomas Eklund I just sent. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 16:45:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAM0hu120024 for ipng-dist; Tue, 21 Nov 2000 16:43:56 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAM0hjj20017 for ; Tue, 21 Nov 2000 16:43:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA08760 for ; Tue, 21 Nov 2000 16:43:45 -0800 (PST) Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA27751 for ; Tue, 21 Nov 2000 17:43:44 -0700 (MST) Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345) id F00194510; Tue, 21 Nov 2000 18:43:43 -0600 (CST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 2979A4639; Tue, 21 Nov 2000 18:43:43 -0600 (CST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id TAA0000658840; Tue, 21 Nov 2000 19:43:41 -0500 (EST) From: Jim Bound Message-Id: <200011220043.TAA0000658840@anw.zk3.dec.com> To: Alex Conta Cc: Jim Bound , Steve Deering , Michael Thomas , Francis Dupont , Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Tue, 21 Nov 2000 15:45:06 EST." <3A1ADED2.68D558E8@txc.com> Date: Tue, 21 Nov 2000 19:43:40 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Alex, >I would agree with that only of flow label's role is an end-to-end, or >host-to-host >processing. But then why bother to carry it in the IPv6 main header, >which is a header that >is for hop-by-hop processing? Carry in header because it can be also used for setup and traffic engineering as RSVP is using it today with IPv6 (well not traffic engineering but I believe it could). Also I don't want to add it below the header because I can access the addr+flowlabel tuple immediately in the header for uses that are not just for routing, as I suggested to Thomas Eklund (TCP congestion as one example). regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 17:06:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAM15C020101 for ipng-dist; Tue, 21 Nov 2000 17:05:12 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAM14oj20094 for ; Tue, 21 Nov 2000 17:04:52 -0800 (PST) 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,v1.7) with ESMTP id RAA12303 for ; Tue, 21 Nov 2000 17:04:47 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA28263 for ; Tue, 21 Nov 2000 17:04:46 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 21 Nov 2000 17:03:51 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Tue, 21 Nov 2000 17:04:39 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80130C9BB@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "'nisse@lysator.liu.se'" , mankin@east.isi.edu Cc: narten@raleigh.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: Comments on the Privacy Extensions draft Date: Tue, 21 Nov 2000 16:57:31 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > For instance, consider a link with a few dozen nodes, each of them > having > > (i) a globally unique addess, constructed as prefix + EUI-64, > (ii) link-level address, also based on the same EUI-64 id, > (iii) a bunch of anonymous addresses based on, say, > md5(EUI-64 + small counter), using the same prefix as the global > address This isn't how the randomized interface identifiers are generated... > If you connect somewhere using an anonymous address, and the server > has a list of previously observed global addresses, the server can > lookup the global addresses that happened to match your prefix. Next, > the EUI-64 ids for the matching addresses are extracted, and a > reasonably small search will tell if any of those identifiers match > your anonymous address, and if so, which one. So the server can not work backwards from a public address to figure out what anonymous addresses belong to the same node. 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 Tue Nov 21 17:27:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAM1Pon20153 for ipng-dist; Tue, 21 Nov 2000 17:25:50 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAM1Pej20143 for ; Tue, 21 Nov 2000 17:25:41 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id eAM1OUY06079 for ipng@sunroof.eng.sun.com; Tue, 21 Nov 2000 17:24:30 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAM1Blj20113 for ; Tue, 21 Nov 2000 17:11:48 -0800 (PST) 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,v1.7) with ESMTP id RAA13849 for ; Tue, 21 Nov 2000 17:11:44 -0800 (PST) Received: from zmailer.org (mail.zmailer.org [194.252.70.162]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29860 for ; Tue, 21 Nov 2000 17:11:43 -0800 (PST) Received: (from localhost user: 'mea' uid#500 fake: STDIN (mea@zmailer.org)) by mail.zmailer.org id ; Wed, 22 Nov 2000 03:11:28 +0200 Date: Wed, 22 Nov 2000 03:11:28 +0200 From: Matti Aarnio To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: ipng@sunroof.eng.sun.com Subject: Re: Comments on the Privacy Extensions draft Message-ID: <20001122031128.W28963@mea-ext.zmailer.org> References: <10011210413.AA18840@maia.east.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: ; from nisse@lysator.liu.se on Tue, Nov 21, 2000 at 09:40:42PM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Nov 21, 2000 at 09:40:42PM +0100, Niels Möller wrote: > If also non-anonymous adresses, based on the link-level address, are > used, som knowledge about the address are leaked. > > For instance, consider a link with a few dozen nodes, each of them > having > > (i) a globally unique addess, constructed as prefix + EUI-64, > (ii) link-level address, also based on the same EUI-64 id, > (iii) a bunch of anonymous addresses based on, say, > md5(EUI-64 + small counter), using the same prefix as the global > address IF there is *small* counter. Indeed the draft gives me more of an idea of using some good randomness source, like hosts need to have against TCP sequence number start spoof attacks anyway. Algorithm at chapter 3.2.1 seems to have very strong randomness property, not a trivial counter at all. Indeed doing pure pick of 8 random bytes, masking some, and doing DAD driven duplicate avoidance does yield similar result as the whole complicated scheme of calculating new value from real EUI-64 + previous (8) history pseudorandom bytes. But being purely random, they have no relationship with the real EUI-64 at the machine. For second and third reasons mentioned at chapter 4, I still prefer DHCP approach. ISC's DHCP does fluently issue (IPv4) addresses out of pool to machines: first come, first free issued. The only problem at the DHCP approach is that it doesn't support time variability of the address in gracefull manner. ... but that is developeable, perhaps as an extension. (chapter 6 mentions this issue also.) The DHCP does give traceability for local network administrators (presuming it is used -- not an absolute requirement, after all), while external people have no clue as to who is where when. The "blame-traceability" is important thing to many network admins, anonymization should not make that too difficult. (A thing analogous to 'arpwatch' can handle Layer2/Layer3 binding tracking for IPv6, but it mandates a set of machines not otherwise needed.) > You probably also don't want to assume that the "arbitrary remote > peer" isn't cooperating with other less arbitrary and more determined > peers. If the badies are at your local L2 network, you have been had anyway... Your privacy, at least, possibly also your data. > /Niels /Matti Aarnio -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 20:28:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAM4REZ20228 for ipng-dist; Tue, 21 Nov 2000 20:27:14 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAM4R3j20221 for ; Tue, 21 Nov 2000 20:27:03 -0800 (PST) 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,v1.7) with ESMTP id UAA12860 for ; Tue, 21 Nov 2000 20:27:02 -0800 (PST) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15378 for ; Tue, 21 Nov 2000 20:27:01 -0800 (PST) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id XAA05312; Tue, 21 Nov 2000 23:26:19 -0500 Message-Id: <200011220426.XAA05312@hygro.adsl.duke.edu> To: mankin@east.isi.edu cc: richdr@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: Comments on the Privacy Extensions draft In-Reply-To: Message from Allison Mankin of "Mon, 20 Nov 2000 23:13:34 EST." <10011210413.AA18840@maia.east.isi.edu> Date: Tue, 21 Nov 2000 23:26:19 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Allison. Thanks for the comments. I (and Rich) agree with pretty much all of them. Your comments on Section 2 in particular really improved the document. Here is a breakdown of our response: > Typo > ---- > Sec 3.5 > applications are used by end users. Thus the default value given of > one week (ANON_PREFERRED_LIFETIME) may not be appropriate in all > environments. Implementations should provide end users with the > ability to override both of these default values. > s/ANON_PREFERRED_LIFETIME/ANON_VALID_LIFETIME Done. > Detailed comments > ----------------- > Sec 1 > By design, the interface > identifier is globally unique when generated in this fashion. The > interface identifier is in turn appended to a prefix to form a > 128-bit IPv6 address. > Since RFC2462 doesn't allow counting on the EUI-64 interface id being > unique even on the link (MUST do DAD on the generated link-local > address) this bit of intro is too strong. A more accurate wording would > be: "There is an expectation that the interface identifier > generated in this way will be globally unique, and that this might > be a valuable property for future approaches to hierarchical routing, > as explained in [ADDRARCH]." Or more simply: > s/is globally unique/is likely to be globally unique/ Second suggestion accepted. > described may also apply to interfaces with other types of globally > unique and persistent identifiers. > This is good, but should say "globally unique and/or persistent" Done. > This document discusses concerns associated with the embedding of > non-changing interface identifiers within IPv6 addresses and > describes extensions to stateless address autoconfiguration that can > help mitigate those concerns in environments where such concerns are > significant. > Nit: the last phrase sounds like a diminution of likelihood of > such concerns existing. An alternative phrasing that implies > a bit more concern for privacy: "help mitigate those concerns for > individual users and in environments where such concerns are significant" Done. > Sec 2.1 > serves as a similar identifier. Although the DNS name associated with > an address is more work to obtain (it may require a DNS query) the > information is often readily available. In such cases, changing the > address on a machine over time would do little to address the concern > raised in this document, as the DNS name would become the correlating > identifier. > Instead of the "would do little..." final sentence, which suggests > that anonymous addresses are defeated by inverse DNS, this paragraph > should send with a sentence like "In such cases, nodes using > anonymous addresses might also use some form of anonymous DNS names > (see Section 4)". Wording changed as follows: Although the DNS name associated with an address is more work to obtain (it may require a DNS query) the information is often readily available. In such cases, changing the address on a machine over time would do little to address the concern raised in this document, unless some form of anonymous DNS names were used as well (see Section 4). > Sec 2.2 > Sec 2.2's first paragraph begs for a comparison with the Intel > PIII serial number. It seems to me that it would be best to be > up-front about the problems being comparable. > Sec 2.2 (cont) > Many network services require that the client authenticate itself to > the server before gaining access to a resource. The authentication > step binds the activity (e.g., TCP connection) to a specific entity > (e.g., an end user). In such cases, a server already has the ability > to track usage by an individual, independent of the address they > happen to use. Indeed, such tracking is an important part of > accounting. > This paragraph undercuts the whole purpose of the draft and ought > to be rewritten. Sec 2.2 in fact sends an undercutting message: > becasue identification and tracking goes on, therefore > don't worry about your IP addresses being trackable. A better > message from the section (and one more appropriate to the draft) > would be: don't undermine higher level technologies for improving > the privacy of applications by leaving every packet trackable at > low level. > Examples of attempts to improve privacy at higher level that could > be undercut by trackable packets: > 1. varying one's registrations at a web-based service > 2. rejecting persistent cookies and only allowing session cookies > It is possible to avoid persistent higher level identifiers. People > create changing or multiple identities per site or for different sites. > Even sites where registration is an email address can be given > varied inputs by using multiple free email accounts. Credit card > registration is the subject of a US mandate to go to one-time credit > card numbers. However, all of these kinds of anonymizing are > undermined by having a trackable IP address. Agree on your basic points. Much of this section has been reorganized/rewritten. New text below: 2.2. Address Usage in IPv4 Today Addresses used in today's Internet are often non-changing in practice for extended periods of time, especially in non-home environments (e.g., corporations, campuses, etc.). In such sites, addresses are assigned statically and typically change infrequently. Over the last few years, sites have begun moving away from static allocation to dynamic allocation via DHCP [DHCP]. In theory, the address a client gets via DHCP can change over time, but in practice servers often return the same address to the same client (unless addresses are in such short supply that they are reused immediately by a different node when they become free). Thus, even within sites using DHCP, clients frequently end up using the same address for weeks to months at a time. For home users accessing the Internet over dialup lines, the situation is generally different. Such users do not have permanent connections and are often assigned temporary addresses each time they connect to their ISP (e.g., AOL). Consequently, the addresses they use change frequently over time and are shared among a number of different users. Thus, an address does not reliably identify a particular device over time spans of more than a few minutes. A more interesting case concerns always-on connections (e.g., cable modems, ISDN, DSL, etc.) that result in a home site using the same address for extended periods of time. This is a scenario that is just starting to become common in IPv4 and promises to become more of a concern as always-on internet connectivity becomes widely available. Although it might appear that changing an address regularly in such environments would be desirable to lesson privacy concerns, it should be noted that the network prefix portion of an address also serves as a constant identifier. All nodes at (say) a home, would have the same network prefix, which identifies the topological location of those nodes. This has implications for privacy, though not at the same granularity as the concern that this document addresses. Specifically, all nodes within a home would be grouped together for the purposes of collecting information. This issue is difficult to address, because the routing prefix part of an address contains topology information and cannot contain arbitrary values. Finally, it should be noted that nodes that need a (non-changing) DNS name generally have static addresses assigned to them to simplify the configuration of DNS servers. Although Dynamic DNS [DDNS] can be used to update the DNS dynamically, it is not yet widely deployed. In addition, changing an address but keeping the same DNS name does not really address the underlying concern, since the DNS name becomes a non-changing identifier. Servers generally require a DNS name (so clients can connect to them), and clients often do as well (e.g., some servers refuse to speak to a client whose address cannot be mapped into a DNS name that also maps back into the same address). Section 4 describes one approach to this issue. 2.3. The Concern With IPv6 Addresses The division of IPv6 addresses into distinct topology and interface identifier portions raises an issue new to IPv6 in that a fixed portion of an IPv6 address (i.e., the interface identifier) can contain an identifier that remains constant even when the topology portion of an address changes (e.g., as the result of connecting to a different part of the Internet). In IPv4, when an address changes, the entire address (including the local part of the address) usually changes. It is this new issue that this document addresses. If addresses are generated from an interface identifier, a home user's address could contain an interface identifier that remains the same from one dialup session to the next, even if the rest of the address changes. The way PPP is used today, however, PPP servers typically unilaterally inform the client what address they are to use (i.e., the client doesn't generate one on its own). This practice, if continued in IPv6, would avoid the concerns that are the focus of this document. A more troubling case concerns mobile devices (e.g., laptops, PDAs, etc.) that move topologically within the Internet. Whenever they move (in the absence of technology such as mobile IP [MOBILEIP]), they form new addresses for their current topological point of attachment. This is typified today by the "road warrior" who has Internet connectivity both at home and at the office. While the node's address changes as it moves, however, the interface identifier contained within the address remains the same (when derived from an IEEE Identifier). In such cases, the interface identifier can be used to track the movement and usage of a particular machine [SERIALNUM]. For example, a server that logs usage information together with a source addresses, is also recording the interface identifier since it is embedded within an address. Consequently, any data-mining technique that correlates activity based on addresses could easily be extended to do the same using the interface identifier. This is of particular concern with the expected proliferation of next-generation network- connected devices (e.g., PDAs, cell phones, etc.) in which large numbers of devices are in practice associated with individual users (i.e., not shared). Thus, the interface identifier embedded within an address could be used to track activities of an individual, even as they move topologically within the internet. In summary, IPv6 addresses on a given interface generated via Stateless Autoconfiguration contain the same interface identifier, regardless of where within the Internet the device connects. This facilitates the tracking of individual devices (and thus potentially users). The purpose of this document is to define mechanisms that eliminate this issue, in those situations where it is a concern. > Sec 2.3 > In such environments, one may need multiple addresses: a "public" (i.e., > non-secret) server address, registered in the DNS, that is used to > accept incoming connection requests from other machines, and > (possibly) an "anonymous" address used to shield the identity of the > Nit: sentence already has "may," so why add further distance with > the "(possibly)"? Done. > To make it difficult to make educated guesses as to whether two > different interface identifiers belong to the same node, the > algorithm for generating alternate identifiers must include input > that has an unpredictable component from the perspective of the > outside entities that are collecting information. Picking identifiers > from a pseudo-random sequence suffices, so long as the specific > sequence cannot be determined by an outsider examining just the > identifiers that appear in addresses or are otherwise readily > available (e.g., a node's link-layer address). > It's bad news if the node's link-layer address is "readily > available" to arbitrary remote peers - the last parenthesis > doesn't make sense in this draft about not embedding link-layer > addresses in packet addresses.... Sentence changed as follows: Picking identifiers from a pseudo-random sequence suffices, so long as the specific sequence cannot be determined by an outsider examining information that is readily available or easily determinable (e.g., by examining packet contents) > Sec 3.1 > The algorithm also assumes that for a given anonymous address, one > can determine the corresponding public address. > Who does "one" refer to? I think this sentence must intend to > say "The algorithm also assumes that there is an internal data > structure available to address autoconfiguration matching a given anonymous > address to its corresponding public address", but it can be read > as saying there's an algorithmic conversion from the anonymous > back to the public. The one refers to the "implementation". Fixed. > Finally, this document assumes that when a node initiates outgoing > communication, anonymous addresses can be given preference over other > public addresses. > Delete "other". Done. > This can mean that all outgoing connections use > anonymous addresses by default, or that applications individually > indicate whether they prefer to use anonymous or public addresses. > Replace "outgoing connections" with "connections > initiated by the node". Done. > Mention somewhere that applications > indicating their preference for an anonymous address is one > example of API work that is needed in conjunction with this > spec. Added a paragraph in the "future work" section: The determination as to whether to use public vs. temporary addresses can in some cases only be made by an application. For example, some applications may always want to use temporary addresses, while others may want to use them only in some circumstances or not at all. Suitable API extensions will likely need to be developed to enable individual applications to indicate with sufficient granularity their needs with regards to the use of temporary addresses. > Sec 3.2 > a randomized interface identifier may need to be > generated at random. > Repetitive. > s/at random/without previous state/ Replace sentence with: A second approach addresses the case where stable storage is unavailable and there is a need to generate randomomized interface identifiers without previous state. > Sec 3.5 > This can be achieved automatically by > generating a new randomized interface identifier at least once every > (ANON_PREFERRED_LIFETIME - REGEN_ADVANCE) time units. As described > above, generating a new anonymous address REGEN_ADVANCE time units > before an anonymous address becomes deprecated produces addresses > with a preferred lifetime no larger than ANON_PREFERRED_LIFETIME. > I think this should have the same mechanism of desynchronizing the nodes > that RFC2461 has, because nodes that start up after a power failure > could have their new randomized interface timers synch up and cause > a daily DAD flood. Added a 0 - RANDOM_DELAY component (suggest value of 10 minutes) in the setting of certain timers. > Sec 4 > The IPv6 addressing architecture goes to great lengths to ensure that > interface identifiers are globally unique. > s/great lengths/some lengths/ > s/are globally unique/may be globally unique/ > The sentence is too strong, compared with the address architecture > RFC (even the new i-d). And as before, saying the EUI-64's are > surely globally unique is contradicted by Addrconf requiring DAD > on them. > During the IPng > discussions of the GSE proposal [GSE], it was felt that keeping > interface identifiers globally unique in practice might prove useful > to future transport protocols. Usage of the algorithms in this > document would eliminate that future flexibility. > I disagree that the anonymous addresses would eliminate a GSE-like > future scheme, any more than using any addresses where the u/l bit is > unset is doing so already. There are other ways that a GSE-like > future scheme might be work, for instance, using global interface ids > as input to a cryptographic registry that would return an anonymized > interface id to use in the address. Wording suggestion: > s/eliminate that future flexibility/possibly complicate that future > flexibility/ Paragraph changed to: The IPv6 addressing architecture goes to some lengths to ensure that interface identifiers are likely to be globally unique where easy to do so. During the IPng discussions of the GSE proposal [GSE], it was felt that keeping interface identifiers globally unique in practice might prove useful to future transport protocols. Usage of the algorithms in this document may complicate providing such a future flexibility. > DNS name (if non-changing) serves as a constant identifier. If the > extension described in this document becomes widely deployed, servers > will likely need to change their behavior to not require every > address be in the DNS. Another alternative is to register anonymous > addresses in DNS using random names (for example a string version of > the address itself). > Sweeping changes to server behavior are unlikely/hard to drive. > The prospect of anonymized DNS names (as mentioned next) is better. > Perhaps change the last two sentences to be both more realistic and more > constructive: > The wide deployment of the extension described in this document could > challenge the practice of inverse-DNS-based "authentication," which > is has little validity, though it is widely implemented. In order > to meet server challenges, nodes could register anonymous addresses > in DNS using random names (for example a string version of the > random address itself). Done. > Sec 6 > Use of the extensions defined in this document is likely to make > debugging and other operational troubleshooting activities more > difficult. > Not certain - when the troubleshooting regards nodes that are > in LAN segments controlled by an administrator, it should be > possible to register and identify nodes by their layer 2 addresses > (RMON can give access to that sort of trace). If the troubleshooting > regards distant nodes, it's already the case that the addresses > won't give much help (e.g. in DDos). Reworded (and moved to section 4): Use of the extensions defined in this document may complicate debugging and other operational troubleshooting activities. Consequently, it may be site policy that temporary addresses should not be used. Implementations may provide a method for a trusted administrator to override the use of temporary addresses. A new draft will be submitted shortly. 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 Nov 21 22:54:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAM6r8j20343 for ipng-dist; Tue, 21 Nov 2000 22:53:08 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAM6qxj20336 for ; Tue, 21 Nov 2000 22:53:00 -0800 (PST) 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,v1.7) with ESMTP id WAA24409 for ; Tue, 21 Nov 2000 22:53:00 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA25714 for ; Tue, 21 Nov 2000 23:52:59 -0700 (MST) Received: from ValuedSonyCustomer (as1b-234.chi.il.dial.anet.com [198.92.157.234]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id AAA10585 for ; Wed, 22 Nov 2000 00:46:29 -0600 (CST) Message-ID: <06ab01c05450$0fc72480$df00a8c0@ValuedSonyCustomer> From: "JIM FLEMING" To: References: <200011220034.TAA0000658150@anw.zk3.dec.com> Subject: Federal Trade Commission...examine emerging wireless Internet and data technologies and the privacy, security, and consumer protection issues they raise... Date: Wed, 22 Nov 2000 00:47:18 -0600 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk http://www.ftc.gov/opa/2000/11/wireless.htm http://www.ftc.gov/os/2000/11/wirelesswrkshp.htm "SUMMARY: The Federal Trade Commission ("Commission") has set December 11-12, 2000 as the dates for a public workshop examining emerging wireless Internet and data technologies and the privacy, security, and consumer protection issues they raise." @@@@@@@@@@@@@@@@@@@@@ Jim Fleming http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 22 02:09:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAMA7bF20492 for ipng-dist; Wed, 22 Nov 2000 02:07:37 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAMA7Qj20485 for ; Wed, 22 Nov 2000 02:07:26 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA09677 for ; Wed, 22 Nov 2000 02:07:26 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21014 for ; Wed, 22 Nov 2000 02:07:25 -0800 (PST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id XC97BJ4K; Wed, 22 Nov 2000 11:07:24 +0100 Reply-To: From: "Thomas Eklund" To: "'Jim Bound'" Cc: "'Alex Conta'" , "'Ipng \(E-Mail\)'" Subject: RE: Usage of IPv6 flow label Date: Wed, 22 Nov 2000 11:07:07 +0100 Message-ID: <31A473DBB655D21180850008C71E251A02949291@mail.kebne.se> 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) In-Reply-To: <31A473DBB655D21180850008C71E251A02F3CC60@mail.kebne.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, > Because the diff serv bits are too precious rather take one > from 20 than > the few left in tos/class. But I am not convinced this is the correct > technical answer but might be the only answer. I got at least 4 > different inputs in the customer base for four different uses of the > flowlabel. But the good news is the needs all aggregate to I hope two > solutions we are discussing now. I still dont understand what the ECN bits have to do with the flowlabel, and as I said the most way of using the ecn bits have been in the 2 unassigned bits in the TC field, which makes sense because the DSCP are 6 bits and that leaves the room to use the remaining two bits in that field.. This clearly shows that there is time now for standadizing the flow label field and semantics so we dont have XXX different ways of using it. > Think I answered above on why not the tos/class field. Sorry - i did not understand your concerns 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 Wed Nov 22 03:05:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAMB43o20552 for ipng-dist; Wed, 22 Nov 2000 03:04:03 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAMB3qj20545 for ; Wed, 22 Nov 2000 03:03:53 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA10803 for ; Wed, 22 Nov 2000 03:03:52 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27088 for ; Wed, 22 Nov 2000 03:03:52 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19638; Wed, 22 Nov 2000 06:03:49 -0500 (EST) Message-Id: <200011221103.GAA19638@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-ion-ipv6-ind-05.txt Date: Wed, 22 Nov 2000 06:03:48 -0500 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 IPNG Working Group of the IETF. Title : Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification Author(s) : A. Conta Filename : draft-ietf-ion-ipv6-ind-05.txt Pages : 22 Date : 21-Nov-00 This memo describes extensions to the IPv6 Neighbor Discovery that allow a node to determine and advertise an IPv6 address corresponding to a given link-layer address. These extensions are called Inverse Neighbor Discovery. The Inverse Neighbor Discovery (IND) was originally developed for Frame Relay networks, but may also apply to other networks with similar behavior. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ion-ipv6-ind-05.txt 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-ion-ipv6-ind-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ion-ipv6-ind-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001121110829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-ipv6-ind-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-ipv6-ind-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001121110829.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 Nov 22 04:13:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAMCC1L20626 for ipng-dist; Wed, 22 Nov 2000 04:12:01 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAMCBqj20619 for ; Wed, 22 Nov 2000 04:11:52 -0800 (PST) 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,v1.7) with ESMTP id EAA13307 for ; Wed, 22 Nov 2000 04:11:51 -0800 (PST) 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 EAA15989 for ; Wed, 22 Nov 2000 04:11:50 -0800 (PST) Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA23070 for ; Wed, 22 Nov 2000 12:11:45 GMT Received: from penelope (penelope [152.78.68.135]) by penelope.ecs.soton.ac.uk (8.9.1a/8.9.1) with ESMTP id MAA16101 for ; Wed, 22 Nov 2000 12:11:45 GMT Date: Wed, 22 Nov 2000 12:11:43 +0000 (GMT) From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: RE: default router selection based on network topology In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA80130C96D@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 On Thu, 16 Nov 2000, Richard Draves wrote: > OK, I just submitted the promised draft on this topic... > If you'd like to check it out early, you can find it here: > > ftp://ftp.research.microsoft.com/users/richdr/draft-draves-ipngwg-router-sel > ection-00.txt > > Comments welcome! It seems that the subject of routers giving hints to hosts as to best routes off a network is tied in very closely with the issue of source address selection in a multihomed environment. Do you intend expanding the scope of the document to suggest what happens (for example) if the RA preference and src/dst selection algorithm happen to give conflicting suggestions for source address? I'm also interested in just how the routers will be configured to make the advertisements, as it would seem this would impact the router renumbering process? 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 Wed Nov 22 08:39:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAMGbRV20796 for ipng-dist; Wed, 22 Nov 2000 08:37:27 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAMGbIj20789 for ; Wed, 22 Nov 2000 08:37:18 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA13929 for ; Wed, 22 Nov 2000 08:37:18 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01230 for ; Wed, 22 Nov 2000 09:37:16 -0700 (MST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA42440; Wed, 22 Nov 2000 08:34:12 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA24378; Wed, 22 Nov 2000 08:37:12 -0800 Message-ID: <3A1BF606.8FEFE60A@hursley.ibm.com> Date: Wed, 22 Nov 2000 10:36:22 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Alex Conta CC: Steve Deering , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <20001115190919.321B17EF9@starfruit.itojun.org> <200011160958.KAA90047@givry.rennes.enst-bretagne.fr> <14867.59850.899996.178063@thomasm-u1.cisco.com> <3A142DEE.AA44B45F@txc.com> <3A1584F1.79185912@txc.com> <3A15B6B2.D29AAED@txc.com> <3A19A76B.3DA48095@hursley.ibm.com> <3A1B0AD7.C1EB94AD@txc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I didn't imply, or mean to imply, that the flow label is well defined. That doesn't prevent it being orthogonal. Brian Alex Conta wrote: > > Brian, > > Please re-examine. My point was that both Diffserv, and MPLS, deal with > QoS topics, as the IPv6 flow label does. Therefore, orthogonality, if I > understand you correctly, as independence from each other, and the rest, > has little relevance to my point. > > In contradiction to earlier calls, and statements on this list, your > message seem to suggest that the flow label is well defined, and its > role well determined... If that is the case, I should say I am sorry: > this is rather a waste of everybody's time.... > > Alex > > Brian E Carpenter wrote: > > > > Alex, > > > > Alex Conta wrote: > > > > > > Since the IPv6 flow label work started, two major efforts in IETF made > > > significant progress on related topics: Diffserv and MPLS. > > > > Steve's already said this but I want to say it again: no! > > > > The Flow Label is totally orthogonal to diffserv, which has no need > > of it, since it has its own mutable 6-bit field (more than enough). > > > > The Flow Label is totally orthogonal to the MPLS Shim, which is at a lower > > layer and is edge-to-edge, not end-to-end. > > > > As has been observed, the Flow Label is accommodated neatly by the IntServ > > model. > > > > 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 Nov 22 09:45:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAMHd9i20852 for ipng-dist; Wed, 22 Nov 2000 09:39:10 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAMHd5j20845 for ; Wed, 22 Nov 2000 09:39:05 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id eAMHc0B06278 for ipng@sunroof.eng.sun.com; Wed, 22 Nov 2000 09:38:00 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAMDi6j20648 for ; Wed, 22 Nov 2000 05:44:07 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA20404 for ; Wed, 22 Nov 2000 05:44:08 -0800 (PST) From: lassi.hippelainen@nokia.com Received: from esebh02nok.ntc.nokia.com (esebh02nok.ntc.nokia.com [131.228.118.151]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA22990 for ; Wed, 22 Nov 2000 05:44:06 -0800 (PST) Received: by esebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 22 Nov 2000 15:44:04 +0200 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE102551834@eseis04nok> To: ipng@sunroof.eng.sun.com Subject: Security considerations about the flow label Date: Wed, 22 Nov 2000 15:43:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear list, sorry to stir the hornet's nest about end-to-end flow labels, but I think there are some security problems in them. First, the labels are excluded from the IPSec AH, which means they cannot be trusted. I wouldn't build a service that is based on them, unless there is some other way to make them trustworthy. Like keeping the server and the client within the same administrative domain. Another problem is a covert channel. If a client can set the flow label bits, it can communicate with the outside world without anybody noticing. I don't mean just transmitting payload without paying for it. There are spy programs, too. Don't-care bits should not cross a security perimeter. All header fields that are not protected by the IPSec AH should be overwritten by edge routers. Either by something neutral (like zeroes for flow label) or values that have been agreed with the peering domain (DiffServ Code Points). I vote for edge-to-edge flow labels, not end-to-end. -- Lassi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 22 11:49:02 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAMJlPq20953 for ipng-dist; Wed, 22 Nov 2000 11:47:25 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAMJlGj20946 for ; Wed, 22 Nov 2000 11:47:16 -0800 (PST) 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,v1.7) with ESMTP id LAA02542 for ; Wed, 22 Nov 2000 11:47:15 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA01828 for ; Wed, 22 Nov 2000 11:47:12 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 22 Nov 2000 11:46:20 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Wed, 22 Nov 2000 11:45:48 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9BDC@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "'Tim Chown'" Cc: ipng@sunroof.eng.sun.com Subject: RE: default router selection based on network topology Date: Wed, 22 Nov 2000 09:46:30 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It seems that the subject of routers giving hints to hosts as to best > routes off a network is tied in very closely with the issue of source > address selection in a multihomed environment. > > Do you intend expanding the scope of the document to suggest what happens > (for example) if the RA preference and src/dst selection algorithm happen > to give conflicting suggestions for source address? Hmm. I don't see the connection. The RA preferences are for router selection, not source address selection. Are you suggesting that the two should be connected somehow? > I'm also interested in just how the routers will be configured to make > the advertisements, as it would seem this would impact the router > renumbering process? My first thought is that this should not impact router renumbering. Router renumbering is about making configuration changes uniformly across a set of routers, while the advertisement of default router preferences & more-specific routes is very topology dependent. I think it's something that an administrator would need to selectively configure on relatively few routers, not configure uniformly across a site. 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 Wed Nov 22 12:24:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAMKMWO20997 for ipng-dist; Wed, 22 Nov 2000 12:22:32 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAMKMGj20990 for ; Wed, 22 Nov 2000 12:22:17 -0800 (PST) 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,v1.7) with ESMTP id MAA10703 for ; Wed, 22 Nov 2000 12:22:15 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA06025 for ; Wed, 22 Nov 2000 13:22:14 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24638; Wed, 22 Nov 2000 15:22:10 -0500 (EST) Message-Id: <200011222022.PAA24638@ietf.org> To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: The IESG SUBJECT: Last Call: IP Version 6 Addressing Architecture to Draft Standard Reply-to: iesg@ietf.org Date: Wed, 22 Nov 2000 15:22:10 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider IP Version 6 Addressing Architecture as a Draft Standard, replacing RFC2373, currently a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits7 final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by December 6, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-02.txt The Implementation Report can be found at http://www.ietf.org/IESG/Implementations/address-architecture.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 Wed Nov 22 12:52:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAMKhWu21038 for ipng-dist; Wed, 22 Nov 2000 12:43:32 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAMKh6j21031 for ; Wed, 22 Nov 2000 12:43:09 -0800 (PST) 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,v1.7) with ESMTP id MAA16069 for ; Wed, 22 Nov 2000 12:43:02 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA18166 for ; Wed, 22 Nov 2000 12:35:33 -0800 (PST) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 22 Nov 2000 12:35:32 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Wed, 22 Nov 2000 12:35:32 -0800 Message-ID: From: Brian Zill To: "'lassi.hippelainen@nokia.com'" , ipng@sunroof.eng.sun.com Subject: RE: Security considerations about the flow label Date: Wed, 22 Nov 2000 12:35:04 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't follow your logic here. You say you want edge-to-edge flow labels, not end-to-end, yet complain that flow labels are not secure since they are not covered by AH IPsec. If they were covered by AH ipsec, then they would be secure end-to-end, not edge-to-edge. We have no mechanism to secure things edge-to-edge (unless you're counting on all edges being security gateways with all "inside" traffic existing in IPsec tunnels). I also don't understand your concerns regarding a covert channel. Since IPsec is secure end-to-end, the trust is in the end hosts. Of course they can send whatever data they want encrypted and hide it from things in the middle. This is a feature. If the worry is that routers along the way can piggy-back a covert channel, there are many other ways to do that. They can play games with the Hop Count, for one. Or in packets that contain at least one Hop-by-Hop or Destination Option, they can add another one of their own invention with the upper bits set to 001 so it will be skipped over by routers that don't understand it and treated as mutable by AH. --Brian > -----Original Message----- > From: lassi.hippelainen@nokia.com [mailto:lassi.hippelainen@nokia.com] > Sent: Wednesday, 22 November, 2000 05:44 > To: ipng@sunroof.eng.sun.com > Subject: Security considerations about the flow label > > > Dear list, > > sorry to stir the hornet's nest about end-to-end flow > labels, but I think there are some security problems > in them. > > First, the labels are excluded from the IPSec AH, > which means they cannot be trusted. I wouldn't build > a service that is based on them, unless there is some > other way to make them trustworthy. Like keeping the > server and the client within the same administrative > domain. > > Another problem is a covert channel. If a client can > set the flow label bits, it can communicate with the > outside world without anybody noticing. I don't mean > just transmitting payload without paying for it. > There are spy programs, too. > > Don't-care bits should not cross a security perimeter. > All header fields that are not protected by the IPSec > AH should be overwritten by edge routers. Either by > something neutral (like zeroes for flow label) or > values that have been agreed with the peering domain > (DiffServ Code Points). > > I vote for edge-to-edge flow labels, not end-to-end. > > -- Lassi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 22 15:05:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAMN3Nd21116 for ipng-dist; Wed, 22 Nov 2000 15:03:23 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAMN3Ej21109 for ; Wed, 22 Nov 2000 15:03:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA20091 for ; Wed, 22 Nov 2000 15:03:15 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02081 for ; Wed, 22 Nov 2000 16:03:14 -0700 (MST) Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA29587; Wed, 22 Nov 2000 23:03:12 GMT Received: from penelope (penelope [152.78.68.135]) by penelope.ecs.soton.ac.uk (8.9.1a/8.9.1) with ESMTP id XAA03799; Wed, 22 Nov 2000 23:03:11 GMT Date: Wed, 22 Nov 2000 23:03:11 +0000 (GMT) From: Tim Chown To: Richard Draves cc: ipng@sunroof.eng.sun.com Subject: RE: default router selection based on network topology In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA81C9BDC@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 On Wed, 22 Nov 2000, Richard Draves wrote: > Hmm. I don't see the connection. The RA preferences are for router > selection, not source address selection. Are you suggesting that the two > should be connected somehow? Would you always pick a longest match for source address over the RA that had the best preference? For example in the selection draft you say "For example, suppose a node has interfaces on two different links, with both links having a working default router. Both of the interfaces have preferred global addresses. When sending to a global destination address, if there's no routing reason to prefer one interface over the other, then an implementation MAY preferentially choose the outgoing interface that will allow it to use the source address that shares a longer common prefix with the destination." The RAs now convey "routing reasons", which affect the selection (in that without them, another choice might be made). Of course, this may be exactly want you want, but I suspect the common "multihomed" scenario at present is sites with a 2001: link and a 3ffe: link, one of which is probably much better than the other, even though both may route happily anywhere. > > I'm also interested in just how the routers will be configured to make > > the advertisements, as it would seem this would impact the router > > renumbering process? > > My first thought is that this should not impact router renumbering. Router > renumbering is about making configuration changes uniformly across a set of > routers, while the advertisement of default router preferences & > more-specific routes is very topology dependent. I think it's something that > an administrator would need to selectively configure on relatively few > routers, not configure uniformly across a site. The question is how deeply the "topologically dependent" changes are made by the administrator through the network. Having manually configured preferences in the config file only adds to the list of things that (might) need changing if the network is renumbered, or a network you're giving a preference to is renumbered? I appreciate there are other issues such as IOS access lists and of course IPs embedded in host configs. How realistic a goal is (relatively) transparent renumbering? 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 Wed Nov 22 15:56:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAMNsuZ21208 for ipng-dist; Wed, 22 Nov 2000 15:54:56 -0800 (PST) Received: from ebaymail2.EBay.Sun.COM (ebaymail2.EBay.Sun.COM [129.150.111.20]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAMNsmj21201 for ; Wed, 22 Nov 2000 15:54:48 -0800 (PST) Received: from domus.ebay.sun.com (domus.EBay.Sun.COM [129.150.113.143]) by ebaymail2.EBay.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA20125; Wed, 22 Nov 2000 15:54:48 -0800 (PST) Received: from amal (amal [129.150.113.131]) by domus.ebay.sun.com (Trusted Solaris (8.9.3)/8.9.3) with SMTP id PAA21784; Wed, 22 Nov 2000 15:54:43 -0800 (PST) Message-Id: <200011222354.PAA21784@domus.ebay.sun.com> Date: Wed, 22 Nov 2000 15:54:45 -0800 (PST) From: Kais Belgaied Reply-To: Kais Belgaied Subject: RE: Security considerations about the flow label To: lassi.hippelainen@nokia.com, ipng@sunroof.eng.sun.com, bzill@microsoft.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: GlsMiSiRu1gzkXZUGxuXjA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.1 SunOS 5.8 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >I also don't understand your concerns regarding a covert channel. Since >IPsec is secure end-to-end, the trust is in the end hosts. Of course they >can send whatever data they want encrypted and hide it from things in the >middle. This is a feature. If the worry is that routers along the way can >piggy-back a covert channel, there are many other ways to do that. They can >play games with the Hop Count, for one. Or in packets that contain at least >one Hop-by-Hop or Destination Option, they can add another one of their own >invention with the upper bits set to 001 so it will be skipped over by >routers that don't understand it and treated as mutable by AH. I think the tiny covert channel meant is that one of the end hosts leaking out (intentionally or being exploited by a malicious insider) information using a field not covered by IPSec's protection, and tries to do so without being noticed. The recipient of the leaked info is not necessary the other end host (trusted). Messing with the hop count may work, but, due to non predictible re-routes, it is not reliable for the spy who cares about the integrity of the data being leaked. Mutable h-b-h or dest1 options could also be exploited, but, again, they are mutable, and may mean something to routers in between and get altered. Kais. > >--Brian > >> -----Original Message----- >> From: lassi.hippelainen@nokia.com [mailto:lassi.hippelainen@nokia.com] >> Sent: Wednesday, 22 November, 2000 05:44 >> To: ipng@sunroof.eng.sun.com >> Subject: Security considerations about the flow label >> >> >> Dear list, >> >> sorry to stir the hornet's nest about end-to-end flow >> labels, but I think there are some security problems >> in them. >> >> First, the labels are excluded from the IPSec AH, >> which means they cannot be trusted. I wouldn't build >> a service that is based on them, unless there is some >> other way to make them trustworthy. Like keeping the >> server and the client within the same administrative >> domain. >> >> Another problem is a covert channel. If a client can >> set the flow label bits, it can communicate with the >> outside world without anybody noticing. I don't mean >> just transmitting payload without paying for it. >> There are spy programs, too. >> >> Don't-care bits should not cross a security perimeter. >> All header fields that are not protected by the IPSec >> AH should be overwritten by edge routers. Either by >> something neutral (like zeroes for flow label) or >> values that have been agreed with the peering domain >> (DiffServ Code Points). >> >> I vote for edge-to-edge flow labels, not end-to-end. >> >> -- Lassi >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Nov 23 06:12:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eANEBPG21500 for ipng-dist; Thu, 23 Nov 2000 06:11:25 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eANEBHj21493 for ; Thu, 23 Nov 2000 06:11:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA23292 for ; Thu, 23 Nov 2000 06:11:17 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA24592 for ; Thu, 23 Nov 2000 07:11:16 -0700 (MST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 23 Nov 2000 06:11:15 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58) id ; Thu, 23 Nov 2000 06:11:15 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9BE0@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "'Tim Chown'" Cc: ipng@sunroof.eng.sun.com Subject: RE: default router selection based on network topology Date: Wed, 22 Nov 2000 17:00:06 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Would you always pick a longest match for source address over the RA > that had the best preference? > > For example in the selection draft you say > > "For example, suppose a node has interfaces on two different links, > with both links having a working default router. Both of the > interfaces have preferred global addresses. When sending to a global > destination address, if there's no routing reason to prefer one > interface over the other, then an implementation MAY preferentially > choose the outgoing interface that will allow it to use the source > address that shares a longer common prefix with the destination." > > The RAs now convey "routing reasons", which affect the > selection (in that > without them, another choice might be made). I'm still not understanding your scenario. The paragraph you qoute above is a suggestion of how source address selection concerns *might* be used to influence the choice of router. (I don't think it's a great idea but I wanted to discuss it in the draft.) Whereas I think you're asking about the other direction - how will the routing preferences influence source address selection. The answer is simple: the routing preferences influence the choice of sending interface, and that strongly influences source address selection. > Of course, this may be exactly want you want, but I suspect the common > "multihomed" scenario at present is sites with a 2001: link > and a 3ffe: > link, one of which is probably much better than the other, even though > both may route happily anywhere. OK. Suppose a host has two interfaces. On Interface 1, it receives RAs advertising a 2001 prefix. Interface 1 is better for reaching 2001 destinations. On Interface 2, it receives RAs advertising a 3ffe prefix. Interface 2 is better for reaching 3ffe destinations. The host has a default route on interface 1 and a default route on interface 2. Now the host is sending to a 2001 destination. This is a situation where the paragraph you qouted applies. An implementation might choose the default router on interface 1 (the "right" answer), by looking at its autoconfigured addressses on the two interfaces and realizing that it has a "better" source address on interface 1. Now, suppose the router on interface 1 advertises a more specific route for 2001::/16 and the router on interface 2 advertises a more specific route for 3ffe::/16. Now the routing table will select the "right" interface - it doesn't need any help from source address selection. I think this is a better approach. Which is why I've implemented it and not implemented the quoted paragraph. > > > I'm also interested in just how the routers will be > configured to make > > > the advertisements, as it would seem this would impact the router > > > renumbering process? > > > > My first thought is that this should not impact router > renumbering. Router > > renumbering is about making configuration changes uniformly > across a set of > > routers, while the advertisement of default router preferences & > > more-specific routes is very topology dependent. I think > it's something that > > an administrator would need to selectively configure on > relatively few > > routers, not configure uniformly across a site. > > The question is how deeply the "topologically dependent" > changes are made > by the administrator through the network. Having manually configured > preferences in the config file only adds to the list of > things that (might) > need changing if the network is renumbered, or a network > you're giving a > preference to is renumbered? I appreciate there are other > issues such as > IOS access lists and of course IPs embedded in host configs. > How realistic > a goal is (relatively) transparent renumbering? Consider an enterprise with 100 routers. I certainly do not imagine an administrator will be going into each of those routers' config and individually tweaking advertised router preferences and routes. Maybe an administrator might have a policy like here's a specific /16 or /48 route that I want to advertise in RAs, and it would be nice to update this prefix across a bunch of routers. I imagine an extension of router renumbering could handle this. 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 Fri Nov 24 02:49:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAOAm6G21848 for ipng-dist; Fri, 24 Nov 2000 02:48:06 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAOAluj21841 for ; Fri, 24 Nov 2000 02:47:57 -0800 (PST) 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,v1.7) with ESMTP id CAA09081 for ; Fri, 24 Nov 2000 02:47:56 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA11131 for ; Fri, 24 Nov 2000 02:47:55 -0800 (PST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 24 Nov 2000 02:47:52 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58) id ; Fri, 24 Nov 2000 02:47:39 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80146961F@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "IPng List (E-mail)" Subject: draft-ietf-ipngwg-default-addr-select-02 Date: Fri, 24 Nov 2000 01:07:58 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just submitted this revision: ftp://ftp.research.microsoft.com/users/richdr/draft-ietf-ipngwg-default-addr -select-02.txt It is a fairly substantial revision, so if you haven't reviewed this draft recently now would be a good time. The main changes are: Added Examples section, demonstrating default behavior and some policy table configuration scenarios. Removed many uses of MUST. Remaining uses concern the candidate set of source addresses and the source address selection rule that prefers source addresses of appropriate scope. Simplified the default policy table. Reordered the source address selection rules to reduce the influence of policy labels. Added more destination address selection rules. Added scoping of v4-compatible and 6to4 addresses based on the embedded IPv4 address. Changed references to anonymous addresses to use the new term, temporary addresses. Clarified that a user-level implementation of destination address ordering, which does not have knowledge of the outgoing interface for each destination, may use a looser definition of the candidate set. Clarified that an implementation should prevent an application or upper-layer from choosing a source address that is not in the candidate set and not prevent an application or upper-layer from choosing a source address that is in the candidate set. Miscellaneous editorial changes, including adding some missing references. If you feel you've contributed to the draft, please let me know so I can add you to the acknowledgments section. As usual, comments & discussion are welcome. Thanks, 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 Fri Nov 24 03:32:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAOBVMs21880 for ipng-dist; Fri, 24 Nov 2000 03:31:22 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAOBVDj21873 for ; Fri, 24 Nov 2000 03:31:13 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA11090 for ; Fri, 24 Nov 2000 03:31:13 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA17980 for ; Fri, 24 Nov 2000 03:31:06 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id eAOBTeE02640; Fri, 24 Nov 2000 18:29:40 +0700 (ICT) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Robert Elz To: Richard Draves cc: "'Tim Chown'" , ipng@sunroof.eng.sun.com Subject: Re: default router selection based on network topology In-reply-to: Your message of "Wed, 22 Nov 2000 17:00:06 PST." <7695E2F6903F7A41961F8CF888D87EA81C9BE0@red-msg-06.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Nov 2000 18:29:40 +0700 Message-ID: <2638.975065380@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 22 Nov 2000 17:00:06 -0800 From: Richard Draves Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9BE0@red-msg-06.redmond.corp.microsoft.com> | > The RAs now convey "routing reasons", which affect the | > selection (in that | > without them, another choice might be made). | | I'm still not understanding your scenario. I think what Tim is getting at is that different source addresses may be chosen with the router preferences than without. I don't think this is an issue at all - the routing table has always influenced source address selection, all the draft in question does is alter the way the routing table is built. On the other hand, I don't think the effects of more config in routers is something to be swept under the table - that, in co-ordination with router renumbering does need some work. It may be as simple as noting that when router renumbering causes a prefix to be altered, and that prefix is in the router preference list, then it should be altered there as well. But I haven't thought that through. 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 Nov 24 06:20:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAOEJ1j21926 for ipng-dist; Fri, 24 Nov 2000 06:19:01 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAOEIqj21919 for ; Fri, 24 Nov 2000 06:18:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA13520; Fri, 24 Nov 2000 06:18:47 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA08726; Fri, 24 Nov 2000 06:18:28 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAOEIPb41845; Fri, 24 Nov 2000 15:18:25 +0100 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 PAA25053; Fri, 24 Nov 2000 15:18:24 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id PAA29396; Fri, 24 Nov 2000 15:21:24 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011241421.PAA29396@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mohan Parthasarathy cc: ipng@sunroof.eng.sun.com Subject: Re: draft-dupont-destoptupd-00.txt In-reply-to: Your message of Mon, 20 Nov 2000 09:40:31 PST. <200011201740.eAKHeVI09621@locked.eng.sun.com> Date: Fri, 24 Nov 2000 15:21:24 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: In section 4, you tried giving names to the various option headers and i think it can be a bit more clearer. How about the following : 1) The option header before routing header (called as destination options (1) in rfc2460) can be called as routing option header as this appears only with routing header. => I am afraid that people will be confused by routing header and routing option header names. 2) The new place that occurs between routing header and fragment header can be called as Intermediate option header. => I'd like to keep the destionation option header name and (more important) type for this. 3) The final one that appears after IPsec can be called as Destination option header. => 3) options are mobility new options (others are 2), there is no defined 1) option) then a new type for this will minimize the impact on interoperability. They all can have different types assigned by IANA to keep it simple. => this is the important point. Implementors at the ETSI bake-off *required* this. In section (5), you have argued that mutable options existing after the routing header does not make sense. => yes, the argument is nobody should change them... But with tunnel encapsulation limit present in the intrmediate position, the limit needs change as it passes through tunnels. So, it is mutable. Could you clarify ? => tunnel encapsulation limit is not mutable, the option is copied and the limit decremented in the new encapsulation stuff, the old option is kept as it until it is decapsulated. This option is not commonly used because most implementors don't want to chase for it in all packets (this is an expensive operation, and in some cases impossible). But this option is still a good solution to a very common configuration error and I'd like to make this alive again... 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 Fri Nov 24 08:02:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAOFxn422008 for ipng-dist; Fri, 24 Nov 2000 07:59:49 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAOFxSj22001 for ; Fri, 24 Nov 2000 07:59:30 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA27576 for ; Fri, 24 Nov 2000 07:59:27 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11700 for ; Fri, 24 Nov 2000 07:59:25 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAOFsVb39086; Fri, 24 Nov 2000 16:54:32 +0100 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 QAA28863; Fri, 24 Nov 2000 16:54:30 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id QAA29940; Fri, 24 Nov 2000 16:57:28 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011241557.QAA29940@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jim Bound cc: Alex Conta , Steve Deering , Michael Thomas , Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of Tue, 21 Nov 2000 00:18:15 EST. <200011210518.AAA0000564672@anw.zk3.dec.com> Date: Fri, 24 Nov 2000 16:57:27 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: the flow label should be guranteed e-2-e. clients should set it. routers should leave it alone. => I agree but in the real word IntServ stuff (then flow label marking) is done by an edge router. If doesn't matter if the LAN is fast enough (and it can be without too much money) and if clients and edge routers collaborate. 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 Nov 24 11:00:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAOIxUX22197 for ipng-dist; Fri, 24 Nov 2000 10:59:30 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAOIxJj22190 for ; Fri, 24 Nov 2000 10:59:19 -0800 (PST) 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,v1.7) with ESMTP id KAA02682 for ; Fri, 24 Nov 2000 10:59:19 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA11629 for ; Fri, 24 Nov 2000 10:59:17 -0800 (PST) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 24 Nov 2000 10:59:09 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Fri, 24 Nov 2000 10:58:36 -0800 Message-ID: From: Brian Zill To: "'Kais Belgaied'" , lassi.hippelainen@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: Security considerations about the flow label Date: Fri, 24 Nov 2000 10:58:13 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think the tiny covert channel meant is that one of > the end hosts leaking out (intentionally or being > exploited by a malicious insider) information using > a field not covered by IPSec's protection, and tries > to do so without being noticed. The recipient of the > leaked info is not necessary the other end host (trusted). Okay, I can understand this concern. Unfortunately, malicious insiders are very hard to protect against. Those end nodes essentially become untrusted. Untrusted nodes can do all sorts of unsavory things. I don't think this covert channel issue is something we need to worry about when debating how to define the flow label. [The rest of this message is just an academic exercise] > Messing with the hop count may work, but, due to > non predictible re-routes, it is not reliable for the spy > who cares about the integrity of the data being leaked. I suspect you would find that in practice the upper two or three bits of the hop count never change over the life of most connections. With a little bit of error correction, you could probably get a decent (albeit low bit rate) data channel over that. > Mutable h-b-h or dest1 options could also be exploited, > but, again, they are mutable, and may mean something to > routers in between and get altered. Ah, you missed my point about setting the option type bits appropriately. You could invent your own option with a new type code (so no intervening routers will mess with it) and set the upper bits to 00, causing nodes that don't understand this type to just skip over the option instead of dropping the packet or flagging an error. I thought of a different flaw with this scheme after sending that, however. While AH can be told to treat this new option as mutable, it still includes the option in the ICV calculation (as all zeroes). So if it is added after the ICV calculation on the sending side, then the receiving covert entity on/near the other end would have to strip out this option before it made it to it the intended receiver. But if the malicious insider can add the option before the ICV is calculated (and marks it mutable), then the covert receiver could just read it (and wipe the bits if it cared to) before the intended receiver saw the packet. --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 Nov 24 15:58:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAONuln22436 for ipng-dist; Fri, 24 Nov 2000 15:56:47 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAONuaj22429 for ; Fri, 24 Nov 2000 15:56:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA03299 for ; Fri, 24 Nov 2000 15:56:37 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28536 for ; Fri, 24 Nov 2000 15:56:36 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01049; Fri, 24 Nov 2000 18:56:32 -0500 (EST) Message-Id: <200011242356.SAA01049@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-prefix-rr-disc-00.txt Date: Fri, 24 Nov 2000 18:56:31 -0500 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 IPNG Working Group of the IETF. Title : Discovery of Resource Records Designating IPv6 Address prefixes Author(s) : M. Crawford Filename : draft-ietf-ipngwg-prefix-rr-disc-00.txt Pages : 4 Date : 22-Nov-00 The A6 resource record type [A6] was introduced to store IPv6 addresses in a manner which facilitates prefix changes and assignment of addresses from multiple prefixes. In order to allow use of dynamic DNS updates while still respecting whatever prefix hierarchy may be in use in a site's A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-prefix-rr-disc-00.txt 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-prefix-rr-disc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-prefix-rr-disc-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: <20001122145525.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-prefix-rr-disc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-prefix-rr-disc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001122145525.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 Nov 24 23:42:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAP7eTp22655 for ipng-dist; Fri, 24 Nov 2000 23:40:29 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAP7eKj22648 for ; Fri, 24 Nov 2000 23:40:20 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA19987 for ; Fri, 24 Nov 2000 23:40:21 -0800 (PST) Received: from web1001.mail.yahoo.com (web1001.mail.yahoo.com [128.11.23.91]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA14820 for ; Fri, 24 Nov 2000 23:40:21 -0800 (PST) Received: (qmail 22115 invoked by uid 60001); 25 Nov 2000 07:40:21 -0000 Message-ID: <20001125074021.22114.qmail@web1001.mail.yahoo.com> Received: from [213.29.206.8] by web1001.mail.yahoo.com; Fri, 24 Nov 2000 23:40:21 PST Date: Fri, 24 Nov 2000 23:40:21 -0800 (PST) From: shahram tabandeh Subject: IP length To: ipng@sunroof.eng.sun.com Cc: tabandeh@parsiannet.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear all friends I’m working about IP over ATM, I need some statistical Information about IP packet lengths. Do you have curves of IP length probability distribution function (PDF) for the IPv4 and IPv6 packets who are transferred in a general network? Thanks all Shahram Tabandeh __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.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 Nov 25 10:27:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAPIOvj22909 for ipng-dist; Sat, 25 Nov 2000 10:24:57 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAPIOmj22902 for ; Sat, 25 Nov 2000 10:24:48 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA08988 for ; Sat, 25 Nov 2000 10:24:48 -0800 (PST) Received: from audrey.enst-bretagne.fr (audrey.enst-bretagne.fr [192.108.115.9]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19207 for ; Sat, 25 Nov 2000 10:24:47 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by audrey.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAPIO9637029; Sat, 25 Nov 2000 19:24:09 +0100 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 TAA07490; Sat, 25 Nov 2000 19:22:51 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA38217; Sat, 25 Nov 2000 19:25:57 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011251825.TAA38217@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: shahram tabandeh cc: ipng@sunroof.eng.sun.com, tabandeh@parsiannet.com Subject: Re: IP length In-reply-to: Your message of Fri, 24 Nov 2000 23:40:21 PST. <20001125074021.22114.qmail@web1001.mail.yahoo.com> Date: Sat, 25 Nov 2000 19:25:57 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just cited by Jayant Shukla (?) on the IPsec mailing list (with an argument about the overhead of IPsec tunnel mode for IPv6): http://isglabs.rainbow.com/rsa99/sld007.htm 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 Nov 25 13:41:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAPLdBU23033 for ipng-dist; Sat, 25 Nov 2000 13:39:11 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAPLcxj23026 for ; Sat, 25 Nov 2000 13:38:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA15051 for ; Sat, 25 Nov 2000 13:38:58 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25986 for ; Sat, 25 Nov 2000 13:38:58 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA61478; Sat, 25 Nov 2000 13:34:57 -0800 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA29466; Sat, 25 Nov 2000 13:38:56 -0800 Message-ID: <3A200B12.DF9E71F4@hursley.ibm.com> Date: Sat, 25 Nov 2000 12:55:14 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jim Bound CC: "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <200011241557.QAA29940@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, It still isn't clear to me what the flow label adds to the semantics used by existing 5-tuple QOS classifiers. Brian Francis Dupont wrote: > > In your previous mail you wrote: > > the flow label should be guranteed e-2-e. clients should set it. > routers should leave it alone. > > => I agree but in the real word IntServ stuff (then flow label marking) > is done by an edge router. If doesn't matter if the LAN is fast enough > (and it can be without too much money) and if clients and edge routers > collaborate. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 25 14:01:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAPM0RA23071 for ipng-dist; Sat, 25 Nov 2000 14:00:27 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAPM0Gj23064 for ; Sat, 25 Nov 2000 14:00:17 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA11370 for ; Sat, 25 Nov 2000 14:00:16 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27923 for ; Sat, 25 Nov 2000 14:00:15 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id HAA12506; Sun, 26 Nov 2000 07:00:05 +0900 (JST) To: Brian E Carpenter cc: Jim Bound , "Ipng (E-Mail)" In-reply-to: brian's message of Sat, 25 Nov 2000 12:55:14 CST. <3A200B12.DF9E71F4@hursley.ibm.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: Usage of IPv6 flow label From: itojun@iijlab.net Date: Sun, 26 Nov 2000 07:00:05 +0900 Message-ID: <12504.975189605@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >It still isn't clear to me what the flow label adds to the semantics >used by existing 5-tuple QOS classifiers. just checking, here by "5-tuple" you meant: - IP address pair (src/dst) - layer 4 port number pair (src/dst) - protocol type is it correct? except for IP address, they may be embedded into ESP, or may be buried in IP header chain. so for efficient router operation we need to use flow label, which will effectively give us the following 3 items (depending on the definition of "flow"): - layer 4 port number pair - protocol type see RFC2205 page 9. i believe this (availability of flow label field) is one of important value-adds of IPv6 against IPv4. 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 Sun Nov 26 18:18:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAR2GtG23491 for ipng-dist; Sun, 26 Nov 2000 18:16:55 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAR2GGj23484 for ; Sun, 26 Nov 2000 18:16:46 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA05936 for ; Sun, 26 Nov 2000 18:15:36 -0800 (PST) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA14119 for ; Sun, 26 Nov 2000 18:15:36 -0800 (PST) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id BDCD71E59; Sun, 26 Nov 2000 20:15:32 -0600 (CST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 755AA1E4E; Sun, 26 Nov 2000 20:15:28 -0600 (CST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id VAA0000587808; Sun, 26 Nov 2000 21:12:06 -0500 (EST) From: Jim Bound Message-Id: <200011270212.VAA0000587808@anw.zk3.dec.com> To: Francis Dupont Cc: Jim Bound , Alex Conta , Steve Deering , Michael Thomas , Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Fri, 24 Nov 2000 16:57:27 +0100." <200011241557.QAA29940@givry.rennes.enst-bretagne.fr> Date: Sun, 26 Nov 2000 21:12:06 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In your previous mail you wrote: > > the flow label should be guranteed e-2-e. clients should set it. > routers should leave it alone. > >=> I agree but in the real word IntServ stuff (then flow label marking) >is done by an edge router. If doesn't matter if the LAN is fast enough >(and it can be without too much money) and if clients and edge routers >collaborate. I don't agree. The cell phone or audio server will set the flowlabel. See Itojun's draft: draft-itojun-ipv6-flowlabel-api-00.txt Which is a good piece of work and I agree with Itojun's presentation of the flowlabel. Its set by the end node. regards, /jim 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 26 18:48:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAR2kcs23541 for ipng-dist; Sun, 26 Nov 2000 18:46:38 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAR2kGj23534 for ; Sun, 26 Nov 2000 18:46:28 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA13870 for ; Sun, 26 Nov 2000 18:46:04 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09291 for ; Sun, 26 Nov 2000 18:44:50 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 64EF44EAE; Sun, 26 Nov 2000 21:44:50 -0500 (EST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 343F54C48; Sun, 26 Nov 2000 21:44:50 -0500 (EST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id VAA0000590282; Sun, 26 Nov 2000 21:43:26 -0500 (EST) From: Jim Bound Message-Id: <200011270243.VAA0000590282@anw.zk3.dec.com> To: Brian E Carpenter Cc: Jim Bound , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Sat, 25 Nov 2000 12:55:14 CST." <3A200B12.DF9E71F4@hursley.ibm.com> Date: Sun, 26 Nov 2000 21:43:26 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >It still isn't clear to me what the flow label adds to the semantics >used by existing 5-tuple QOS classifiers. First go look at RSVP. Thats one. In our RSVP implementation apps can set the flowid and then get reserved resources along the path for audio or video or even more mundane things like file transfer for mission critical apps like downloading coordinates to a military operation. Respond to Itojun's mail it says it all. The bottom line is the client or a server can set the flowlabel and with the address none of those other tuples are needed and it can also be useful when IPsec is being used to identify connections at a server that has a front end router parsing connections for a large MP machine as another example and get us away from monolithic TCP/IP processing. Itojuns mail attached. Also look at Itojuns draft. regards, /jim Return-Path: itojun@itojun.org Received: from oflume.zk3.dec.com by sigma.zk3.dec.com (8.8.8/1.1.20.3/24Apr98-0811AM) id RAA0000014230; Sat, 25 Nov 2000 17:00:41 -0500 (EST) Received: from ztxmail01.ztx.compaq.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id RAA0000028683; Sat, 25 Nov 2000 17:00:14 -0500 (EST) Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345) id 2521523C9; Sat, 25 Nov 2000 16:00:14 -0600 (CST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 03A592091 for ; Sat, 25 Nov 2000 16:00:12 -0600 (CST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id HAA12506; Sun, 26 Nov 2000 07:00:05 +0900 (JST) To: Brian E Carpenter Cc: Jim Bound , "Ipng (E-Mail)" In-reply-to: brian's message of Sat, 25 Nov 2000 12:55:14 CST. <3A200B12.DF9E71F4@hursley.ibm.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: Usage of IPv6 flow label From: itojun@iijlab.net Date: Sun, 26 Nov 2000 07:00:05 +0900 Message-ID: <12504.975189605@coconut.itojun.org> Sender: itojun@itojun.org >It still isn't clear to me what the flow label adds to the semantics >used by existing 5-tuple QOS classifiers. just checking, here by "5-tuple" you meant: - IP address pair (src/dst) - layer 4 port number pair (src/dst) - protocol type is it correct? except for IP address, they may be embedded into ESP, or may be buried in IP header chain. so for efficient router operation we need to use flow label, which will effectively give us the following 3 items (depending on the definition of "flow"): - layer 4 port number pair - protocol type see RFC2205 page 9. i believe this (availability of flow label field) is one of important value-adds of IPv6 against IPv4. 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 Sun Nov 26 21:32:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAR5V1D23611 for ipng-dist; Sun, 26 Nov 2000 21:31:01 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAR5Uoj23604 for ; Sun, 26 Nov 2000 21:30:50 -0800 (PST) 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,v1.7) with ESMTP id VAA28106 for ; Sun, 26 Nov 2000 21:30:49 -0800 (PST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA11060 for ; Sun, 26 Nov 2000 21:30:49 -0800 (PST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Mon Nov 27 00:28:16 EST 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by scummy; Mon Nov 27 00:29:02 EST 2000 Received: from research.bell-labs.com (ex-vpn69.pa.bell-labs.com [135.250.1.69]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAV93405 (AUTH gja); Sun, 26 Nov 2000 21:28:59 -0800 (PST) Message-ID: <3A21F15D.CB7F2436@research.bell-labs.com> Date: Sun, 26 Nov 2000 21:30:05 -0800 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Bound CC: Brian E Carpenter , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <200011270243.VAA0000590282@anw.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound wrote: > > Brian, > > >It still isn't clear to me what the flow label adds to the semantics > >used by existing 5-tuple QOS classifiers. > > First go look at RSVP. Thats one. Although RSVP's use of flowlabel does provide a simpler, not-munged-by-IPsec syntax for expressing a flow's identity, I was under the impression the flowlabel+srcaddr is semantically identical to the 5-tuple. cheers, gja -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 27 00:48:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAR8fvC23715 for ipng-dist; Mon, 27 Nov 2000 00:41:57 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAR8flj23708 for ; Mon, 27 Nov 2000 00:41:47 -0800 (PST) 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,v1.7) with ESMTP id AAA21125 for ; Mon, 27 Nov 2000 00:41:47 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA22602 for ; Mon, 27 Nov 2000 01:41:46 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eAR8bn417160; Mon, 27 Nov 2000 09:37:49 +0100 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 JAA01904; Mon, 27 Nov 2000 09:37:48 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id JAA48547; Mon, 27 Nov 2000 09:41:02 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200011270841.JAA48547@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jim Bound cc: Alex Conta , Steve Deering , Michael Thomas , Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of Sun, 26 Nov 2000 21:12:06 EST. <200011270212.VAA0000587808@anw.zk3.dec.com> Date: Mon, 27 Nov 2000 09:41:02 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > In your previous mail you wrote: > > the flow label should be guranteed e-2-e. clients should set it. > routers should leave it alone. > >=> I agree but in the real word IntServ stuff (then flow label marking) >is done by an edge router. If doesn't matter if the LAN is fast enough >(and it can be without too much money) and if clients and edge routers >collaborate. I don't agree. => What do you not agree about? I agree about the should but not the will. Technical there is no reason to set the flow label in the edge router but it is very common for not technical reason to see the edge router doing the *Serv stuff on the behalf of the real source. The cell phone or audio server will set the flowlabel. => it is not what happens today then we should not fordid that the edge router rewrites the flow label. Which is a good piece of work and I agree with Itojun's presentation of the flowlabel. Its set by the end node. => don't confuse the real and the ideal worlds. 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 Mon Nov 27 06:04:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eARE2mm23885 for ipng-dist; Mon, 27 Nov 2000 06:02:48 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eARE2dj23878 for ; Mon, 27 Nov 2000 06:02:39 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA26125 for ; Mon, 27 Nov 2000 06:02:34 -0800 (PST) Received: from zcamail02.zca.compaq.com (zcamail02.zca.compaq.com [161.114.32.102]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26276 for ; Mon, 27 Nov 2000 06:02:34 -0800 (PST) Received: by zcamail02.zca.compaq.com (Postfix, from userid 12345) id 16FC6741A; Mon, 27 Nov 2000 06:02:40 -0800 (PST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zcamail02.zca.compaq.com (Postfix) with ESMTP id 09A267475; Mon, 27 Nov 2000 06:02:39 -0800 (PST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id JAA0000672360; Mon, 27 Nov 2000 09:00:25 -0500 (EST) From: Jim Bound Message-Id: <200011271400.JAA0000672360@anw.zk3.dec.com> To: Francis Dupont Cc: Jim Bound , Alex Conta , Steve Deering , Michael Thomas , Jun-ichiro itojun Hagino , "Hesham Soliman (EPA)" , Metzler Jochen , "Ipng (E-Mail)" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Mon, 27 Nov 2000 09:41:02 +0100." <200011270841.JAA48547@givry.rennes.enst-bretagne.fr> Date: Mon, 27 Nov 2000 09:00:24 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >=> I agree but in the real word IntServ stuff (then flow label marking) >is done by an edge router. If doesn't matter if the LAN is fast enough >(and it can be without too much money) and if clients and edge routers >collaborate. I don't agree. >=> What do you not agree about? I agree about the should but not the will. >Technical there is no reason to set the flow label in the edge router but >it is very common for not technical reason to see the edge router doing >the *Serv stuff on the behalf of the real source. There is no flowlabel to set today so don't tell me the real world is using it. What they are using is the diffserv bits and other mechanisms for switching etc... This is a wide open option and discussion. As I said in prior mail we may need to take a bit to define if the flow is rewritable. The cell phone or audio server will set the flowlabel. >=> it is not what happens today then we should not fordid that the edge >router rewrites the flow label. This is discussable and you must not have read my mail to Thomas Eklund. Which is a good piece of work and I agree with Itojun's presentation of the flowlabel. Its set by the end node. >=> don't confuse the real and the ideal worlds. Excuse me. But lets go offline with this I will match the customers in the real world building real products who want the flowlabel e2e and we are talking 3GPP, Military Operations, and Video/Audio apps. The bottom line is many folks want to use this flowlabel and one of those folks are those who want it from one client to another client across the Internet and to NOT BE TOUCHED by a router. You should not confuse what exists today in IPv4 what can exist in IPv6 tomorrow. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 27 06:22:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAREKql23924 for ipng-dist; Mon, 27 Nov 2000 06:20:52 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAREKhj23917 for ; Mon, 27 Nov 2000 06:20:44 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA19089 for ; Mon, 27 Nov 2000 06:20:43 -0800 (PST) Received: from zcamail02.zca.compaq.com (zcamail02.zca.compaq.com [161.114.32.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15040 for ; Mon, 27 Nov 2000 06:20:43 -0800 (PST) Received: by zcamail02.zca.compaq.com (Postfix, from userid 12345) id 961017453; Mon, 27 Nov 2000 06:20:49 -0800 (PST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zcamail02.zca.compaq.com (Postfix) with ESMTP id 0594C7725; Mon, 27 Nov 2000 06:20:49 -0800 (PST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id JAA0000674021; Mon, 27 Nov 2000 09:18:35 -0500 (EST) From: Jim Bound Message-Id: <200011271418.JAA0000674021@anw.zk3.dec.com> To: Grenville Armitage Cc: Jim Bound , Brian E Carpenter , "Ipng (E-Mail)" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Sun, 26 Nov 2000 21:30:05 PST." <3A21F15D.CB7F2436@research.bell-labs.com> Date: Mon, 27 Nov 2000 09:18:35 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Greenville, >Although RSVP's use of flowlabel does provide a simpler, >not-munged-by-IPsec syntax for expressing a flow's identity, >I was under the impression the flowlabel+srcaddr is semantically >identical to the 5-tuple. Sure you can take a 5 tuple and get a 2 tuple. But you also have to munge down into the packet past the header in IPv4 and this can be avoided in IPv6, and only if IPsec is not there. IPsec is mandatory for IPv6. It will be there unless users turn it off and I doubt that unless it performs very very bad. I don't think we can assume IPsec will not perform good enough to be used, as engineers or architects. So one may not be able to see the TCP port+address+proto-id without a decrypt operation. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 27 06:24:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eAREN8Z23942 for ipng-dist; Mon, 27 Nov 2000 06:23:08 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eAREMuj23935 for ; Mon, 27 Nov 2000 06:22:56 -0800 (PST) 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,v1.7) with ESMTP id GAA11753 for ; Mon, 27 Nov 2000 06:22:56 -0800 (PST) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00759 for ; Mon, 27 Nov 2000 06:22:56 -0800 (PST) Received: from zcard00m.ca.nortel.com by ertpg14e1.nortelnetworks.com; Mon, 27 Nov 2000 09:20:30 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id XN5LPN52; Mon, 27 Nov 2000 09:20:27 -0500 Received: from nortelnetworks.com (DEATHVALLEY [132.245.252.116]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id XJ54TD7X; Mon, 27 Nov 2000 09:20:27 -0500 Message-ID: <3A226D74.142B85D9@nortelnetworks.com> Date: Mon, 27 Nov 2000 09:19:32 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Mailing List Subject: [Fwd: I-D ACTION:draft-haberman-ipngwg-auto-prefix-00.txt] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, The following is an individual submission discussing automated prefix delegation. The basic idea is that routers can request a prefix to use within a network. Right now, we restrict its use to leaf networks, but are working on expanding it. Comments welcome. Regards, Brian Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Automatic Prefix Delegation Protocol for Internet > Protocol Version 6 (IPv6) > Author(s) : B. Haberman, J. Martin > Filename : draft-haberman-ipngwg-auto-prefix-00.txt > Pages : 11 > Date : 22-Nov-00 > > The expansion of the IP address space provided by IPv6 makes it both > possible and reasonable to allocate entire subnets to environments > that had been previously limited to a few individual IP addresses. > Other protocols such as Neighbor Discovery and Stateless Address > Autoconfiguration allow hosts within those subnets to be > automatically configured. The router between this subnet and the > upstream world requires just one more piece to make this process > automatic, a network prefix. > This document describes a mechanism for the automated delegation of > an IPv6 network prefix. It allows routers to request a specific size > prefix and inform the upstream router of the routing protocols of > which it is capable. Upon authorizing the request the delegating > router then returns a prefix, the desired routing protocol, and a > lifetime for the use of the prefix. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-haberman-ipngwg-auto-prefix-00.txt > > 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-haberman-ipngwg-auto-prefix-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-haberman-ipngwg-auto-prefix-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 Mon Nov 27 07:05:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eARF3up24037 for ipng-dist; Mon, 27 Nov 2000 07:03:56 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eARF3fj24030 for ; Mon, 27 Nov 2000 07:03:41 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA16318 for ; Mon, 27 Nov 2000 07:03:41 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13892 for ; Mon, 27 Nov 2000 07:03:31 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id eARF3gJ08175; Mon, 27 Nov 2000 22:03:45 +0700 (ICT) From: Robert Elz To: "Brian Haberman" cc: IPng Mailing List Subject: Re: [Fwd: I-D ACTION:draft-haberman-ipngwg-auto-prefix-00.txt] In-reply-to: Your message of "Mon, 27 Nov 2000 09:19:32 EST." <3A226D74.142B85D9@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Nov 2000 22:03:42 +0700 Message-ID: <8173.975337422@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 27 Nov 2000 09:19:32 -0500 From: "Brian Haberman" Message-ID: <3A226D74.142B85D9@nortelnetworks.com> | The following is an individual submission discussing automated | prefix delegation. In general, I think this is a great idea, IPv6 needs more like this. | Right now, we restrict its use to leaf | networks, but are working on expanding it. I looked, but other than for the assertion of that, I couldn't find such a restriction? If a router can request a /56 prefix from its upstream router, what's to stop it then registering as an ALL-DELEGATORS on its other links and then giving out shorter prefixes to anyone who asks - or even just receiving a request from downstream, making a request upstream, and then passing back the prefix obtained ? | Comments welcome. I am a little concerned with the assumption that an ALL-DELEGATOR is a router. To me, a protocol like this requires state in the server, so it can remember what it has allocated over outages (including "broken box, replace it" outages). That smells more like a host than a router to me (and yes, I know that routers are also hosts, but not usually that kind of host, though they can be). Was there some reason you're assuming that the delegator is a router? I'm also not sure why it is important that it be deterministic which server (delegator) a client router picks when it receives multiple offers? Wouldn't any one of them suffice? Perhaps all of them (serially) if the client ends up unable to obtain a prefix from the first it tries. I know you have "not directly connected" (between client & server) as a "future work" - this is one I think needs more urgent future work. It could be as easy as having it not possible when there is no site local address (or global) already available to the client, but if there is, doing an expanding ring multicast search (limited to a smallish N hops, and prefering site local over global - using site scope multicast) to find the delegator. Alternatively, dhcp type relay agents in routers... Also, is there a need for 2 icmp types really? I know icmp has a tradition of request & reply messages, but couldn't all this be made to fit in one? There are already lots of sub-codes for the messages. 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 Nov 27 08:50:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eARGnAM24138 for ipng-dist; Mon, 27 Nov 2000 08:49:10 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eARGn1j24131 for ; Mon, 27 Nov 2000 08:49:01 -0800 (PST) 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,v1.7) with ESMTP id IAA20544 for ; Mon, 27 Nov 2000 08:49:00 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13452 for ; Mon, 27 Nov 2000 08:49:00 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id IAA12091; Mon, 27 Nov 2000 08:48:57 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA09421; Mon, 27 Nov 2000 08:48:57 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14882.36985.101243.804568@thomasm-u1.cisco.com> Date: Mon, 27 Nov 2000 08:48:57 -0800 (PST) To: Brian E Carpenter Cc: Jim Bound , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label In-Reply-To: <3A200B12.DF9E71F4@hursley.ibm.com> References: <200011241557.QAA29940@givry.rennes.enst-bretagne.fr> <3A200B12.DF9E71F4@hursley.ibm.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes: > Jim, > > It still isn't clear to me what the flow label adds to the semantics > used by existing 5-tuple QOS classifiers. It seems intuitively more efficient for a flow classifier to use a single host-defined flow identifier than having to walk a potentially long list of extension headers. Another advantage is that, sort of like diffserv, the host itself can decide what is to be grouped in a particular flow instead of requiring that it match the normal 5-tuple. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 27 10:42:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eARIerg24294 for ipng-dist; Mon, 27 Nov 2000 10:40:53 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eARIegj24287 for ; Mon, 27 Nov 2000 10:40:42 -0800 (PST) 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,v1.7) with ESMTP id KAA04338; Mon, 27 Nov 2000 10:40:40 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA27152; Mon, 27 Nov 2000 11:40:37 -0700 (MST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA26257; Mon, 27 Nov 2000 10:42:30 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA22248; Mon, 27 Nov 2000 10:42:31 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id KAA29838; Mon, 27 Nov 2000 10:42:46 -0800 (PST) Date: Mon, 27 Nov 2000 10:42:46 -0800 (PST) From: Tim Hartrick Message-Id: <200011271842.KAA29838@feller.mentat.com> To: jinmei@isl.rdc.toshiba.co.jp, Erik.Nordmark@eng.sun.com Subject: Re: IPV6_USEMTU socket option Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > What would you like to see instead? > uint32_t? uint16_t? > uint32_t is probably best. > > > This cmsghdr will be passed to every socket that sets the > > IPV6_RECVPATHMTU socket option, even if the socket is > > non-connected. Note that this also means an application that sets > > the option may get the ancillary data upon a too big message sent > > from other applications to the same destination. An implementation > > may skip to deliver the data to sockets that connect a different > > foreign address from the destination address of the corresponding > > ip6_mtuinfo strucutre. > > I'll add the above. THanks for the text. > > > This is based on the behavior of our implementation, but I don't stick > > to minor details (e.g. the last sentence). > > > > > XXX What about more complex paths e.g. when using a routing header? > > > > How about the following text? > > > > When an application sends packet with a routing header, the final > > destination stored in the ip6m_addr member does not necessarily > > contain complete information of the entire path. Thus, an > > implementation may append an additional data structure after > > ip6_mtuinfo to tell the application precise information of the > > entire path. This definition of the additinaol structure is beyond > > the scope of this document. > > I can add this unless somebody has any concerns about essentially making > this implementation specific. > I do, since I am having a difficult time understanding how an application would make use of such information. If it can be used by an application then it should be documented in full or not referenced at all in the document. Note that I am not saying that someone can't implement anything they like. What I am saying is that the specification is intended to document specific features that application writers can depend on being available on all platforms. 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 Mon Nov 27 11:15:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eARJDdS24454 for ipng-dist; Mon, 27 Nov 2000 11:13:39 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eARJDUj24447 for ; Mon, 27 Nov 2000 11:13:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA04504 for ; Mon, 27 Nov 2000 11:13:28 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05933 for ; Mon, 27 Nov 2000 11:13:26 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA134474; Mon, 27 Nov 2000 11:08:50 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA09662; Mon, 27 Nov 2000 11:13:24 -0800 Message-ID: <3A22B207.BA7E4F13@hursley.ibm.com> Date: Mon, 27 Nov 2000 13:12:07 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: itojun@iijlab.net CC: "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <12504.975189605@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > > >It still isn't clear to me what the flow label adds to the semantics > >used by existing 5-tuple QOS classifiers. > > just checking, here by "5-tuple" you meant: > - IP address pair (src/dst) > - layer 4 port number pair (src/dst) > - protocol type > is it correct? Correct. And that will be used by classifiers in both IntServ and DiffServ implementations. > > except for IP address, they may be embedded into ESP, or may be buried > in IP header chain. so for efficient router operation we need to > use flow label, which will effectively give us the following 3 items > (depending on the definition of "flow"): > - layer 4 port number pair > - protocol type Only if we define a standard way of compressing the ports and protocol type into the flow label. > see RFC2205 page 9. > i believe this (availability of flow label field) is one of important > value-adds of IPv6 against IPv4. "Could be", not "is", unfortunately. It's very dangerous to use this as a sales argument before it is actually true. 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 Nov 27 11:19:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eARJFM224467 for ipng-dist; Mon, 27 Nov 2000 11:15:22 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eARJFAj24460 for ; Mon, 27 Nov 2000 11:15:11 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA05037 for ; Mon, 27 Nov 2000 11:15:09 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA06691 for ; Mon, 27 Nov 2000 11:15:06 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA134598; Mon, 27 Nov 2000 11:10:28 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA20724; Mon, 27 Nov 2000 11:15:02 -0800 Message-ID: <3A22B269.139369C8@hursley.ibm.com> Date: Mon, 27 Nov 2000 13:13:45 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Grenville Armitage CC: Jim Bound , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <200011270243.VAA0000590282@anw.zk3.dec.com> <3A21F15D.CB7F2436@research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Grenville Armitage wrote: > > Jim Bound wrote: > > > > Brian, > > > > >It still isn't clear to me what the flow label adds to the semantics > > >used by existing 5-tuple QOS classifiers. > > > > First go look at RSVP. Thats one. > > Although RSVP's use of flowlabel does provide a simpler, > not-munged-by-IPsec syntax for expressing a flow's identity, > I was under the impression the flowlabel+srcaddr is semantically > identical to the 5-tuple. No, not until the flow label has some semantics, which it doesn't today. And itojun's point about IPSEC is important. 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 Nov 27 12:42:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eARKfHg24568 for ipng-dist; Mon, 27 Nov 2000 12:41:17 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eARKf7j24561 for ; Mon, 27 Nov 2000 12:41:07 -0800 (PST) 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,v1.7) with ESMTP id MAA08973 for ; Mon, 27 Nov 2000 12:41:06 -0800 (PST) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00442 for ; Mon, 27 Nov 2000 12:41:05 -0800 (PST) Received: from zbl6c016.corpeast.baynetworks.com (actually zbl6c016) by ertpg14e1.nortelnetworks.com; Mon, 27 Nov 2000 12:08:47 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id W8KSPJ2S; Mon, 27 Nov 2000 12:08:43 -0500 Received: from nortelnetworks.com (DEATHVALLEY [132.245.252.116]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id XJ54T1AN; Mon, 27 Nov 2000 12:08:43 -0500 Message-ID: <3A2294E5.1A22C2AB@nortelnetworks.com> Date: Mon, 27 Nov 2000 12:07:49 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Elz CC: IPng Mailing List , "James Martin" Subject: Re: [Fwd: I-D ACTION:draft-haberman-ipngwg-auto-prefix-00.txt] References: <8173.975337422@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, Robert Elz wrote: > > Date: Mon, 27 Nov 2000 09:19:32 -0500 > From: "Brian Haberman" > Message-ID: <3A226D74.142B85D9@nortelnetworks.com> > > | The following is an individual submission discussing automated > | prefix delegation. > > In general, I think this is a great idea, IPv6 needs more like this. > > | Right now, we restrict its use to leaf > | networks, but are working on expanding it. > > I looked, but other than for the assertion of that, I couldn't find > such a restriction? Operationally, there is not a restriction. We have a concern though, about having multiple routers on the same network requesting multiple prefixes for use on it. There are some details that I have not had time to completely work through yet. > > If a router can request a /56 prefix from its upstream router, what's > to stop it then registering as an ALL-DELEGATORS on its other links > and then giving out shorter prefixes to anyone who asks - or even just > receiving a request from downstream, making a request upstream, and > then passing back the prefix obtained ? See comment above. I also have a concern about having this protocol look like DHCPv6 (replace addresses with prefixes). > > | Comments welcome. > > I am a little concerned with the assumption that an ALL-DELEGATOR is > a router. To me, a protocol like this requires state in the server, > so it can remember what it has allocated over outages (including > "broken box, replace it" outages). That smells more like a host > than a router to me (and yes, I know that routers are also hosts, but > not usually that kind of host, though they can be). Good point. There is no reason that the delegator cannot be a host. In fact, it may be better if it was a host. > > Was there some reason you're assuming that the delegator is a router? > > I'm also not sure why it is important that it be deterministic which > server (delegator) a client router picks when it receives multiple > offers? Wouldn't any one of them suffice? Perhaps all of them > (serially) if the client ends up unable to obtain a prefix from the > first it tries. It was meant as a guideline for requestors. How they choose which delegator to use may not be all that important. > > I know you have "not directly connected" (between client & server) as > a "future work" - this is one I think needs more urgent future work. > It could be as easy as having it not possible when there is no site > local address (or global) already available to the client, but if there > is, doing an expanding ring multicast search (limited to a smallish N > hops, and prefering site local over global - using site scope multicast) > to find the delegator. Alternatively, dhcp type relay agents in routers... Either a relay or a site-local multicast address is what I had in mind for "not directly connected" requests. I just did not have time to address it and the security issues prior to the deadline. > > Also, is there a need for 2 icmp types really? I know icmp has a tradition > of request & reply messages, but couldn't all this be made to fit in one? > There are already lots of sub-codes for the messages. Yes, that was my original intent, and could easily be modified to use one type. Thanks for the comments. 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 Nov 27 14:14:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eARMCru24621 for ipng-dist; Mon, 27 Nov 2000 14:12:53 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eARMCgj24614 for ; Mon, 27 Nov 2000 14:12:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA27950 for ; Mon, 27 Nov 2000 14:12:42 -0800 (PST) Received: from starfruit.itojun.org (dhcp0.itojun.org [210.160.95.106]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA26805 for ; Mon, 27 Nov 2000 15:12:39 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 9561E7E20; Tue, 28 Nov 2000 07:12:28 +0900 (JST) To: Brian E Carpenter Cc: "Ipng (E-Mail)" In-reply-to: brian's message of Mon, 27 Nov 2000 13:12:07 CST. <3A22B207.BA7E4F13@hursley.ibm.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: Usage of IPv6 flow label From: Jun-ichiro itojun Hagino Date: Tue, 28 Nov 2000 07:12:28 +0900 Message-Id: <20001127221228.9561E7E20@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> except for IP address, they may be embedded into ESP, or may be buried >> in IP header chain. so for efficient router operation we need to >> use flow label, which will effectively give us the following 3 items >> (depending on the definition of "flow"): >> - layer 4 port number pair >> - protocol type >Only if we define a standard way of compressing the ports and protocol type >into the flow label. i don't think there needs to be a standard way. if there's some pseudorandom and unique number in flow label field (as suggested in RFC2460) it is more than enough. itjun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 27 15:00:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eARMwiG24703 for ipng-dist; Mon, 27 Nov 2000 14:58:44 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eARMwZj24696 for ; Mon, 27 Nov 2000 14:58:36 -0800 (PST) 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,v1.7) with ESMTP id OAA12613 for ; Mon, 27 Nov 2000 14:58:36 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14775 for ; Mon, 27 Nov 2000 14:58:34 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id OAA131994; Mon, 27 Nov 2000 14:53:55 -0800 Received: from hursley.ibm.com (lig32-227-10-35.us.lig-dial.ibm.com [32.227.10.35]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA32494; Mon, 27 Nov 2000 14:58:28 -0800 Message-ID: <3A22E4C5.27CFD182@hursley.ibm.com> Date: Mon, 27 Nov 2000 16:48:37 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Michael Thomas CC: Jim Bound , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <200011241557.QAA29940@givry.rennes.enst-bretagne.fr> <3A200B12.DF9E71F4@hursley.ibm.com> <14882.36985.101243.804568@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: > > Brian E Carpenter writes: > > Jim, > > > > It still isn't clear to me what the flow label adds to the semantics > > used by existing 5-tuple QOS classifiers. > > It seems intuitively more efficient for a flow classifier > to use a single host-defined flow identifier than having > to walk a potentially long list of extension headers. > Another advantage is that, sort of like diffserv, the > host itself can decide what is to be grouped in a particular > flow instead of requiring that it match the normal 5-tuple. Just to make the point again: the 5-tuple has semantics that allows a classifier to *classify* the traffic. Today at least, the flow label has no such semantics - it's just plain bits. That may help in IntServ but it's no use at all in DiffServ. 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 Nov 27 15:45:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id eARNhCN24795 for ipng-dist; Mon, 27 Nov 2000 15:43:12 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id eARNh3j24788 for ; Mon, 27 Nov 2000 15:43:04 -0800 (PST) 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,v1.7) with ESMTP id PAA03509 for ; Mon, 27 Nov 2000 15:43:03 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28310 for ; Mon, 27 Nov 2000 15:43:03 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA48516; Mon, 27 Nov 2000 15:38:23 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA24816; Mon, 27 Nov 2000 15:43:00 -0800 Message-ID: <3A22F161.82CC6282@hursley.ibm.com> Date: Mon, 27 Nov 2000 17:42:25 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <20001127221228.9561E7E20@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino wrote: > > >> except for IP address, they may be embedded into ESP, or may be buried > >> in IP header chain. so for efficient router operation we need to > >> use flow label, which will effectively give us the following 3 items > >> (depending on the definition of "flow"): > >> - layer 4 port number pair > >> - protocol type > >Only if we define a standard way of compressing the ports and protocol type > >into the flow label. > > i don't think there needs to be a standard way. if there's some > pseudorandom and unique number in flow label field (as suggested in > RFC2460) it is more than enough. No, not for diffserv and not for any solution where intserv is used only somewhere downstream from the host. The classifier needs something that *encodes* the ports and protocol, so that a QOS policy can be applied. That's how QOS classifiers work; they can't use pseudorandom numbers. 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 Nov 27 21:20:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAS5JNG25038 for ipng-dist; Mon, 27 Nov 2000 21:19:23 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAS5JEK25031 for ; Mon, 27 Nov 2000 21:19:15 -0800 (PST) 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,v1.7) with ESMTP id VAA20059 for ; Mon, 27 Nov 2000 21:19:13 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA16090 for ; Mon, 27 Nov 2000 22:19:13 -0700 (MST) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 27 Nov 2000 21:19:12 -0800 (Pacific Standard Time) Received: by inet-imc-02.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Mon, 27 Nov 2000 21:11:08 -0800 Message-ID: From: Christian Huitema To: "'Brian E Carpenter'" , Michael Thomas Cc: Jim Bound , "Ipng (E-Mail)" Subject: RE: Usage of IPv6 flow label Date: Mon, 27 Nov 2000 18:38:19 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, I am a bit puzzled by your reference to the 5 tuple as "enabling diffserv." I think you have a model there in which the diffserv bits are set by some intermediate router, after examining the "5 tuple" of the packet. In this context, the five-tuple works somewhat. But it does not work well with IPSEC (ports are hidden), it does not work well with floating port applications such as VoIP, and it leads to some interesting header manipulation when we encounter stacks of IPv6 headers. There are at least two other ways to "enable diffserv." One way would be to just let the hosts set the diffserv bits, and then let the intermediate router do accounting, charging, and maybe rationing. Another way is to use RSVP to convey the requested quality of service, and the user credentials, to the intermediate routers; then, the flow-id can be use for flow classification, and the intermediate routers can on this basis set the diffserv bits however they see fit. -- Christian Huitema > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Monday, November 27, 2000 2:49 PM > To: Michael Thomas > Cc: Jim Bound; Ipng (E-Mail) > Subject: Re: Usage of IPv6 flow label > > > Michael Thomas wrote: > > > > Brian E Carpenter writes: > > > Jim, > > > > > > It still isn't clear to me what the flow label adds to > the semantics > > > used by existing 5-tuple QOS classifiers. > > > > It seems intuitively more efficient for a flow classifier > > to use a single host-defined flow identifier than having > > to walk a potentially long list of extension headers. > > Another advantage is that, sort of like diffserv, the > > host itself can decide what is to be grouped in a particular > > flow instead of requiring that it match the normal 5-tuple. > > Just to make the point again: the 5-tuple has semantics that > allows a classifier to *classify* the traffic. Today at least, > the flow label has no such semantics - it's just plain bits. > That may help in IntServ but it's no use at all in DiffServ. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 27 22:48:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAS6l8725172 for ipng-dist; Mon, 27 Nov 2000 22:47:08 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAS6kxK25165 for ; Mon, 27 Nov 2000 22:46:59 -0800 (PST) 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,v1.7) with ESMTP id WAA08489 for ; Mon, 27 Nov 2000 22:46:58 -0800 (PST) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA02493 for ; Mon, 27 Nov 2000 22:46:57 -0800 (PST) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id 281281FCC; Tue, 28 Nov 2000 00:46:57 -0600 (CST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 8E3171F17 for ; Tue, 28 Nov 2000 00:46:56 -0600 (CST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id BAA0000771996; Tue, 28 Nov 2000 01:45:30 -0500 (EST) From: Jim Bound Message-Id: <200011280645.BAA0000771996@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: Itojun and Jochen's Flow Drafts Date: Tue, 28 Nov 2000 01:45:30 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks I urge all to read: draft-itojun-ipv6-flowlabel-api-00.txt draft-metzler-ipv6-flowlabel-00.txt I believe these two pieces of work have great synergy and unify the ideas I believe we need to pursue to select what the 20bit flow label should do for IPv6 and get us on the right track. I am traveling and also want to say I fully agree with Christian's mail to Brian regarding the role of setting the diffserv bits. I also do not believe that the orginal thoughts early in SIP and IPv6 regarding the flowlabel time has passed but is now with 3GPP more than ever needed than before to be used by the client and set by the client. I also know this works on our implementation of IPv6 and we will be showing it at ITU Asia I think with our RSVP demo of v4 and v6 to the Asian Telco community and others, but I need to verify it made the demo / interop code drop. IF not here definitely at the next show. I also know the code very well and Itojun's draft would make the programming of flows even more elegant than what we did. Also to look at the IPv4 code for RSVP to hack into the payload to determine the 5-tuple vs IPv6 just using the flowlabel and srcaddr is no comparison at all. Also to Brian: RSVP does define the use of the flowlabel for IPv6 and does specify how to use it and Itojun's statements to you in that context are axiomatic. my .02/cents /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 00:51:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAS8nfc25227 for ipng-dist; Tue, 28 Nov 2000 00:49:41 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAS8nWK25220 for ; Tue, 28 Nov 2000 00:49:32 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA05872 for ; Tue, 28 Nov 2000 00:49:32 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA12219 for ; Tue, 28 Nov 2000 00:49:27 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id eAS8ng301739; Tue, 28 Nov 2000 15:49:45 +0700 (ICT) From: Robert Elz To: "Brian Haberman" cc: IPng Mailing List , "James Martin" Subject: Re: [Fwd: I-D ACTION:draft-haberman-ipngwg-auto-prefix-00.txt] In-reply-to: Your message of "Mon, 27 Nov 2000 12:07:49 EST." <3A2294E5.1A22C2AB@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Nov 2000 15:49:42 +0700 Message-ID: <1737.975401382@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 27 Nov 2000 12:07:49 -0500 From: "Brian Haberman" Message-ID: <3A2294E5.1A22C2AB@nortelnetworks.com> | We have a concern though, | about having multiple routers on the same network requesting multiple | prefixes for use on it. Yes... I have always been of the view that it ought be prefectly safe for routers to acquire a prefix on a net the same way that hosts do - listen for RAs from other routers... (and like hosts, also via static config optionally). Then, I'd only be asking for prefix allocation for a net in the case that there were no other routers on the link. This even fits well with divided cables, that end up with one router on each, each of which is connected to the outside world (when they boot, or when one of them boots - as in after a power off restart, where the switch supposed to connect the segments doesn't recover) - then they can each go get a prefix from their servers, and depending up how they're set up, might each get handed the same prefix (perhaps with some glue added, like instructions to build a tunnel, and bridge, between themselves) or they might each be given a different prefix, as they are at least temporarily disjoint nets, and then allow one of the prefixes to die out after the nets reconnect. There's lots of scope for good work here... Unfortunately, there are (or at least were) also lots of people who seem to strongly believe that any kind of router autoconfiguration us something so dangerous, that it can never be permitted. | I also have a concern about having this protocol | look like DHCPv6 (replace addresses with prefixes). I had the same thought, but more along the lines of merging the two... (ie: just use DHCPv6 to fetch the prefix, the DHCP servers have just about all the mechanism to do everything that is needed 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 Tue Nov 28 08:22:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eASGLNp25689 for ipng-dist; Tue, 28 Nov 2000 08:21:23 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eASGLEK25682 for ; Tue, 28 Nov 2000 08:21:14 -0800 (PST) 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,v1.7) with ESMTP id IAA20133 for ; Tue, 28 Nov 2000 08:21:14 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23402 for ; Tue, 28 Nov 2000 09:21:12 -0700 (MST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA126622; Tue, 28 Nov 2000 08:16:19 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA24688; Tue, 28 Nov 2000 08:21:10 -0800 Message-ID: <3A23DB41.3C395A22@hursley.ibm.com> Date: Tue, 28 Nov 2000 10:20:17 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Christian Huitema CC: Michael Thomas , Jim Bound , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, All three modes of operation of diffserv that you mention are possible, implemented,and in experimental use. But there is a problem: a) we expect ISPs to classify, police, re-mark and shape traffic at their ingress, regardless of what the originating host or the first border router may have done b) that classification will be done in accordance with an ISP-specific policy expressed in some subset of {address range, port #, protocol #} c) this is impossible for IPSEC encrypted packets d) a syntax and semantics for the flow label that could be used by a classifier would fix this e) the only way I can see to do this is to compress port # and protocol # information into the flow label. I do intend to read the recent drafts so I'd better shut up until then. Brian Christian Huitema wrote: > > Brian, > > I am a bit puzzled by your reference to the 5 tuple as "enabling diffserv." > I think you have a model there in which the diffserv bits are set by some > intermediate router, after examining the "5 tuple" of the packet. In this > context, the five-tuple works somewhat. But it does not work well with IPSEC > (ports are hidden), it does not work well with floating port applications > such as VoIP, and it leads to some interesting header manipulation when we > encounter stacks of IPv6 headers. > > There are at least two other ways to "enable diffserv." One way would be to > just let the hosts set the diffserv bits, and then let the intermediate > router do accounting, charging, and maybe rationing. Another way is to use > RSVP to convey the requested quality of service, and the user credentials, > to the intermediate routers; then, the flow-id can be use for flow > classification, and the intermediate routers can on this basis set the > diffserv bits however they see fit. > > -- Christian Huitema > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Monday, November 27, 2000 2:49 PM > > To: Michael Thomas > > Cc: Jim Bound; Ipng (E-Mail) > > Subject: Re: Usage of IPv6 flow label > > > > > > Michael Thomas wrote: > > > > > > Brian E Carpenter writes: > > > > Jim, > > > > > > > > It still isn't clear to me what the flow label adds to > > the semantics > > > > used by existing 5-tuple QOS classifiers. > > > > > > It seems intuitively more efficient for a flow classifier > > > to use a single host-defined flow identifier than having > > > to walk a potentially long list of extension headers. > > > Another advantage is that, sort of like diffserv, the > > > host itself can decide what is to be grouped in a particular > > > flow instead of requiring that it match the normal 5-tuple. > > > > Just to make the point again: the 5-tuple has semantics that > > allows a classifier to *classify* the traffic. Today at least, > > the flow label has no such semantics - it's just plain bits. > > That may help in IntServ but it's no use at all in DiffServ. > > > > 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 > > -------------------------------------------------------------------- > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.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 Tue Nov 28 08:23:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eASGMpQ25698 for ipng-dist; Tue, 28 Nov 2000 08:22:51 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eASGMdK25691 for ; Tue, 28 Nov 2000 08:22:39 -0800 (PST) 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,v1.7) with ESMTP id IAA20656 for ; Tue, 28 Nov 2000 08:22:39 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09339 for ; Tue, 28 Nov 2000 08:22:38 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA66494; Tue, 28 Nov 2000 08:17:45 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA24462; Tue, 28 Nov 2000 08:22:32 -0800 Message-ID: <3A23DB92.2156416@hursley.ibm.com> Date: Tue, 28 Nov 2000 10:21:38 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Juan Fco Rodriguez Hervella CC: Michael Thomas , Jim Bound , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <200011241557.QAA29940@givry.rennes.enst-bretagne.fr> <3A200B12.DF9E71F4@hursley.ibm.com> <14882.36985.101243.804568@thomasm-u1.cisco.com> <3A237600.AF92B67C@it.uc3m.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk {source address, destination address, source port, destination port, protocol number} Brian Juan Fco Rodriguez Hervella wrote: ... > Could anyone explain to me what is the "5-tuple" that I am hearing > everywhere ? > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 08:25:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eASGOfX25725 for ipng-dist; Tue, 28 Nov 2000 08:24:41 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eASGOUK25718 for ; Tue, 28 Nov 2000 08:24:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA21137 for ; Tue, 28 Nov 2000 08:24:30 -0800 (PST) Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11358 for ; Tue, 28 Nov 2000 08:24:25 -0800 (PST) Received: from znsgd00t.europe.nortel.com (actually znsgd00t) by qnsgs000.nortel.com; Tue, 28 Nov 2000 16:22:05 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 28 Nov 2000 16:22:04 -0000 Message-ID: <3353DE9BA890D4118DDB0020484008840F7BF1@zhard00n.europe.nortel.com> From: "Elwyn Davies" To: "'ipng@sunroof.eng.sun.com'" Subject: RE: Usage of IPv6 flow label Date: Tue, 28 Nov 2000 16:21:59 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05957.553AFD50" 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_01C05957.553AFD50 Content-Type: text/plain Hi. 1. draft-metzler-ipv6-flowlabel-00 - the mechanisms proposed in this draft are not something that we should be supporting - it proposes polluting a network layer header with application layer info. If an application needs to multiplex streams onto a single socket in the way proposed it could equally well format the PDU in an appropriate way without layer pollution. 2. draft-itojun-ipv6-flowlabel-api-00 - this draft seems entirely sensible apart possibly from the desire to modify the flow label whenever the extension headers change. This should probably be under user control. Otherwise the network layer is allowed to control its own destiny whilst providing some useful information which allows routers simply to tie up the relationship between the packets of a flow. 3. The e2e mutability issue has been done to death in DiffServ for code points and it sounds like the whole argument is being trotted out again. The one and only fundamental point is that if the flow label is mutable, information is generally lost when it is changed after original setting and can never be restored unless there is some additional agency available to regenerate the information (entropy argument). If the label is changed in a way that does not lose information then it doesn't matter; likewise, if you don't care about the loss of information then go ahead and change it. 4. The flow label could clearly (also) be used as a signalling method to help out with inter-domain MPLS issues when you need to cross exchange points where the whole MPLS header has to be removed. I concur fully with Brian Carpenter's points on orthogonality of DiffServ and MPLS. As we know some of the proposals for combining MPLS and DiffServ have an implicit (i.e. signalled during path setup) connection between label and DSCP (as opposed to just intepreting the bits in the label). This is obviously important to MPLS because if there is an MPLS header, the router (LSR) shouldn't go poking around in the encapsulated packet to determine what the DSCP is (If MPLS is used as originally intended, the payload might not be an IP packet of any kind!). So: A. If there is an MPLS (Shim) header, that header specifies either implicitly or explicitly the DSCP to be used. The DSCP and flow label in the IPv6 header are never inspected once the packet is flowing down the MPLS path. B. If there isn't, you could use the flow label for flowy type things (like helping with determining what MPLS path should be used at the beginning of each of, perhaps, several serially crossed MPLS domains), but the DSCP in the packet should be used to drive the DiffServ operations. Regards, Elwyn Davies ---------------------------------------------------------------------------- ------ Elwyn B Davies Tel: +44 1279 405498 (ESN 742 - 5498) Email: elwynd@nortelnetworks.com Technical Strategy Manager - IP Networks Advanced Technology Centre Nortel UK London Road Harlow Essex UK CM17 9NA "The Folly is mostly mine" and the opinions are mine and not those of my employer. ============================================================================ ====== ------_=_NextPart_001_01C05957.553AFD50 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Usage of IPv6 flow label

Hi.

1.  = draft-metzler-ipv6-flowlabel-00 - the mechanisms proposed in this draft = are not something that we should be supporting - it proposes polluting = a network layer header with application layer info.  If an = application needs to multiplex streams onto a single socket in the way = proposed it could equally well format the PDU in an appropriate way = without layer pollution.

2. draft-itojun-ipv6-flowlabel-api-00 = - this draft seems entirely sensible apart possibly from the desire to = modify the flow label whenever the extension headers change.  This = should probably be under user control.  Otherwise the network = layer is allowed to control its own destiny whilst providing some = useful information which allows routers simply to tie up the = relationship between the packets of a flow.

3.  The e2e mutability issue has = been done to death in DiffServ for code points and it sounds like the = whole argument is being trotted out again.  The one and only = fundamental point is that if the flow label is mutable, information is = generally lost when it is changed after original setting and can never = be restored unless there is some additional agency available to = regenerate the information (entropy argument).  If the label is = changed in a way that does not lose information then it doesn't = matter;  likewise, if you don't care about the loss of information = then go ahead and change it.

4. The flow label could clearly (also) = be used as a signalling method to help out with inter-domain MPLS = issues when you need to cross exchange points where the whole MPLS = header has to be removed.

I concur fully with Brian Carpenter's = points on orthogonality of DiffServ and MPLS.  As we know some of = the proposals for combining MPLS and DiffServ have an implicit (i.e. = signalled during path setup) connection between label and DSCP (as = opposed to just intepreting the bits in the label).  This is = obviously important to MPLS because if there is an MPLS header, the = router (LSR) shouldn't go poking around in the encapsulated packet to = determine what the DSCP is (If MPLS is used as originally intended, the = payload might not be an IP packet of any kind!). So:

A. If there is an MPLS (Shim) header, = that header specifies either implicitly or explicitly the DSCP to be = used.  The DSCP and flow label in the IPv6 header are never = inspected once the packet is flowing down the MPLS path.

B. If there isn't, you could use the = flow label for flowy type things (like helping with determining what = MPLS path should be used at the beginning of each of, perhaps, several = serially crossed MPLS domains), but the DSCP in the packet should be = used to drive the DiffServ operations.

Regards,
Elwyn Davies

--------------------------------------------------------= --------------------------

Elwyn B Davies

Tel: +44 1279 405498 (ESN 742 - = 5498)
Email: = elwynd@nortelnetworks.com

Technical Strategy Manager - IP = Networks
Advanced Technology Centre
Nortel UK
London Road
Harlow
Essex
UK
CM17 9NA

"The Folly is mostly = mine"
and the opinions are mine and not = those of my employer.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



------_=_NextPart_001_01C05957.553AFD50-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 09:34:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eASHWl525779 for ipng-dist; Tue, 28 Nov 2000 09:32:47 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eASHWgK25772 for ; Tue, 28 Nov 2000 09:32:43 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id eASHVXc07920 for ipng@sunroof.eng.sun.com; Tue, 28 Nov 2000 09:31:33 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAS96qK25278 for ; Tue, 28 Nov 2000 01:06:53 -0800 (PST) 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,v1.7) with ESMTP id BAA07477 for ; Tue, 28 Nov 2000 01:06:52 -0800 (PST) Received: from matrix.it.uc3m.es (matrix.it.uc3m.es [163.117.139.159]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00948 for ; Tue, 28 Nov 2000 01:06:46 -0800 (PST) Received: from it.uc3m.es (localhost [127.0.0.1]) by matrix.it.uc3m.es (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id eAS98Gk14357; Tue, 28 Nov 2000 10:08:16 +0100 X-Authentication-Warning: matrix.it.uc3m.es: Host localhost [127.0.0.1] claimed to be it.uc3m.es Message-ID: <3A237600.AF92B67C@it.uc3m.es> Date: Tue, 28 Nov 2000 10:08:16 +0100 From: Juan Fco Rodriguez Hervella X-Mailer: Mozilla 4.74 [es] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Brian E Carpenter , Jim Bound , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <200011241557.QAA29940@givry.rennes.enst-bretagne.fr> <3A200B12.DF9E71F4@hursley.ibm.com> <14882.36985.101243.804568@thomasm-u1.cisco.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id eAS96rK25279 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas escribió: > > Brian E Carpenter writes: > > Jim, > > > > It still isn't clear to me what the flow label adds to the semantics > > used by existing 5-tuple QOS classifiers. > > It seems intuitively more efficient for a flow classifier > to use a single host-defined flow identifier than having > to walk a potentially long list of extension headers. > Another advantage is that, sort of like diffserv, the > host itself can decide what is to be grouped in a particular > flow instead of requiring that it match the normal 5-tuple. > Could anyone explain to me what is the "5-tuple" that I am hearing everywhere ? Thanks. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 11:18:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eASJHFa25887 for ipng-dist; Tue, 28 Nov 2000 11:17:15 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eASJH5K25880 for ; Tue, 28 Nov 2000 11:17:06 -0800 (PST) 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,v1.7) with ESMTP id LAA09680 for ; Tue, 28 Nov 2000 11:17:04 -0800 (PST) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA21995 for ; Tue, 28 Nov 2000 12:17:02 -0700 (MST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 140qFF-0003dx-00; Tue, 28 Nov 2000 14:16:49 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA16710; Tue, 28 Nov 00 14:11:56 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id OAA20210; Tue, 28 Nov 2000 14:16:13 -0500 Message-Id: <3A24049D.A7E17716@txc.com> Date: Tue, 28 Nov 2000 14:16:45 -0500 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Brian E Carpenter Cc: itojun@iijlab.net, "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <12504.975189605@coconut.itojun.org> <3A22B207.BA7E4F13@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6914D9666FC116FE578EC013" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms6914D9666FC116FE578EC013 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > > itojun@iijlab.net wrote: > > > > >It still isn't clear to me what the flow label adds to the semantics > > >used by existing 5-tuple QOS classifiers. > > > > just checking, here by "5-tuple" you meant: > > - IP address pair (src/dst) > > - layer 4 port number pair (src/dst) > > - protocol type > > is it correct? > > Correct. And that will be used by classifiers in both IntServ and DiffServ > implementations. > [...] > Brian It also can be used by an ingress MPLS router to determine a Forwarding Equivalence Class, when an unlabeled packet is being processed (and prepended the MPLS label stack.) Alex --------------ms6914D9666FC116FE578EC013 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKBgYJKoZIhvcNAQcCoIIJ9zCCCfMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICETCCAg0CAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDExMjgxOTE2NDdaMCMGCSqGSIb3DQEJBDEWBBR2LzJ0sebM16xULBgA DBYv5z4XrzAnBgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAQ64atkEGKimksIZAZOKPCpop49OFrmruMAdzOe+dQKCJdwUHOydSYbQ7 6D+5yONksLdpViW4/7Q5UVawFqUdAdExYk9IiECtoQ9G5+s6YFV4oDOk7wS0yWDvLFWWRNb9 mgq9obWppoKmlJOcsf9V1jHMtBIsuiLgX4X9nT0Mk5s= --------------ms6914D9666FC116FE578EC013-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 11:56:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eASJsrk25922 for ipng-dist; Tue, 28 Nov 2000 11:54:53 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eASJsiK25915 for ; Tue, 28 Nov 2000 11:54:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA18280 for ; Tue, 28 Nov 2000 11:54:43 -0800 (PST) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00299 for ; Tue, 28 Nov 2000 11:54:42 -0800 (PST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 140qpq-0002UC-00; Tue, 28 Nov 2000 14:54:38 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA17126; Tue, 28 Nov 00 14:49:44 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id OAA21433; Tue, 28 Nov 2000 14:54:01 -0500 Message-Id: <3A240D7F.415C9A29@txc.com> Date: Tue, 28 Nov 2000 14:54:39 -0500 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Brian E Carpenter Cc: Christian Huitema , Michael Thomas , Jim Bound , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <3A23DB41.3C395A22@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms328D1542562C83ED9369220A" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms328D1542562C83ED9369220A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian, Brian E Carpenter wrote: > [...] > e) the only way I can see to do this is to compress port # and protocol # > information into the flow label. > [...] > > Brian Brian, This would allow any router on the path of a packet to apply the same 5-tuple classification rules, which is a nice feature. But, I am not sure why you exclude other ways, like associating a particular value to the 5-tuple, ala MPLS, and have all downstream routers "know" and classify based on that "known" value. As classification is done for practical purposes to place packets in distinct processing queues, I have mixed thoughts about the practicality of having both source and destination port numbers, and as a matter of fact the 5-tuple for that purpose. I wonder in fact, if one would have a straight answer on how many router implementations, including IPv4 ones, do per flow (5-tuple) queuing today, or plan to have that in the future. Alex > > Christian Huitema wrote: > > > > Brian, > > > > I am a bit puzzled by your reference to the 5 tuple as "enabling diffserv." > > I think you have a model there in which the diffserv bits are set by some > > intermediate router, after examining the "5 tuple" of the packet. In this > > context, the five-tuple works somewhat. But it does not work well with IPSEC > > (ports are hidden), it does not work well with floating port applications > > such as VoIP, and it leads to some interesting header manipulation when we > > encounter stacks of IPv6 headers. > > > > There are at least two other ways to "enable diffserv." One way would be to > > just let the hosts set the diffserv bits, and then let the intermediate > > router do accounting, charging, and maybe rationing. Another way is to use > > RSVP to convey the requested quality of service, and the user credentials, > > to the intermediate routers; then, the flow-id can be use for flow > > classification, and the intermediate routers can on this basis set the > > diffserv bits however they see fit. > > > > -- Christian Huitema >>[....] --------------ms328D1542562C83ED9369220A Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKBgYJKoZIhvcNAQcCoIIJ9zCCCfMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICETCCAg0CAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDExMjgxOTU0NDFaMCMGCSqGSIb3DQEJBDEWBBSX5PPoQ78xrJIfwOKa RkYBVbwjBDAnBgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAFOuGnuxZ46fuRofPPZJyP9xvmjxn8kc8Et0X/7CnB49cATfyKHyya5w2 MFlNENCxylxs82e3ZqM9RtdfCjzjv9TRmi1kVH8YMoixhig0QbtUYO8lmXNZn8OG57hO6Ggh kXNFARCeCPd5bAUHXVS8WEyNwF4Sn3rkDV2GhbE280Q= --------------ms328D1542562C83ED9369220A-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 15:07:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eASN6NG26155 for ipng-dist; Tue, 28 Nov 2000 15:06:23 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eASN6EK26148 for ; Tue, 28 Nov 2000 15:06:14 -0800 (PST) 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,v1.7) with ESMTP id PAA23276 for ; Tue, 28 Nov 2000 15:06:14 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02257 for ; Tue, 28 Nov 2000 16:06:13 -0700 (MST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA134512; Tue, 28 Nov 2000 15:01:14 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA32690; Tue, 28 Nov 2000 15:06:10 -0800 Message-ID: <3A24361E.3947A848@hursley.ibm.com> Date: Tue, 28 Nov 2000 16:47:58 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Alex Conta CC: Christian Huitema , Michael Thomas , Jim Bound , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <3A23DB41.3C395A22@hursley.ibm.com> <3A240D7F.415C9A29@txc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, The problem is that any such association is pretty much likely to disappear across ISP/ISP boundaries, unless there is a global standard for the semantics. Brian Alex Conta wrote: > > Brian, > > Brian E Carpenter wrote: > > [...] > > e) the only way I can see to do this is to compress port # and protocol # > > information into the flow label. > > [...] > > > > Brian > > Brian, > > This would allow any router on the path of a packet to apply the same > 5-tuple > classification rules, which is a nice feature. > > But, I am not sure why you exclude other ways, like associating a > particular > value to the 5-tuple, ala MPLS, and have all downstream routers "know" > and > classify based on that "known" value. > > As classification is done for practical purposes to place packets in > distinct processing queues, I have mixed thoughts about the practicality > of > having both source and destination port numbers, and as a matter of fact > the > 5-tuple for that purpose. I wonder in fact, if one would have a straight > answer > on how many router implementations, including IPv4 ones, do per flow > (5-tuple) > queuing today, or plan to have that in the future. > > Alex > > > > > Christian Huitema wrote: > > > > > > Brian, > > > > > > I am a bit puzzled by your reference to the 5 tuple as "enabling diffserv." > > > I think you have a model there in which the diffserv bits are set by some > > > intermediate router, after examining the "5 tuple" of the packet. In this > > > context, the five-tuple works somewhat. But it does not work well with IPSEC > > > (ports are hidden), it does not work well with floating port applications > > > such as VoIP, and it leads to some interesting header manipulation when we > > > encounter stacks of IPv6 headers. > > > > > > There are at least two other ways to "enable diffserv." One way would be to > > > just let the hosts set the diffserv bits, and then let the intermediate > > > router do accounting, charging, and maybe rationing. Another way is to use > > > RSVP to convey the requested quality of service, and the user credentials, > > > to the intermediate routers; then, the flow-id can be use for flow > > > classification, and the intermediate routers can on this basis set the > > > diffserv bits however they see fit. > > > > > > -- Christian Huitema > >>[....] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 16:06:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAT04vB26419 for ipng-dist; Tue, 28 Nov 2000 16:04:57 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAT04mK26412 for ; Tue, 28 Nov 2000 16:04:48 -0800 (PST) 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,v1.7) with ESMTP id QAA02471 for ; Tue, 28 Nov 2000 16:04:49 -0800 (PST) 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 RAA01790 for ; Tue, 28 Nov 2000 17:04:47 -0700 (MST) 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 QAA23218; Tue, 28 Nov 2000 16:04:46 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eAT04i830117; Tue, 28 Nov 2000 16:04:44 -0800 X-Virus-Scanned: Tue, 28 Nov 2000 16:04:44 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdOFTnoW; Tue, 28 Nov 2000 16:04:39 PST Message-Id: <4.3.2.7.2.20001128155855.01c04408@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Nov 2000 16:02:29 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: W.G. Last Call on "Transmission of IPv6 Packets over IEEE 1394 Networks" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as a Proposed Standard: Title : Transmission of IPv6 Packets over IEEE 1394 Networks Author(s) : K. Fujisawa, A. Onoe Filename : draft-ietf-ipngwg-1394-00.txt Pages : 7 Date : 14-Nov-00 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on December 12, 2000. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 17:33:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAT1WH226497 for ipng-dist; Tue, 28 Nov 2000 17:32:17 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAT1W6K26490 for ; Tue, 28 Nov 2000 17:32:07 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA16969 for ; Tue, 28 Nov 2000 17:32:06 -0800 (PST) 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 RAA14222 for ; Tue, 28 Nov 2000 17:32:05 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id KAA28501; Wed, 29 Nov 2000 10:31:57 +0900 (JST) cc: Brian E Carpenter , "Ipng (E-Mail)" In-reply-to: itojun's message of Tue, 28 Nov 2000 07:12:28 JST. <20001127221228.9561E7E20@starfruit.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: Usage of IPv6 flow label From: itojun@iijlab.net Date: Wed, 29 Nov 2000 10:31:57 +0900 Message-ID: <28499.975461517@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>Only if we define a standard way of compressing the ports and protocol type >>into the flow label. > i don't think there needs to be a standard way. if there's some > pseudorandom and unique number in flow label field (as suggested in > RFC2460) it is more than enough. oops, what I meant here was: - router/RSVP device looks at full 5-tuple, on the first packet it sees, and remember flow label value (need to chase extension headers) - for subsequent packets router/RSVP device will classify packets based on flow label value there's no need for compression rule from 5-tuple to flow label (some other protocol may use something other than 5-tuple!) I admit that ESP case is tricky. 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 Nov 28 21:09:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAT584K26689 for ipng-dist; Tue, 28 Nov 2000 21:08:04 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAT57tK26682 for ; Tue, 28 Nov 2000 21:07:56 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA15614 for ; Tue, 28 Nov 2000 21:07:55 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA12781 for ; Tue, 28 Nov 2000 21:07:54 -0800 (PST) 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 VAA16130; Tue, 28 Nov 2000 21:07:53 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eAT57oG20590; Tue, 28 Nov 2000 21:07:50 -0800 X-Virus-Scanned: Tue, 28 Nov 2000 21:07:50 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from Ihinden-3.iprg.nokia.com (205.226.22.76, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdLVJ5pR; Tue, 28 Nov 2000 21:07:38 PST Message-Id: <4.3.2.7.2.20001128210212.0224cfa0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Nov 2000 21:05:03 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPng Agenda for San Diego IETF Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached is the proposed agenda for IPng w.g. sessions at the San Diego IETF. We received requests for talks equaling the total time. Consequentially we gave priority to current working group activities and documents, new individual submissions, and last to status reports. Speakers should plan to keep their talk within the allotted time including discussion. The chairs will do our best to keep to this agenda. Please send us comments, additions, and deletions. Thanks, Bob Hinden Steve Deering ------------------------------------------------------------------------- WEDNESDAY, December 13, 2000 1300-1500 Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) Document Status / R. Hinden (10 min) Summary of Internet Address Registry Presentations / Alain Durand (15 min) Source/Destination Address Selection / Rich Draves (20 min) An analysis of IPv6 anycast / Itojun Hagino (10 min) Analysis of DNS Server Discovery Mechanisms for IPv6 / Dave Thaler (30 min) Discovery of Resource Records Designating IPv6 Address prefixes / Matt Crawford (10 min) Socket API for IPv6 traffic class field / Itojun Hagino (5 min) THURSDAY, December 14, 2000 1530-1730 ------------------------------------- Default Router Preferences & More Specific Routes in RAs / Rich Draves (15 min) Automatic Prefix Delegation Protocol for IPv6 / Brian Haberman (10 min) Destination Option Headers Cleanup / Francis Dupont (15 min) An end-to-end usage of IPv6 flow label / Jochen Metzler (15 min) Socket API for IPv6 flow label field / Itojun Hagino (5 min) Multihoming / Masataka Ohta (10 min) Record Route Hop-by-Hop Option for IPv6 / Hiroshi Kitamura (10 min) ETSI bake-off report / Francis Dupont (5 min) Overview of USAGI Project (Linux IPv6 Improvement Project) / Yuji Sekiya (5 min) Site renumbering using router renumbering protocol / Tatuya Jinmei (10 min) How to write UDP/IPv6 applications that care about path MTU / Tatuya Jinmei (10 min) Status of OSPFv3 implementation for Zebra / Yasuhiro Ohara (10 min) -------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 03:29:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eATBSDp26970 for ipng-dist; Wed, 29 Nov 2000 03:28:13 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eATBS2K26963 for ; Wed, 29 Nov 2000 03:28:02 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA00103 for ; Wed, 29 Nov 2000 03:28:01 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA13956 for ; Wed, 29 Nov 2000 03:28:01 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29960; Wed, 29 Nov 2000 06:27:59 -0500 (EST) Message-Id: <200011291127.GAA29960@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-dns-discovery-00.txt Date: Wed, 29 Nov 2000 06:27:59 -0500 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 IPNG Working Group of the IETF. Title : Analysis of DNS Server Discovery Mechanisms for IPv6 Author(s) : D. Thaler Filename : draft-ietf-ipngwg-dns-discovery-00.txt Pages : 43 Date : 28-Nov-00 There are any number of ways that IPv6 hosts can discover information required to enable name resolution, in the absence of a DHCP server. This document discusses the issues and provides a taxonomy of possible solutions, and evaluates them against various design criteria. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-discovery-00.txt 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-dns-discovery-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-dns-discovery-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: <20001128133723.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-dns-discovery-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-dns-discovery-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128133723.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 Nov 29 05:37:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eATDaHZ27109 for ipng-dist; Wed, 29 Nov 2000 05:36:17 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eATDa8K27102 for ; Wed, 29 Nov 2000 05:36:08 -0800 (PST) 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,v1.7) with ESMTP id FAA29448 for ; Wed, 29 Nov 2000 05:36:08 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05550 for ; Wed, 29 Nov 2000 05:36:07 -0800 (PST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id OAA29277; Wed, 29 Nov 2000 14:35:51 +0100 (MET) Date: Wed, 29 Nov 2000 14:35:50 +0100 From: Ignatios Souvatzis To: Brian Haberman Cc: IPng Mailing List Subject: Re: [Fwd: I-D ACTION:draft-haberman-ipngwg-auto-prefix-00.txt] Message-ID: <20001129143550.A27269@theory.cs.uni-bonn.de> References: <3A226D74.142B85D9@nortelnetworks.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A226D74.142B85D9@nortelnetworks.com>; from haberman@nortelnetworks.com on Mon, Nov 27, 2000 at 09:19:32AM -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 27, 2000 at 09:19:32AM -0500, Brian Haberman wrote: > > Title : Automatic Prefix Delegation Protocol for Inte= rnet > > Protocol Version 6 (IPv6) > > Author(s) : B. Haberman, J. Martin > > Filename : draft-haberman-ipngwg-auto-prefix-00.txt First comments, and a question: 1. I suggest to swap the "Routing capabilites" with the "Reserved" field=20 in 5.1 Prefix Request Message; and also the "Lifetime" with the "Rt Prot= o" field in 5.2 Prefix Delegation Message. This way, the 16 bit field is naturally aligned (assuming alignment of= =20 the whole packet buffer) and can be accessed more efficient by a lot of devices. 2. This one is probably covered by "6. To Do's: additional security discussion"... My impression is that there are all sorts of DOS (and worse) attacks possible if no authentication header is used. (This happens for lots of routing-like protools, of course.) This must be pointed out in the Secur= ity Discussion. 3. What are the differences between this protocol and Router Renumbering? What are the interactions between this protocol and Router Renumbering? Regards, -is --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBOiUGIjCn4om+4LhpAQHDjwgAo3AEsdOaNEatGD9V0cFwucFSBk2bHfh9 Ljjw/k7wHCyb5ZvaLff72f0vABEOZl49k+C4kCOysIP1UbE0PYd8BmwEcDdHu5+Z S37TeClnC3vJ8o3KjAoBrdjNmrbw7n6luB6BEjOKCmQ/flkx127PqvEWMPpP+VSm Pk444RLM7ec8OqcSMIC/A7DHXom1WvwZe9a34BISLPbRgc0q03idmMqrkfKG3ApN yfKs6kKw9WIwfC4MtSaeRszVaJlvWPaJxnTtWVWH4TUTMW9gdaB4UPGW2S9hrE3B AEvC4c7TwgrzCdByIWAyTvGxFBw05PNmqKvo1B+wVbM9lBY8UTdGPg== =/am0 -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 06:41:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eATEdmL27201 for ipng-dist; Wed, 29 Nov 2000 06:39:48 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eATEddK27194 for ; Wed, 29 Nov 2000 06:39:39 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA00921 for ; Wed, 29 Nov 2000 06:39:39 -0800 (PST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA27028 for ; Wed, 29 Nov 2000 06:39:38 -0800 (PST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA00925; Wed, 29 Nov 2000 15:39:09 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA02096; Wed, 29 Nov 2000 15:39:36 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 15:39:35 +0100 Message-ID: <158669A6D0F5D3119B940060086D94F55006EF@ULML202E> From: Metzler Jochen To: "'Elwyn Davies'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: WG: Usage of IPv6 flow label Date: Wed, 29 Nov 2000 15:39:05 +0100 X-Message-Flag: Zur Nachverfolgung MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 1. draft-metzler-ipv6-flowlabel-00 - the mechanisms proposed in this draft are not something that we should be supporting - it proposes polluting a network layer header with application layer info. If an application needs to multiplex streams onto a single socket in the way proposed it could equally well format the PDU in an appropriate way without layer pollution. you missed the thing that it is not the intention of that draft to pollute the network layer with application layer information. you are right in a way that an application can / should handle multiplexing of streams internally. but imagine that applications that request a special handling by the network for every single stream, especially wanting all packets belonging to one single stream to take the same way through the network. in that case the application must signal the network which packets belong to which flow. the flow label would be the right place for doing this, there would be no mixture of network layers. as shown by some other protocols (e.g. HC) it is legitimate to use lower layer information on upper layer protocols. if it is e-t-e or mutable a fully standardized flow label would help in both cases application and network design. best regards jochen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 08:24:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eATGNFi27460 for ipng-dist; Wed, 29 Nov 2000 08:23:15 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eATGN6K27453 for ; Wed, 29 Nov 2000 08:23:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA21584 for ; Wed, 29 Nov 2000 08:23:06 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19183 for ; Wed, 29 Nov 2000 08:23:06 -0800 (PST) Received: from ValuedSonyCustomer (as1b-234.chi.il.dial.anet.com [198.92.157.234]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id KAA28446 for ; Wed, 29 Nov 2000 10:15:54 -0600 (CST) Message-ID: <04a701c05a1f$dfc09480$df00a8c0@ValuedSonyCustomer> From: "JIM FLEMING" To: Subject: Fw: 0:201 COM IPv6 Servers Date: Wed, 29 Nov 2000 10:17:29 -0600 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: JIM FLEMING To: Sent: Wednesday, November 29, 2000 10:12 AM Subject: 0:201 COM IPv6 Servers > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp > > 0:201 COM > > Has any registry company stepped forward to provide "native" IPv6 > DNS servers for the COM Community ? > > Will all 20+ million companies have to also pay for IPv6 service ? > ...will it be an option ?...or added on automatically by "registrars" ? > > > Jim Fleming > http://www.unir.com > Mars 128n 128e > http://www.unir.com/images/architech.gif > http://www.unir.com/images/address.gif > http://www.unir.com/images/headers.gif > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 08:29:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eATGSYw27497 for ipng-dist; Wed, 29 Nov 2000 08:28:34 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eATGSPK27490 for ; Wed, 29 Nov 2000 08:28:25 -0800 (PST) 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,v1.7) with ESMTP id IAA07418 for ; Wed, 29 Nov 2000 08:28:25 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA11388 for ; Wed, 29 Nov 2000 09:28:21 -0700 (MST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA84838; Wed, 29 Nov 2000 08:23:07 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA09568; Wed, 29 Nov 2000 08:28:16 -0800 Message-ID: <3A252DD5.90C57685@hursley.ibm.com> Date: Wed, 29 Nov 2000 10:24:53 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: itojun@iijlab.net CC: "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <28499.975461517@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun, To be more precise, is that what you mean: The box maintains a cache of currently active flow IDs. For each arriving packet, it looks to see if the flow ID on that packet is in the cache. If no ==> extract the 5-tuple, cache the flow ID and the 5-tuple, then apply corresponding RSVP or diffserv action. If yes ==> extract the 5-tuple from the cache, then apply corresponding RSVP or diffserv action. The problem is that for encrypted packets, the first step is impossible. Brian itojun@iijlab.net wrote: > > >>Only if we define a standard way of compressing the ports and protocol type > >>into the flow label. > > i don't think there needs to be a standard way. if there's some > > pseudorandom and unique number in flow label field (as suggested in > > RFC2460) it is more than enough. > > oops, what I meant here was: > - router/RSVP device looks at full 5-tuple, on the first packet it sees, > and remember flow label value > (need to chase extension headers) > - for subsequent packets router/RSVP device will classify packets > based on flow label value > there's no need for compression rule from 5-tuple to flow label > (some other protocol may use something other than 5-tuple!) > > I admit that ESP case is tricky. > > 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 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.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 Wed Nov 29 08:57:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eATGtvN27556 for ipng-dist; Wed, 29 Nov 2000 08:55:57 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eATGtjK27546 for ; Wed, 29 Nov 2000 08:55:46 -0800 (PST) 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,v1.7) with ESMTP id IAA29072 for ; Wed, 29 Nov 2000 08:55:45 -0800 (PST) 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 JAA02396 for ; Wed, 29 Nov 2000 09:55:43 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id BAA09785; Thu, 30 Nov 2000 01:55:10 +0900 (JST) To: Brian E Carpenter cc: "Ipng (E-Mail)" In-reply-to: brian's message of Wed, 29 Nov 2000 10:24:53 CST. <3A252DD5.90C57685@hursley.ibm.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: Usage of IPv6 flow label From: itojun@iijlab.net Date: Thu, 30 Nov 2000 01:55:10 +0900 Message-ID: <9783.975516910@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >To be more precise, is that what you mean: >The box maintains a cache of currently active flow IDs. >For each arriving packet, it looks to see if the flow ID on that >packet is in the cache. >If no ==> extract the 5-tuple, cache the flow ID and the 5-tuple, > then apply corresponding RSVP or diffserv action. >If yes ==> extract the 5-tuple from the cache, > then apply corresponding RSVP or diffserv action. Basically yes. To be even more precise, see below. I have never talked about diffserv, but it should be possible to do something about diffserv. >The problem is that for encrypted packets, the first step is impossible. yup. but the impression I've got from existing specification is, flow label is for optimization (to avoid full 5-tuple lookup in intermediate router). yes, ESP is a problem, but it always is a problem for diffserv/intserv kind of work. itojun The originating node will fill flow label field (20 bit) with pseudorandom value, as documented in RFC2460 appendix A. The value will be same for a "flow" - think of it as a TCP session (see my draft for a possible definition of "flow"). Somewhere, we will have RSVP reservation running behind-the-scene. Intermediate router has the following database: 1. database of RSVP filter spec (basically 5 tuple) and RSVP flow spec (QoS parameters) 2. cache table from flow label value, to RSVP flow spec. When a packet comes into a intermediate router, the router will behave as follows: look at flow label value, and look at database 2; if (we have an entry in database 2) we got an RSVP flow spec. else { /* if we do not have an entry in database 2 */ chase header chain, obtain full 5 tuple. lookup database 1. if (we have an entry in database 1) { we got an RSVP flow spec. register flow label value and RSVP flow spec into database 2. database 2 is a cache, so we can purge old entry if it is full. } else { we don't have an RSVP flow spec. } } forward packet based on RSVP flow spec we've got. In short, flow label makes it easier for intermediate routers to lookup QoS flow spec from a packet. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 10:01:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eATHxsk27691 for ipng-dist; Wed, 29 Nov 2000 09:59:54 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eATHxjK27684 for ; Wed, 29 Nov 2000 09:59:45 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA15585 for ; Wed, 29 Nov 2000 09:59:45 -0800 (PST) Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA17081 for ; Wed, 29 Nov 2000 09:59:43 -0800 (PST) Received: from znsgd00t.europe.nortel.com (actually znsgd00t) by qnsgs000.nortel.com; Wed, 29 Nov 2000 17:59:23 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 29 Nov 2000 17:59:22 -0000 Message-ID: <3353DE9BA890D4118DDB0020484008840F7BF8@zhard00n.europe.nortel.com> From: "Elwyn Davies" To: "'Metzler Jochen'" , "Elwyn Davies" Cc: "'ipng@sunroof.eng.sun.com'" Subject: RE: Usage of IPv6 flow label Date: Wed, 29 Nov 2000 17:59:16 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05A2E.172155F0" 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_01C05A2E.172155F0 Content-Type: text/plain Hi. I absolurely agree that it is very useful for the network to be informed that all the packets of a particular stream belong to a flow that should be treated similarly (like going along the same path). Clearly the effects of the proposals in your draft and Itojun's draft at the network level are similar but the network code can do a much better job of generating the pseudo-random numbers needed to identify the streams (otherwise you need coordination between applications) and it reduces the temptation to use the flow label for application layer stuff which is the case when your proposal is followed. Regards, Elwyn > -----Original Message----- > From: Metzler Jochen [SMTP:Jochen.Metzler@icn.siemens.de] > Sent: Wednesday, November 29, 2000 2:39 PM > To: Davies, Elwyn [HAL02:HG00:EXCH] > Cc: 'ipng@sunroof.eng.sun.com' > Subject: WG: Usage of IPv6 flow label > > > 1. draft-metzler-ipv6-flowlabel-00 - the mechanisms proposed in this > draft are not something that we should be supporting - it proposes > polluting a network layer header with application layer info. If an > application needs to multiplex streams onto a single socket in the way > proposed it could equally well format the PDU in an appropriate way > without layer pollution. > > you missed the thing that it is not the intention of that draft to pollute > the > network layer with application layer information. you are right in a way > that an application can / should handle multiplexing of streams > internally. but > imagine that applications that request a special handling by the network > for every single stream, especially wanting all packets belonging to one > single stream to take the same way through the network. in that case > the application must signal the network which packets belong to which > flow. the flow label would be the right place for doing this, there would > be no mixture of network layers. > as shown by some other protocols (e.g. HC) it is legitimate to use lower > layer information on upper layer protocols. if it is e-t-e or mutable a > fully > standardized flow label would help in both cases application and network > design. > > best regards > jochen ------_=_NextPart_001_01C05A2E.172155F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Usage of IPv6 flow label

Hi.

I absolurely agree = that it is very useful for the network to be informed that all the = packets of a particular stream belong to a flow that should be treated = similarly (like going along the same path).  Clearly the effects = of the proposals in your draft and Itojun's draft at the network level = are similar but the network code can do a much better job of generating = the pseudo-random numbers needed to identify the streams (otherwise you = need coordination between applications) and it reduces the temptation = to use the flow label for application layer stuff which is the case = when your proposal is followed.

Regards,
Elwyn

    -----Original Message-----
    From:   Metzler Jochen = [SMTP:Jochen.Metzler@icn.siemens.de]
    Sent:   Wednesday, November 29, 2000 2:39 PM
    To:     Davies, Elwyn [HAL02:HG00:EXCH]
    Cc:     'ipng@sunroof.eng.sun.com'
    Subject:       = WG: Usage of IPv6 flow label


    1.  = draft-metzler-ipv6-flowlabel-00 - the mechanisms proposed in this draft = are not something that we should be supporting - it proposes polluting = a network layer header with application layer info.  If an = application needs to multiplex streams onto a single socket in the way = proposed it could equally well format the PDU in an appropriate way = without layer pollution.

    you missed the thing that it is not = the intention of that draft to pollute the
    network layer with application layer = information. you are right in a way
    that an application can / should = handle multiplexing of streams internally. but
    imagine that applications that = request a special handling by the network
    for every single stream, especially = wanting all packets belonging to one
    single stream to take the same way = through the network. in that case
    the application must signal the = network which packets belong to which
    flow. the flow label would be the = right place for doing this, there would
    be no mixture of network layers. =
    as shown by some other protocols = (e.g. HC) it is legitimate  to use lower
    layer information on upper layer = protocols. if it is e-t-e or mutable a fully
    standardized flow label would help in = both cases application and network
    design.

    best regards
    jochen

------_=_NextPart_001_01C05A2E.172155F0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 11:29:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eATJRnn27844 for ipng-dist; Wed, 29 Nov 2000 11:27:49 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eATJRdK27836 for ; Wed, 29 Nov 2000 11:27:40 -0800 (PST) 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,v1.7) with ESMTP id LAA26839 for ; Wed, 29 Nov 2000 11:27:39 -0800 (PST) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA24592 for ; Wed, 29 Nov 2000 12:27:37 -0700 (MST) Received: by sentry.gw.tislabs.com; id OAA25878; Wed, 29 Nov 2000 14:30:33 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma025859; Wed, 29 Nov 00 14:30:30 -0500 Received: from english.tislabs.com (clipper.gw.tislabs.com [10.33.1.2]) by clipper.gw.tislabs.com (8.9.3/8.9.1) with ESMTP id OAA17719; Wed, 29 Nov 2000 14:26:50 -0500 (EST) Message-Id: <4.3.2.7.2.20001129113611.00dcdf00@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Nov 2000 14:17:58 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: DNSEXT WG Last Call: Message Size Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a DNSEXT WG last call on this document, please send your comments to mailto:namedroppers@ops.ietf.org This document updates RFC2535 and RFC2874 (A6) to demand larger UDP message size than 512 bytes. This document mandates that any entity supporting either DNSSEC or A6 records must support EDNS0 on queries and responses. The motivation(s) for this is the increase in size of DNS answers caused by DNSSEC, IPng, TSIG and large the desire for large answer sets. The document assumes that modern operating systems can do UDP reassembly, thus this the single UDP message requirement can be relaxed and this is less costly than falling back on TCP for all large answers. This WG last call ends December 17'th 2000. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-message-size-01.txt This draft is on standards track, if you disagree with that please state why in your response. Olafur -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 11:46:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eATJiae27923 for ipng-dist; Wed, 29 Nov 2000 11:44:36 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eATJiRK27916 for ; Wed, 29 Nov 2000 11:44:27 -0800 (PST) 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,v1.7) with ESMTP id LAA06990 for ; Wed, 29 Nov 2000 11:44:26 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28689 for ; Wed, 29 Nov 2000 11:44:25 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA17576; Wed, 29 Nov 2000 11:45:51 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA09662; Wed, 29 Nov 2000 11:44:23 -0800 Message-ID: <3A255B91.E6092614@hursley.ibm.com> Date: Wed, 29 Nov 2000 13:40:01 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: itojun@iijlab.net CC: "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <9783.975516910@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun, OK, I understand. However I would really like to find a solution that works for ESP packets. The proposal in draft-conta-ipv6-flow-label-00.txt isn't sufficient (it only conveys half a port number, and a general purpose QOS classifier needs two port numbers). Also it doesn't generate pseudo-uniqueness in the flow label, so the classifier actually has to classify on {source @, dest @, flow label}. That's not so bad, since it uses only fields at fixed header locations. But the flow label doesn't contain enough bits to convey {source port, destination port, protocol}. Brian itojun@iijlab.net wrote: > > >To be more precise, is that what you mean: > >The box maintains a cache of currently active flow IDs. > >For each arriving packet, it looks to see if the flow ID on that > >packet is in the cache. > >If no ==> extract the 5-tuple, cache the flow ID and the 5-tuple, > > then apply corresponding RSVP or diffserv action. > >If yes ==> extract the 5-tuple from the cache, > > then apply corresponding RSVP or diffserv action. > > Basically yes. To be even more precise, see below. I have never > talked about diffserv, but it should be possible to do something > about diffserv. > > >The problem is that for encrypted packets, the first step is impossible. > > yup. but the impression I've got from existing specification is, > flow label is for optimization (to avoid full 5-tuple lookup in > intermediate router). yes, ESP is a problem, but it always is a > problem for diffserv/intserv kind of work. > > itojun > > The originating node will fill flow label field (20 bit) with pseudorandom > value, as documented in RFC2460 appendix A. The value will be same for a > "flow" - think of it as a TCP session (see my draft for a possible definition > of "flow"). > > Somewhere, we will have RSVP reservation running behind-the-scene. > > Intermediate router has the following database: > 1. database of RSVP filter spec (basically 5 tuple) and RSVP flow spec > (QoS parameters) > 2. cache table from flow label value, to RSVP flow spec. > When a packet comes into a intermediate router, the router will behave as > follows: > look at flow label value, and look at database 2; > if (we have an entry in database 2) > we got an RSVP flow spec. > else { /* if we do not have an entry in database 2 */ > chase header chain, obtain full 5 tuple. > lookup database 1. > if (we have an entry in database 1) { > we got an RSVP flow spec. > register flow label value and RSVP flow spec into > database 2. database 2 is a cache, so we can purge > old entry if it is full. > } else { > we don't have an RSVP flow spec. > } > } > > forward packet based on RSVP flow spec we've got. > > In short, flow label makes it easier for intermediate routers to lookup > QoS flow spec from a packet. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.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 Wed Nov 29 13:12:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eATL8i228138 for ipng-dist; Wed, 29 Nov 2000 13:08:44 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eATL8VK28131 for ; Wed, 29 Nov 2000 13:08:31 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA29170 for ; Wed, 29 Nov 2000 13:08:30 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA00660 for ; Wed, 29 Nov 2000 13:08:25 -0800 (PST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id WAA05625; Wed, 29 Nov 2000 22:08:09 +0100 (MET) Date: Wed, 29 Nov 2000 22:08:09 +0100 From: Ignatios Souvatzis To: Brian E Carpenter Cc: itojun@iijlab.net, "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label Message-ID: <20001129220809.C5347@theory.cs.uni-bonn.de> References: <9783.975516910@coconut.itojun.org> <3A255B91.E6092614@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A255B91.E6092614@hursley.ibm.com>; from brian@hursley.ibm.com on Wed, Nov 29, 2000 at 01:40:01PM -0600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id eATL8WK28132 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Nov 29, 2000 at 01:40:01PM -0600, Brian E Carpenter wrote: > OK, I understand. However I would really like to find a solution > that works for ESP packets. The basic idea about ESP is that we do not want to leak information. Putting port of it into the flow label is therefore not what we want to do. Regards, -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 13:37:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eATLYkO28223 for ipng-dist; Wed, 29 Nov 2000 13:34:47 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eATLYWK28216 for ; Wed, 29 Nov 2000 13:34:33 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA16154 for ; Wed, 29 Nov 2000 13:34:31 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06229 for ; Wed, 29 Nov 2000 13:34:30 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA27326; Wed, 29 Nov 2000 13:35:55 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA09480; Wed, 29 Nov 2000 13:34:28 -0800 Message-ID: <3A257518.368052DE@hursley.ibm.com> Date: Wed, 29 Nov 2000 15:28:56 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ignatios Souvatzis CC: itojun@iijlab.net, "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <9783.975516910@coconut.itojun.org> <3A255B91.E6092614@hursley.ibm.com> <20001129220809.C5347@theory.cs.uni-bonn.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We would have to evaluate the risk (which I guess is traffic analysis) versus the benefit (ability to provide QOS). That sounds like a user decision to me. Brian Ignatios Souvatzis wrote: > > On Wed, Nov 29, 2000 at 01:40:01PM -0600, Brian E Carpenter wrote: > > > OK, I understand. However I would really like to find a solution > > that works for ESP packets. > > The basic idea about ESP is that we do not want to leak information. > Putting port of it into the flow label is therefore not what we want to do. > > Regards, > -is > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 30 01:18:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAU9GNH01066 for ipng-dist; Thu, 30 Nov 2000 01:16:23 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAU9G8r01059 for ; Thu, 30 Nov 2000 01:16:08 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA01534 for ; Thu, 30 Nov 2000 01:16:07 -0800 (PST) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA00998 for ; Thu, 30 Nov 2000 01:16:07 -0800 (PST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 141Pov-0000NN-00; Thu, 30 Nov 2000 04:16:01 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA00829; Thu, 30 Nov 00 04:11:07 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id EAA06204; Thu, 30 Nov 2000 04:15:12 -0500 Message-Id: <3A261AD1.4A11D848@txc.com> Date: Thu, 30 Nov 2000 04:16:01 -0500 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Elwyn Davies Cc: "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label References: <3353DE9BA890D4118DDB0020484008840F7BF1@zhard00n.europe.nortel.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5AB6BBB30970C715B80CF45D" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms5AB6BBB30970C715B80CF45D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Elwyn > Elwyn Davies wrote: > [...] > > 3. The e2e mutability issue has been done to death in DiffServ for > code points and it sounds like the whole argument is being trotted out > again. The one and only fundamental point is that if the flow label > is mutable, information is generally lost when it is changed after > original setting and can never be restored unless there is some > additional agency available to regenerate the information (entropy > argument). If the label is changed in a way that does not lose > information then it doesn't matter; likewise, if you don't care about > the loss of information then go ahead and change it. > More explicitly, the information can be a combination of labels and state in each router, ala MPLS. Labels can change from one node to another, but the state in which node, links the input label value to the output label value, without affecting the information being transmitted. > 4. The flow label could clearly (also) be used as a signalling method > to help out with inter-domain MPLS issues when you need to cross > exchange points where the whole MPLS header has to be removed. > I am not sure about the practical value of this. If two MPLS domains are logically disjoint, I think that there are practical reasons - they are not physically adjacent, or if they are, the logical separation is desired, which seems to make more sense with a new MPLS classification at the downstream domain border. > I concur fully with Brian Carpenter's points on orthogonality of > DiffServ and MPLS. [...] > > Regards, > Elwyn Davies > I think the orthogonality is relative. MPLS labels may carry Diffserv, and Intserv information, and may be derived based on Diffserv, and Intserv information. I would not necessarily call that orthogonal. Alex --------------ms5AB6BBB30970C715B80CF45D Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKBgYJKoZIhvcNAQcCoIIJ9zCCCfMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICETCCAg0CAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDExMzAwOTE2MDNaMCMGCSqGSIb3DQEJBDEWBBREbl5XTq2wAo83+JiN +gUCuJEk1DAnBgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGACPag2RFLqIL9aMl1Ec+jVQFCjYE11+PQKI4JBugb1iUFoS9/G7DGW2O8 S+MjBB8f/+2Z8uTUkZXzoc6BSSGSG25z55eTMLzM43jfcCHX56TdZS6udU7GPzOoIw2JYUcf kThEaae9NM+RMXy3uQXU6dIbR1zGEsjGyv5XfXTiBtA= --------------ms5AB6BBB30970C715B80CF45D-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 30 02:00:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAU9wna01111 for ipng-dist; Thu, 30 Nov 2000 01:58:49 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAU9wer01104 for ; Thu, 30 Nov 2000 01:58:40 -0800 (PST) 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,v1.7) with ESMTP id BAA11061 for ; Thu, 30 Nov 2000 01:58:38 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA01046 for ; Thu, 30 Nov 2000 02:58:37 -0700 (MST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id KAA14059; Thu, 30 Nov 2000 10:58:30 +0100 (MET) Date: Thu, 30 Nov 2000 10:58:30 +0100 From: Ignatios Souvatzis To: Brian E Carpenter Cc: Ignatios Souvatzis , itojun@iijlab.net, "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label Message-ID: <20001130105830.A13992@theory.cs.uni-bonn.de> References: <9783.975516910@coconut.itojun.org> <3A255B91.E6092614@hursley.ibm.com> <20001129220809.C5347@theory.cs.uni-bonn.de> <3A257518.368052DE@hursley.ibm.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A257518.368052DE@hursley.ibm.com>; from brian@hursley.ibm.com on Wed, Nov 29, 2000 at 03:28:56PM -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Nov 29, 2000 at 03:28:56PM -0600, Brian E Carpenter wrote: > We would have to evaluate the risk (which I guess is traffic analysis) > versus the benefit (ability to provide QOS). That sounds like a > user decision to me. Of course. Which is, why I think intermediate routers will have to interpret flow labels as magic cookies. Maybe changing them (I have no strong opinion about this), maybe internally sorting them according to a flow label - address/protocol/port mapping for unencrypted packets; but as protocol designers, we can't enforce a static mapping, else we would make hiding of flow properties through ESP impossible to the users. Regards, -is --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBOiYkwTCn4om+4LhpAQEiAwf/e3F/qU56xUdJiKxak2ZE6p02fdYZJ6l2 y3LJ+myGrDKLmRSns0vI00gcB+KIR1TDK6Kbc98XHN9p68qCzVgkGirf6FiH9vM9 nxL38qE72+kYUK/O/n3GKorSAz7qDwQfK0fErPuNUOfV+OQQyL8SwLI03HAKDk0V j3cSuLXiX7jGXYZNyvCVfHZu1bfyOiglLcK/00xi2TluK/PGyF3DIBUBFUEO1a1r tNORcC83gfTzVjaP6dP+n9o3WudxVSENIuNxdJ+UPLiZSvgdFfYbOOU8t0qdiaYm ab7plGmiigrMBAzs4CHVKhYgRwQ9QNYeD3hj86P2IqkciG3l2h/Ksw== =k27i -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 30 02:20:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAUAIh001153 for ipng-dist; Thu, 30 Nov 2000 02:18:43 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAUAIJr01146 for ; Thu, 30 Nov 2000 02:18:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA05703 for ; Thu, 30 Nov 2000 02:18:18 -0800 (PST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13258 for ; Thu, 30 Nov 2000 02:18:17 -0800 (PST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA19409; Thu, 30 Nov 2000 11:17:49 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA15045; Thu, 30 Nov 2000 11:18:15 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 11:18:15 +0100 Message-ID: <158669A6D0F5D3119B940060086D94F55006F0@ULML202E> From: Metzler Jochen To: "'Elwyn Davies'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: AW: Usage of IPv6 flow label Date: Thu, 30 Nov 2000 11:18:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I fully agree with Itojun's draft on generating the flow label within the network code. But I see no reason, why it should not be (at least) readable from application layer and why a single UDP or TCP session should not handle more than one streams. Regards, Jochen Hi. I absolurely agree that it is very useful for the network to be informed that all the packets of a particular stream belong to a flow that should be treated similarly (like going along the same path). Clearly the effects of the proposals in your draft and Itojun's draft at the network level are similar but the network code can do a much better job of generating the pseudo-random numbers needed to identify the streams (otherwise you need coordination between applications) and it reduces the temptation to use the flow label for application layer stuff which is the case when your proposal is followed. Regards, Elwyn -----Original Message----- From: Metzler Jochen [SMTP:Jochen.Metzler@icn.siemens.de] Sent: Wednesday, November 29, 2000 2:39 PM To: Davies, Elwyn [HAL02:HG00:EXCH] Cc: 'ipng@sunroof.eng.sun.com' Subject: WG: Usage of IPv6 flow label 1. draft-metzler-ipv6-flowlabel-00 - the mechanisms proposed in this draft are not something that we should be supporting - it proposes polluting a network layer header with application layer info. If an application needs to multiplex streams onto a single socket in the way proposed it could equally well format the PDU in an appropriate way without layer pollution. you missed the thing that it is not the intention of that draft to pollute the network layer with application layer information. you are right in a way that an application can / should handle multiplexing of streams internally. but imagine that applications that request a special handling by the network for every single stream, especially wanting all packets belonging to one single stream to take the same way through the network. in that case the application must signal the network which packets belong to which flow. the flow label would be the right place for doing this, there would be no mixture of network layers. as shown by some other protocols (e.g. HC) it is legitimate to use lower layer information on upper layer protocols. if it is e-t-e or mutable a fully standardized flow label would help in both cases application and network design. best regards jochen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 30 02:38:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAUAagx01202 for ipng-dist; Thu, 30 Nov 2000 02:36:42 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAUAaVr01195 for ; Thu, 30 Nov 2000 02:36:31 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA17698 for ; Thu, 30 Nov 2000 02:36:30 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA25286 for ; Thu, 30 Nov 2000 02:36:29 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id TAA23235; Thu, 30 Nov 2000 19:33:25 +0900 (JST) To: Metzler Jochen cc: "'Elwyn Davies'" , "'ipng@sunroof.eng.sun.com'" In-reply-to: Jochen.Metzler's message of Thu, 30 Nov 2000 11:18:08 +0100. <158669A6D0F5D3119B940060086D94F55006F0@ULML202E> 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: AW: Usage of IPv6 flow label From: itojun@iijlab.net Date: Thu, 30 Nov 2000 19:33:25 +0900 Message-ID: <23233.975580405@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Hi, >I fully agree with Itojun's draft on generating the flow label within the network code. But >I see no reason, why it should not be (at least) readable from application layer and why >a single UDP or TCP session should not handle more than one streams. I admit there could be people who wants to use: - multiple flows (= multiple flow label value) in a single TCP session - multiple TCP sessions with single flow label value however, I could not find a good (a simple and usable) UNIX API to make the above option happen, so I simplified the story. At least, the latter case can easily be handled by "single TCP session per single flow label". I documented the issue in section 5 of my draft. 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 Nov 30 02:53:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAUAqF401225 for ipng-dist; Thu, 30 Nov 2000 02:52:15 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAUAq4r01218 for ; Thu, 30 Nov 2000 02:52:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA07883 for ; Thu, 30 Nov 2000 02:52:04 -0800 (PST) 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 CAA05425 for ; Thu, 30 Nov 2000 02:52:03 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25513; Thu, 30 Nov 2000 05:52:00 -0500 (EST) Message-Id: <200011301052.FAA25513@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-default-addr-select-02.txt Date: Thu, 30 Nov 2000 05:51:59 -0500 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 IPNG Working Group of the IETF. Title : Default Address Selection for IPv6 Author(s) : R. Draves Filename : draft-ietf-ipngwg-default-addr-select-02.txt Pages : 19 Date : 29-Nov-00 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-default-addr-select-02.txt 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-default-addr-select-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-default-addr-select-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001129114034.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-default-addr-select-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-default-addr-select-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001129114034.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 Nov 30 02:57:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAUAuo601247 for ipng-dist; Thu, 30 Nov 2000 02:56:50 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAUAuer01240 for ; Thu, 30 Nov 2000 02:56:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA18860 for ; Thu, 30 Nov 2000 02:56:39 -0800 (PST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10022 for ; Thu, 30 Nov 2000 02:56:37 -0800 (PST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA25723; Thu, 30 Nov 2000 11:56:09 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA00563; Thu, 30 Nov 2000 11:56:35 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 11:56:34 +0100 Message-ID: <158669A6D0F5D3119B940060086D94F55006F2@ULML202E> From: Metzler Jochen To: "'itojun@iijlab.net'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: AW: AW: Usage of IPv6 flow label Date: Thu, 30 Nov 2000 11:56:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id eAUAufr01241 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Itojun, I am not a kernel specialist, but I assume that from a performance point of view it would be much more performant to have several flows using only one socket instead of having a single socket for each flow? An other concern is the redundancy of information in ports and labels. Cheers, Jochen ------------------------------------------------------------------ Jochen Metzler Siemens AG Lise-Meitner-Straße 5, 89081 Ulm Phone: +49.(0)731.9533.390 Mobile Networks Fax : +49.(0)731.9533.336 ICM N MR UR SE 2 mailto: jochen.metzler@icn.siemens.de -----Ursprüngliche Nachricht----- Von: itojun@iijlab.net [SMTP:itojun@iijlab.net] Gesendet am: Donnerstag, 30. November 2000 11:33 An: Metzler Jochen Cc: 'Elwyn Davies'; 'ipng@sunroof.eng.sun.com' Betreff: Re: AW: Usage of IPv6 flow label >Hi, >I fully agree with Itojun's draft on generating the flow label within the network code. But >I see no reason, why it should not be (at least) readable from application layer and why >a single UDP or TCP session should not handle more than one streams. I admit there could be people who wants to use: - multiple flows (= multiple flow label value) in a single TCP session - multiple TCP sessions with single flow label value however, I could not find a good (a simple and usable) UNIX API to make the above option happen, so I simplified the story. At least, the latter case can easily be handled by "single TCP session per single flow label". I documented the issue in section 5 of my draft. 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 Nov 30 04:21:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAUCK1T01317 for ipng-dist; Thu, 30 Nov 2000 04:20:01 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAUCJor01310 for ; Thu, 30 Nov 2000 04:19:50 -0800 (PST) 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,v1.7) with ESMTP id EAA20654 for ; Thu, 30 Nov 2000 04:19:49 -0800 (PST) Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA13616 for ; Thu, 30 Nov 2000 05:19:46 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 25E5B7E20; Thu, 30 Nov 2000 21:19:17 +0900 (JST) To: Metzler Jochen Cc: "'ipng@sunroof.eng.sun.com'" In-reply-to: Jochen.Metzler's message of Thu, 30 Nov 2000 11:56:21 +0100. <158669A6D0F5D3119B940060086D94F55006F2@ULML202E> 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: AW: AW: Usage of IPv6 flow label From: Jun-ichiro itojun Hagino Date: Thu, 30 Nov 2000 21:19:17 +0900 Message-Id: <20001130121917.25E5B7E20@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I am not a kernel specialist, but I assume that from >a performance point of view it would be much more performant >to have several flows using only one socket instead of >having a single socket for each flow? I believe there's no performance issue here. what kind of performace drawback do you have in mind? I can imagine a use of multiple flow label values for single TCP/UDP session, if: - a single TCP session includes traffic with different characteristics, for example, MPEG key frames (full picture) and intermediate data (differences between Nth full picture to (N+1)th full picture) - the application would like to enforce different RSVP characteristics to key frames and intermediate data. - so, application would like to label packets with key frames with flow label X, and intermediate data with flow label Y. packets with flow label X will have a higher priority than those with flow label Y. i'm not sure if the above example makes sense or not. even if the example is okay, there's absolutely no kernel performance issue here. the reason why we use two flow label values (X and Y) is from the applicatoin needs, not from kernel performance issues. >An other concern is the redundancy of information in >ports and labels. as i noted in previous messages, the purpose of flow label value is to provide quick lookup of L4 port pair and protocol type. so I would say that the redundancy is expected. the redundancy is what we really want - intermediate routers do not want to chase extension headers to find L4 header. 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 Nov 30 07:32:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAUFU7s01425 for ipng-dist; Thu, 30 Nov 2000 07:30:07 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAUFTwr01418 for ; Thu, 30 Nov 2000 07:29:58 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA10864 for ; Thu, 30 Nov 2000 07:29:59 -0800 (PST) Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA09443 for ; Thu, 30 Nov 2000 07:29:54 -0800 (PST) Received: from zhard00e.europe.nortel.com by qhars002.nortel.com; Thu, 30 Nov 2000 15:29:03 +0000 Received: by zhard00e.europe.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 30 Nov 2000 15:29:02 -0000 Message-ID: <3353DE9BA890D4118DDB0020484008840F7BFA@zhard00n.europe.nortel.com> From: "Elwyn Davies" To: "'Jun-ichiro itojun Hagino'" , Metzler Jochen Cc: "'ipng@sunroof.eng.sun.com'" Subject: RE: AW: AW: Usage of IPv6 flow label Date: Thu, 30 Nov 2000 15:28:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05AE2.3E9EB0F0" 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_01C05AE2.3E9EB0F0 Content-Type: text/plain Itojun's example would be covered by DiffServ, and I would argue that it would not be a good idea to duplicate the DSCP functionality by using the flowlabel. In the example, I would really want the whole flow to follow the same path (and hence expect it to be kept in order) whereas giving different flowlables to the sub-streams would positively encourage routers to put them on different streams. I suspect that for most cases the extra effort of marking the sub-streams through flow labels might well be left to the kernel by using multiple sockets - why invent a new means of multiplexing when TCP/IP provides a ready made one? Regards, Elwyn > -----Original Message----- > From: Jun-ichiro itojun Hagino [SMTP:itojun@iijlab.net] > Sent: Thursday, November 30, 2000 12:19 PM > To: Metzler Jochen > Cc: 'ipng@sunroof.eng.sun.com' > Subject: Re: AW: AW: Usage of IPv6 flow label > > > >I am not a kernel specialist, but I assume that from > >a performance point of view it would be much more performant > >to have several flows using only one socket instead of > >having a single socket for each flow? > > I believe there's no performance issue here. what kind of > performace drawback do you have in mind? > > I can imagine a use of multiple flow label values for single TCP/UDP > session, if: > - a single TCP session includes traffic with different > characteristics, > for example, MPEG key frames (full picture) and intermediate data > (differences between Nth full picture to (N+1)th full picture) > - the application would like to enforce different RSVP > characteristics > to key frames and intermediate data. > - so, application would like to label packets with key frames with > flow > label X, and intermediate data with flow label Y. packets with > flow > label X will have a higher priority than those with flow label Y. > i'm not sure if the above example makes sense or not. > even if the example is okay, there's absolutely no kernel > performance > issue here. the reason why we use two flow label values (X and Y) > is from the applicatoin needs, not from kernel performance issues. > > >An other concern is the redundancy of information in > >ports and labels. > > as i noted in previous messages, the purpose of flow label value is > to provide quick lookup of L4 port pair and protocol type. so > I would say that the redundancy is expected. the redundancy is > what we really want - intermediate routers do not want to chase > extension headers to find L4 header. > > 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 > -------------------------------------------------------------------- ------_=_NextPart_001_01C05AE2.3E9EB0F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: AW: AW: Usage of IPv6 flow label

Itojun's example = would be covered by DiffServ, and I would argue that it would not be a = good idea to duplicate the DSCP functionality by using the = flowlabel.  In the example, I would really want the whole flow to = follow the same path (and hence expect it to be kept in order) whereas = giving different flowlables to the sub-streams would positively = encourage routers to put them on different streams.  I suspect = that for most cases the extra effort of marking the sub-streams through = flow labels might well be left to the kernel by using multiple sockets = - why invent a new means of multiplexing when TCP/IP provides a ready = made one?

Regards,
Elwyn

    -----Original Message-----
    From:   Jun-ichiro itojun Hagino = [SMTP:itojun@iijlab.net]
    Sent:   Thursday, November 30, 2000 12:19 PM
    To:     Metzler Jochen
    Cc:     'ipng@sunroof.eng.sun.com'
    Subject:       = Re: AW: AW: Usage of IPv6 flow = label


    >I am not a kernel specialist, but = I assume that from
    >a performance point of view it = would be much more performant
    >to have several flows using only = one socket instead of
    >having a single socket for each = flow?

            I believe there's no performance issue here.  what = kind of
            performace drawback do you have in mind?

            I can imagine a use of multiple flow label values for = single TCP/UDP
            session, if:
            - a single TCP session includes traffic with different = characteristics,
              for example, MPEG key frames (full picture) and = intermediate data
              (differences between Nth full picture to (N+1)th = full picture)
            - the application would like to enforce different RSVP = characteristics
              to key frames and intermediate data.
            - so, application would like to label packets with key = frames with flow
              label X, and intermediate data with flow label = Y.  packets with flow
              label X will have a higher priority than those = with flow label Y.
            i'm not sure if the above example makes sense or = not.
            even if the example is okay, there's absolutely no = kernel performance
            issue here.  the reason why we use two flow label = values (X and Y)
            is from the applicatoin needs, not from kernel = performance issues.

    >An other concern is the redundancy = of information in
    >ports and labels.

            as i noted in previous messages, the purpose of flow = label value is
            to provide quick lookup of L4 port pair and protocol = type.  so
            I would say that the redundancy is expected.  the = redundancy is
            what we really want - intermediate routers do not want = to chase
            extension headers to find L4 header.

    itojun
    ---------------------------------------------------------= -----------
    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_01C05AE2.3E9EB0F0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 30 07:38:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAUFbox01451 for ipng-dist; Thu, 30 Nov 2000 07:37:50 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAUFbdr01444 for ; Thu, 30 Nov 2000 07:37:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA14988 for ; Thu, 30 Nov 2000 07:37:40 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29864 for ; Thu, 30 Nov 2000 07:37:35 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id AAA26715; Fri, 1 Dec 2000 00:33:58 +0900 (JST) To: "Elwyn Davies" cc: Metzler Jochen , "'ipng@sunroof.eng.sun.com'" In-reply-to: elwynd's message of Thu, 30 Nov 2000 15:28:52 GMT. <3353DE9BA890D4118DDB0020484008840F7BFA@zhard00n.europe.nortel.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: AW: AW: Usage of IPv6 flow label From: itojun@iijlab.net Date: Fri, 01 Dec 2000 00:33:58 +0900 Message-ID: <26713.975598438@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Itojun's example would be covered by DiffServ, and I would argue that it >would not be a good idea to duplicate the DSCP functionality by using the >flowlabel. I'm not trying to talk about diffserv. 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 Nov 30 08:14:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAUGCZJ01499 for ipng-dist; Thu, 30 Nov 2000 08:12:35 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAUGCPr01492 for ; Thu, 30 Nov 2000 08:12:26 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA22353 for ; Thu, 30 Nov 2000 08:12:25 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15197 for ; Thu, 30 Nov 2000 08:12:24 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id IAA00218; Thu, 30 Nov 2000 08:04:39 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA10264; Thu, 30 Nov 2000 08:04:39 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14886.31382.980387.942374@thomasm-u1.cisco.com> Date: Thu, 30 Nov 2000 08:04:38 -0800 (PST) To: "Elwyn Davies" Cc: "'Jun-ichiro itojun Hagino'" , Metzler Jochen , "'ipng@sunroof.eng.sun.com'" Subject: RE: AW: AW: Usage of IPv6 flow label In-Reply-To: <3353DE9BA890D4118DDB0020484008840F7BFA@zhard00n.europe.nortel.com> References: <3353DE9BA890D4118DDB0020484008840F7BFA@zhard00n.europe.nortel.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Elwyn Davies writes: > Itojun's example would be covered by DiffServ, and I would argue that it > would not be a good idea to duplicate the DSCP functionality by using the > flowlabel. In the example, I would really want the whole flow to follow the > same path (and hence expect it to be kept in order) whereas giving different > flowlables to the sub-streams would positively encourage routers to put them > on different streams. I'm not sure I buy this. While taking different routes wouldn't help TCP especially, SCTP and UDP applications do not suffer from head of line blocking, and therefore this may not be an issue. I think there's a larger issue here: DSCP gives a means of marking a traffic aggregate into a small set of PHB's and thus relieve interior routers of the need to keep uFlow state. This is general goodness. However, there are still uses for uFlows that the Intserv model provides, and when you throw RSVP aggregation into the mix along with the ability to signal for diffserv flows (RFC 2997, I think), I think you get a pretty flexible mix to deploy qos enabled networks. So the real question to my mind is not whether the flowlabel might be gratuitously supplanting the DSCP. I can see no reason for this, and would not support it. However, what _does_ seem to be interesting -- which is how I read Itojun's article -- is whether it would be useful to have an _alternate_ means of flow classification for uFlows than the normal 5-tuple. One of the benfits is that a host could decide which traffic to bind together as a flow for a particular tspec, rather than be rigidly bound to the 5-tuple and needing to set up separate reservations if you have two or more flows which don't match that classifier. This seems like an interesting possibility to me. From a resource standpoint, the only thing the routers care about is the tspec. How a particular host divvies up the bits policed to that tspec is not especially interesting to the router assuming that the router doesn't have to do too much work to do complex classification... which is something that the flowlabel promises to be much better on. Mike I suspect that for most cases the extra effort of > marking the sub-streams through flow labels might well be left to the kernel > by using multiple sockets - why invent a new means of multiplexing when > TCP/IP provides a ready made one? > > Regards, > Elwyn > > > -----Original Message----- > > From: Jun-ichiro itojun Hagino [SMTP:itojun@iijlab.net] > > Sent: Thursday, November 30, 2000 12:19 PM > > To: Metzler Jochen > > Cc: 'ipng@sunroof.eng.sun.com' > > Subject: Re: AW: AW: Usage of IPv6 flow label > > > > > > >I am not a kernel specialist, but I assume that from > > >a performance point of view it would be much more performant > > >to have several flows using only one socket instead of > > >having a single socket for each flow? > > > > I believe there's no performance issue here. what kind of > > performace drawback do you have in mind? > > > > I can imagine a use of multiple flow label values for single TCP/UDP > > session, if: > > - a single TCP session includes traffic with different > > characteristics, > > for example, MPEG key frames (full picture) and intermediate data > > (differences between Nth full picture to (N+1)th full picture) > > - the application would like to enforce different RSVP > > characteristics > > to key frames and intermediate data. > > - so, application would like to label packets with key frames with > > flow > > label X, and intermediate data with flow label Y. packets with > > flow > > label X will have a higher priority than those with flow label Y. > > i'm not sure if the above example makes sense or not. > > even if the example is okay, there's absolutely no kernel > > performance > > issue here. the reason why we use two flow label values (X and Y) > > is from the applicatoin needs, not from kernel performance issues. > > > > >An other concern is the redundancy of information in > > >ports and labels. > > > > as i noted in previous messages, the purpose of flow label value is > > to provide quick lookup of L4 port pair and protocol type. so > > I would say that the redundancy is expected. the redundancy is > > what we really want - intermediate routers do not want to chase > > extension headers to find L4 header. > > > > 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 > > -------------------------------------------------------------------- > > > > > > RE: AW: AW: Usage of IPv6 flow label > > > >

Itojun's example would be covered by DiffServ, and I would argue that it would not be a good idea to duplicate the DSCP functionality by using the flowlabel.  In the example, I would really want the whole flow to follow the same path (and hence expect it to be kept in order) whereas giving different flowlables to the sub-streams would positively encourage routers to put them on different streams.  I suspect that for most cases the extra effort of marking the sub-streams through flow labels might well be left to the kernel by using multiple sockets - why invent a new means of multiplexing when TCP/IP provides a ready made one?

> >

Regards, >
Elwyn >

>
    >

    -----Original Message----- >
    From:   Jun-ichiro itojun Hagino [SMTP:itojun@iijlab.net] >
    Sent:   Thursday, November 30, 2000 12:19 PM >
    To:     Metzler Jochen >
    Cc:     'ipng@sunroof.eng.sun.com' >
    Subject:        Re: AW: AW: Usage of IPv6 flow label >

    >
    > >

    >I am not a kernel specialist, but I assume that from >
    >a performance point of view it would be much more performant >
    >to have several flows using only one socket instead of >
    >having a single socket for each flow? >

    > >

            I believe there's no performance issue here.  what kind of >
            performace drawback do you have in mind? >

    > >

            I can imagine a use of multiple flow label values for single TCP/UDP >
            session, if: >
            - a single TCP session includes traffic with different characteristics, >
              for example, MPEG key frames (full picture) and intermediate data >
              (differences between Nth full picture to (N+1)th full picture) >
            - the application would like to enforce different RSVP characteristics >
              to key frames and intermediate data. >
            - so, application would like to label packets with key frames with flow >
              label X, and intermediate data with flow label Y.  packets with flow >
              label X will have a higher priority than those with flow label Y. >
            i'm not sure if the above example makes sense or not. >
            even if the example is okay, there's absolutely no kernel performance >
            issue here.  the reason why we use two flow label values (X and Y) >
            is from the applicatoin needs, not from kernel performance issues. >

    > >

    >An other concern is the redundancy of information in >
    >ports and labels. >

    > >

            as i noted in previous messages, the purpose of flow label value is >
            to provide quick lookup of L4 port pair and protocol type.  so >
            I would say that the redundancy is expected.  the redundancy is >
            what we really want - intermediate routers do not want to chase >
            extension headers to find L4 header. >

    > >

    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 Thu Nov 30 09:01:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAUGxnU01608 for ipng-dist; Thu, 30 Nov 2000 08:59:49 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAUGxer01601 for ; Thu, 30 Nov 2000 08:59:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA15407 for ; Thu, 30 Nov 2000 08:59:40 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07991 for ; Thu, 30 Nov 2000 08:59:40 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA25910; Thu, 30 Nov 2000 09:00:49 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA35638; Thu, 30 Nov 2000 08:59:37 -0800 Message-ID: <3A2686FA.E7441E7B@hursley.ibm.com> Date: Thu, 30 Nov 2000 10:57:30 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: itojun@iijlab.net CC: "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label References: <26713.975598438@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun, > I'm not trying to talk about diffserv. I think we need a solution that works for diffserv with ESP. A solution that only helps IntServ is insufficient. (DiffServ without ESP doesn't need the flow label as far as I can see). So I would actually like something along the lines of Alex's proposal, but with some differences: - lose the "IANA assigned" option; replace it by pseudo-random numbers as originally defined. Your draft and Jochen's fit right in with this. - figure out a way to make the other option in Alex's draft: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Server Port Number| H-to-H protocol| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ suitable for use by policy-driven diffserv classifiers. Brian itojun@iijlab.net wrote: > > >Itojun's example would be covered by DiffServ, and I would argue that it > >would not be a good idea to duplicate the DSCP functionality by using the > >flowlabel. > > I'm not trying to talk about diffserv. > > 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 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.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 Thu Nov 30 09:06:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAUH4v801634 for ipng-dist; Thu, 30 Nov 2000 09:04:57 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAUH4mr01627 for ; Thu, 30 Nov 2000 09:04:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA25579 for ; Thu, 30 Nov 2000 09:04:48 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22594 for ; Thu, 30 Nov 2000 10:04:46 -0700 (MST) Received: from ValuedSonyCustomer (as1b-234.chi.il.dial.anet.com [198.92.157.234]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id KAA23556 for ; Thu, 30 Nov 2000 10:57:27 -0600 (CST) Message-ID: <029701c05aee$d94d1e00$df00a8c0@ValuedSonyCustomer> From: "JIM FLEMING" To: Subject: Fw: "Causing a collision anywhere on the Internet is ethically wrong," Gallegos says Date: Thu, 30 Nov 2000 10:59:01 -0600 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: JIM FLEMING To: Judith Oppenheimer ; Sent: Thursday, November 30, 2000 10:29 AM Subject: Re: "Causing a collision anywhere on the Internet is ethically wrong," Gallegos says > IPv8 and IPv16 "addressing" are supported in Windows 2000. > > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp > > IPv6 - [ ICANN Assigned Prefix ] [ User's Address (Ethernet, Phone#) ] > > IPv8 - [ 2002: ] [ IPv8 Address (64 bits) ] > > IPv16 - [ 2002: ] [ IPv16 Address (64 bits) ] > > > Jim Fleming > http://www.unir.com > Mars 128n 128e > > > ----- Original Message ----- > From: Judith Oppenheimer > To: 'JIM FLEMING' ; > Sent: Thursday, November 30, 2000 10:27 AM > Subject: RE: "Causing a collision anywhere on the Internet is ethically > wrong," Gallegos says > > > > Jim, your question can only be considered, from a technical standpoint, > > *if* the IPv8 standard is adopted. > > > > But in IPv4, where we are now, it simply doesn't apply, and IMHO I don't > > think its fair to castigate TLD operators with whom your business could > > potentially compete, based on a technical "if." Its a misrepresentation > of > > the facts, and that's not fair to Domain-Policy readers, or the TLD > > operators you attack. I don't think it does anything to further your > > cause, either. > > > > Have you any indication, if and when IPv8 might be adopted? > > > > Judith > > > > P.S. (a) Thanks for the plug and (b) I hope you don't flame me. We've > > spoken at length; I like you, and your genius is confirmed by many people > I > > respect. But looking at the standard, I can't find anything about if and > > when IPv8 might be adopted. Hence my comment and my question. > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > Publisher, http://www.ICBTollFreeNews.com > > President, http://www.1800TheExpert.com > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > -----Original Message----- > > > From: Owner-Domain-Policy > > > [mailto:owner-domain-policy@LISTS.NETSOL.COM]On Behalf Of JIM FLEMING > > > Sent: Thursday, November 30, 2000 9:15 AM > > > To: DOMAIN-POLICY@LISTS.NETSOL.COM > > > Subject: "Causing a collision anywhere on the Internet is ethically > > > wrong," Gallegos says > > > > > > > > > http://www.icbtollfreenews.com/ > > > > > > "Causing a collision anywhere on the Internet is ethically > > > wrong," Gallegos > > > says" > > > > > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > > > > > > Does this mean that people will not be allowed to "collide" > > > with the 37,000+ > > > ONLINE name owners when entered into the ONLINE TLD servers ? > > > > > > Is that the "policy" of www.ONLINE-REGISTRY.com ? > > > > > > ...or, does ONLINE-REGISTRY.com encourage people to collide with the > > > existing ONLINE name owners ? > > > > > > > 37187 ONLINE > > > > 15755 INC > > > > 14787 NET > > > > 11783 USA > > > > 9455 E > > > > 9432 UK > > > > 8657 WEB > > > > 8406 GROUP > > > > 7498 IT > > > > 7175 DESIGN > > > > 6935 SHOP > > > > 6268 TECH > > > > 6260 WORLD > > > > 6017 SOLUTIONS > > > > 5726 US > > > > 5617 SERVICES > > > > 5607 LINE > > > > 5331 TV > > > > 5212 CONSULTING > > > > 5188 1 > > > > 5003 INTERNATIONAL > > > > > > > > > Jim Fleming > > > http://www.unir.com > > > Mars 128n 128e > > > http://www.unir.com/images/architech.gif > > > http://www.unir.com/images/address.gif > > > http://www.unir.com/images/headers.gif > > > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > > > http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp > > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 30 09:17:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAUHEZ401703 for ipng-dist; Thu, 30 Nov 2000 09:14:35 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAUHEQr01696 for ; Thu, 30 Nov 2000 09:14:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA28766 for ; Thu, 30 Nov 2000 09:14:26 -0800 (PST) Received: from smtp1.gtsgroup.com (smtp1.gtsgroup.com [195.158.230.16]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA15364 for ; Thu, 30 Nov 2000 09:14:23 -0800 (PST) Received: by brubhdpnt01.gtsgroup.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 18:14:21 +0100 Message-ID: <8DD51DE55B05D411907400508B6DC44DE53B54@brumsgpnt02.gtsgroup.com> From: "Valk, Geert" To: "'ipng@sunroof.eng.sun.com'" Subject: Looking for papers / thesis Date: Thu, 30 Nov 2000 18:14:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All, My name is Geert Valk and I'm a student in the Netherlands. Looking for papers of thesis on the subject IPv6, more specifically on subjects as 'the commercial impact', 'impact on processes within a company', 'Impact on networks when migrating to IPv6'. (not somuch technical papers) If anyone can help me with that, please respond. Kind regards, Geert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 30 12:02:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAUK10202004 for ipng-dist; Thu, 30 Nov 2000 12:01:00 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAUK0pr01997 for ; Thu, 30 Nov 2000 12:00:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA09902 for ; Thu, 30 Nov 2000 12:00:50 -0800 (PST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17047 for ; Thu, 30 Nov 2000 12:00:48 -0800 (PST) Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 2DED4240ACD4; Thu, 30 Nov 2000 21:00:44 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id VAA05522; Thu, 30 Nov 2000 21:00:43 +0100 (MET) To: itojun@iijlab.net Cc: Metzler Jochen , "'Elwyn Davies'" , "'ipng@sunroof.eng.sun.com'" Subject: Re: AW: Usage of IPv6 flow label References: <23233.975580405@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 30 Nov 2000 21:00:43 +0100 In-Reply-To: itojun@iijlab.net's message of "Thu, 30 Nov 2000 19:33:25 +0900" Message-ID: Lines: 41 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net writes: > I admit there could be people who wants to use: > - multiple flows (= multiple flow label value) in a single TCP session That doesn't make much sense to me. A TCP connection is by definition a single flow (or two, if you count directions). Hmm. Or more precisely, it doesn't make sense to switch back and forth between several flow-labels on the same tcp connection, but it might make sense to switch to a _new_ flow-label. Then one views the connection as a sequence of different flows, but *not* as several flows that are in some way parallell or independent. > - multiple TCP sessions with single flow label value That makes sense, even if I have no idea if it is actually useful. > however, I could not find a good (a simple and usable) UNIX API to make > the above option happen, so I simplified the story. > At least, the latter case can easily be handled by "single TCP session > per single flow label". What about associating a flow-label with each open socket (which is used for all outgoing packets), and supporting these three operations: 1. Make up a new, unique, flow-label and associate it with the given socket. 2. Copy the flow-label association from one socket to another. 3. Reset the flow-label for a socket to zero. I think you could do each of those as a ioctl or setsockopt or something. This way, applications never see the actual flow-label values, and the network code always knows which flow-labels are in use and which are dead. /Niels -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 30 12:23:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAUKMHA02135 for ipng-dist; Thu, 30 Nov 2000 12:22:17 -0800 (PST) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAUKM8r02128 for ; Thu, 30 Nov 2000 12:22:09 -0800 (PST) Received: from hogwart.Central.Sun.COM (hogwart.Central.Sun.COM [129.152.60.185]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA07161; Thu, 30 Nov 2000 13:22:07 -0700 (MST) Received: (from davemq@localhost) by hogwart.Central.Sun.COM (8.11.1+Sun/8.11.1) id eAUKLqf07848; Thu, 30 Nov 2000 14:21:52 -0600 (CST) Date: Thu, 30 Nov 2000 14:21:52 -0600 From: Dave Marquardt To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: itojun@iijlab.net, Metzler Jochen , "'Elwyn Davies'" , "'ipng@sunroof.eng.sun.com'" Subject: Re: AW: Usage of IPv6 flow label Message-ID: <20001130142152.A7406@hogwart> References: <23233.975580405@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from nisse@lysator.liu.se on Thu, Nov 30, 2000 at 09:00:43PM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Nov 30, 2000 at 09:00:43PM +0100, Niels Möller wrote: > > however, I could not find a good (a simple and usable) UNIX API to make > > the above option happen, so I simplified the story. > > At least, the latter case can easily be handled by "single TCP session > > per single flow label". > > What about associating a flow-label with each open socket (which is > used for all outgoing packets), and supporting these three operations: > > 1. Make up a new, unique, flow-label and associate it with the given > socket. > > 2. Copy the flow-label association from one socket to another. > > 3. Reset the flow-label for a socket to zero. I can think of a couple of others: 4. Retrieve the flow label from a socket. 5. Set the flow label on a socket to a specific value. These together should allow UDP servers to associate flow labels with particular traffic. When such an application wanted to create a new flow F, it would use 1 and 4. When it sent packets to another existing flow G, it could use 5. When the application resumed sending packets to flow F, it would again use 5. -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 Nov 30 12:53:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eAUKheB02170 for ipng-dist; Thu, 30 Nov 2000 12:43:40 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eAUKhQr02163 for ; Thu, 30 Nov 2000 12:43:26 -0800 (PST) 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,v1.7) with ESMTP id MAA20434 for ; Thu, 30 Nov 2000 12:43:24 -0800 (PST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA25393 for ; Thu, 30 Nov 2000 13:43:22 -0700 (MST) Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 2B00F240ACC6; Thu, 30 Nov 2000 21:43:19 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id VAA20138; Thu, 30 Nov 2000 21:43:18 +0100 (MET) To: Dave Marquardt Cc: itojun@iijlab.net, Metzler Jochen , "'Elwyn Davies'" , "'ipng@sunroof.eng.sun.com'" Subject: Re: AW: Usage of IPv6 flow label References: <23233.975580405@coconut.itojun.org> <20001130142152.A7406@hogwart> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 30 Nov 2000 21:43:18 +0100 In-Reply-To: Dave Marquardt's message of "Thu, 30 Nov 2000 14:21:52 -0600" Message-ID: Lines: 44 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave Marquardt writes: > > What about associating a flow-label with each open socket (which is > > used for all outgoing packets), and supporting these three operations: > > > > 1. Make up a new, unique, flow-label and associate it with the given > > socket. > > > > 2. Copy the flow-label association from one socket to another. > > > > 3. Reset the flow-label for a socket to zero. > > I can think of a couple of others: > > 4. Retrieve the flow label from a socket. > > 5. Set the flow label on a socket to a specific value. The problem with (5), I think, is that it makes it really difficult for the networking code to know when a flow-label is no longer used, so that it can be reused safely during (1) processing. > These together should allow UDP servers to associate flow labels with > particular traffic. You *can* do the same thing with only 1-3. Whenever you want to copy a flow-label and use it later, you create a new socket, use (2) to save the flow-label you are interested in, and you can use (2) to restore it again later. If you allow (5), if I can somehow discover the flow-labels used by other users' processes (by magic or by passive sniffing of some intermediate cable or something), then I can use (5) to assign the same flow-label to my own sockets and cause trouble by violating any requirements on flow-label use that the other user's processes and friendly routers try to enforce. Is that a problem worth worrying about? Not doing (5) helps the network code to stay in full control of the flow-label allocation; there would be no way to collide with the flow-labels allocated to unrelated processes, neither by mistake or by malice. /Niels -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------