From owner-ipng@sunroof.eng.sun.com Tue Jun 2 20:50:47 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id UAA24454 for ipng-dist; Tue, 2 Jun 1998 20:48:07 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id UAA24447 for ; Tue, 2 Jun 1998 20:47:58 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA03662 for ; Tue, 2 Jun 1998 20:48:09 -0700 Received: from tokyogw.iij.ad.jp (tokyogw.iij.ad.jp [202.232.15.22]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id UAA26433 for ; Tue, 2 Jun 1998 20:47:58 -0700 (PDT) Received: by tokyogw.iij.ad.jp; id MAA09159; Wed, 3 Jun 1998 12:47:57 +0900 (JST) Received: from mine.iij.ad.jp(192.168.4.209) by tokyogw.iij.ad.jp via smap (4.1) id xma009029; Wed, 3 Jun 98 12:46:58 +0900 Received: from localhost (localhost.iij.ad.jp [127.0.0.1]) by mine.iij.ad.jp (8.8.7/8.8.5) with ESMTP id MAA05166; Wed, 3 Jun 1998 12:59:11 +0900 (JST) To: ipng@sunroof.eng.sun.com, IPV6IMP@munnari.OZ.AU Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Jun__2_00:13:09_1998_601)--" Content-Transfer-Encoding: 7bit Reply-To: IPv6-jp@jp.freebsd.org X-Distribute: distribute [version 2.1 (Alpha) patchlevel=24] X-Sequence: IPv6-jp 109 Subject: (IPng 5867) [IPv6-jp 109] the first release of KAME IPv6/IPsec package From: Kazu Yamamoto (=?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.93b37 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Message-Id: <19980603125911M.kazu@Mew.org> Date: Wed, 03 Jun 1998 12:59:11 +0900 X-Dispatcher: imput version 980522 Lines: 77 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----Next_Part(Tue_Jun__2_00:13:09_1998_601)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit # This message was sent to these MLs with my new address but not # delivered. I try sending this message again with my old address. # Sorry if you receive duplicated messages. Hello IPv6 enthusiasts, "KAME Project" is a joint effort of Fujitsu Limited, Hitachi, Ltd., IIJ Research Laboratory, NEC Corporation, Toshiba Corporation, Yokogawa Digital Computer Corporation, and Yokogawa Electric Corporation to create IPv6/IPsec stacks. It started in April 1998 and will be a two-years project (possibly longer). The stack was originally called "Hydrangea" developed by v6 working group of WIDE Project. KAME project members are almost the same as the working group member, but we have chosen this project name along with stack name to emphasize the goal of this effort is different. We're now merging protocol stacks individually developed by each companies, into KAME which is based on Hydrangea. Currently, we target FreeBSD and BSD/OS but will probably adapt NetBSD, too. Like other BSD variants, this package is distributed the BSD "AS IS" style copyright. In short, FREE of charge but with NO warranty. You can use released packages for academic, research, and/or commercial purposes. We release a stable package every other month. This is the first stable release of KAME Project. "kame-980531-{fbsd226,bsdi300}-stable.tgz" contains IPv6 basic features, a lot of IPv6 applications(including TELNET, FTP, RLOGIN, SSH, Netscape), IPv6 routing daemons, IPv6 over p2p ATM, transport mode of IPsec, key exchange daemons, IPv4-IPv6 translator, DNS server which supports both IPv4 and IPv6, etc. Note: Cryptographic softwares are NOT under export control in Japan if distributed without any charge. But please note that your country may have import and/or use control for cryptographic softwares. Before you retrieve this package, please check your country's export/import policies before you retrieve package. If you are interested, please find a download page in following URL: http://www.kame.net For those who prefer FTP, we also enclose FTP external-body in MIME format. // KAME Project ----Next_Part(Tue_Jun__2_00:13:09_1998_601)-- Content-Type: Message/External-Body; access-type="anon-ftp"; name="kame-980531-fbsd226-stable.tgz"; directory="/pub/kame/stable/"; site="ftp.kame.net" Content-Transfer-Encoding: 7bit Content-Type: Application/Octet-Stream Content-ID: <13682.50433.595@kame200.kame.net> ----Next_Part(Tue_Jun__2_00:13:09_1998_601)-- Content-Type: Message/External-Body; access-type="anon-ftp"; name="kame-980531-bsdi300-stable.tgz"; directory="/pub/kame/stable/"; site="ftp.kame.net" Content-Transfer-Encoding: 7bit Content-Type: Application/Octet-Stream Content-ID: <13682.50433.600@kame200.kame.net> ----Next_Part(Tue_Jun__2_00:13:09_1998_601)---- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 3 10:26:28 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id KAA25071 for ipng-dist; Wed, 3 Jun 1998 10:22:46 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id KAA25064 for ; Wed, 3 Jun 1998 10:22:37 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA22503 for ; Wed, 3 Jun 1998 10:22:46 -0700 Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA25337 for ; Wed, 3 Jun 1998 10:22:35 -0700 (PDT) Received: from localhost (msb@localhost) by iol.unh.edu (8.8.8/8.8.8) with SMTP id NAA06388; Wed, 3 Jun 1998 13:21:45 -0400 (EDT) Date: Wed, 3 Jun 1998 13:21:44 -0400 (EDT) From: Michael S Briggs To: ipng@sunroof.eng.sun.com cc: ipv6members@iol.unh.edu Subject: (IPng 5868) Router testing at the UNH IPv6 Test Period In-Reply-To: <01bd88d4$ffee6620$4c11e8c3@creak.ticl.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, As some of you already know, the UNH InterOperability Lab will be having a test period August 17-21 (see the notification included below). As we are in the process of developing our test agenda, we would like to know how many of the vendors who will be attending will have a router implementation running RIPng, BGP MP, and/or OSPFv6 at that time. So, if you will be attending the Test Period, and will be bringing a v6 router implementation, please let us know which routing protocols (if any) you expect to be running (or attempting to run) at that time. I would appreciate it if you would contact me or Ray LaRocca (rglr@iol.unh.edu) with the above information. Thanks, Mike Briggs ------------------------------------------------------------ Michael Briggs UNH InterOperability Lab msb@iol.unh.edu IP/Routing Consortium ------------------------------------------------------------ ***************** NOTICE ***************************** The IP group at UNH will be holding its 7th. IPv6 test period on the campus of UNH at the Leavitt Center facility August 17 - 21 , 1998. The cost is FREE for IP consortium IPv6 members bringing only two participants ($100/participant after two) and $ 1250.00 per company for non-members. Please register early so we can plan the space allocation. There will be registration forms provided on the web www.iol.unh.edu at a later time. You may call Ray @603-862-0090 or myself @ 603-862-4492 if have questions. Also check the web for the te sting schedule. At the last event we tested RIPng and BGP4+ ! We look forward to seeing you there. William Lenharth -- IP group manager ******************************************************* -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 3 20:45:18 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id UAA25793 for ipng-dist; Wed, 3 Jun 1998 20:42:44 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id UAA25786 for ; Wed, 3 Jun 1998 20:42:33 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA01519 for ; Wed, 3 Jun 1998 20:42:43 -0700 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id UAA08532 for ; Wed, 3 Jun 1998 20:42:14 -0700 (PDT) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.8+3.0Wbeta12/3.6W) with ESMTP id MAA01746; Thu, 4 Jun 1998 12:39:48 +0900 (JST) To: bound@zk3.dec.com cc: ipng@sunroof.eng.sun.com In-reply-to: bound's message of Wed, 20 May 1998 11:45:26 -0400. <199805201545.AA01661@wasted.zk3.dec.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: (IPng 5869) Re: Take Two: API sockaddr_in6 Update Discussion Date: Thu, 04 Jun 1998 12:39:48 +0900 Message-ID: <1742.896931588@coconut.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Our project is trying to find out what are necessary/need to be considered with sin6_ifindex, so we already included sin6_ifindex into our sockaddr_in6 structure (visit http://www.kame.net for implementation). And I already got a question:-) What is endian-ness requirement for sin6_ifindex and sin6_scope_id? It has to be in host, or net order? Thanks. jun-ichiro itojun itoh itojun@kame.net itojun@iijlab.net -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 4 10:27:24 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id KAA26565 for ipng-dist; Thu, 4 Jun 1998 10:23:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id KAA26558 for ; Thu, 4 Jun 1998 10:23:28 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA13554 for ; Thu, 4 Jun 1998 10:23:36 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA29166 for ; Thu, 4 Jun 1998 10:23:26 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.7/8.6.10) with SMTP id KAA07671; Thu, 4 Jun 1998 10:23:19 -0700 (PDT) Message-Id: <3.0.5.32.19980604102232.009328d0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 04 Jun 1998 10:22:32 -0700 To: Thomas Narten , burgan@home.net From: Bob Hinden Subject: (IPng 5870) ND / Stateless Address Autoconfig Implementations Reports Cc: ipng@sunroof.eng.sun.com, scoya@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff, Thomas, I am pleased to report there are now 10 implementation reports for Neighbor Discovery for IP Version 6 (IPv6) and IPv6 Stateless Address Autoconfiguration documented at ftp://playground.sun.com/pub/ipng/implementation-reports . This include implementations from: Fujitsu Limited SGI Phase2 Networks Mentat Inc. SICS Bay Networks HP Hitachi, Ltd. KAME Project Sun Microsystems 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 Thu Jun 4 23:46:43 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id XAA27777 for ipng-dist; Thu, 4 Jun 1998 23:43:15 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id XAA27770 for ; Thu, 4 Jun 1998 23:43:04 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA03698 for ; Thu, 4 Jun 1998 23:43:15 -0700 Received: from tokyogw.iij.ad.jp (tokyogw.iij.ad.jp [202.232.15.22]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id XAA11711 for ; Thu, 4 Jun 1998 23:43:00 -0700 (PDT) Received: by tokyogw.iij.ad.jp; id PAA12862; Fri, 5 Jun 1998 15:43:00 +0900 (JST) Received: from mine.iij.ad.jp(192.168.4.209) by tokyogw.iij.ad.jp via smap (4.1) id xma012804; Fri, 5 Jun 98 15:42:41 +0900 Received: from localhost (localhost.iij.ad.jp [127.0.0.1]) by mine.iij.ad.jp (8.8.7/8.8.5) with ESMTP id PAA08521 for ; Fri, 5 Jun 1998 15:55:39 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 5871) Netscape6 From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.93b37 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980605155538N.kazu@Mew.org> Date: Fri, 05 Jun 1998 15:55:38 +0900 X-Dispatcher: imput version 980522 Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As I announced, Netscape for IPv6 is available from http://www.kame.net/. We have not checked whether this Netscape stably runs other platforms. But it runs, at least, on the KAME kernel. The original Netscape (more exactly Mozilla) is designed to get along with IPv6. Actually, our modifications are very SMALL. One member of KAME Project talked with a Netscape gal. She said that feedback corresponding to IPv6 was really welcome. So, we will send our patches to Netscape for inclusion. Some modifications are still necessary. For instance, indication of URL by address notation, FTP, etc. But it is not so difficult, we believe. Many other applications are already IPv6-ready. So, it's high time to start IPv6-only life. :) --Kazu, KAME Project/WIDE 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 Wed Jun 10 14:49:07 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id OAA03664 for ipng-dist; Wed, 10 Jun 1998 14:44:38 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id OAA03657 for ; Wed, 10 Jun 1998 14:44:27 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA22513 for ; Wed, 10 Jun 1998 14:44:37 -0700 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA00854 for ; Wed, 10 Jun 1998 14:44:24 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id XAA11545; Wed, 10 Jun 1998 23:44:16 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id XAA08645; Wed, 10 Jun 1998 23:44:15 +0200 (MET DST) Message-Id: <199806102144.XAA08645@givry.inria.fr> From: Francis Dupont To: bound@zk3.dec.com cc: ipng@sunroof.eng.sun.com Subject: (IPng 5878) Re: Take Two: API sockaddr_in6 Update Discussion In-reply-to: Your message of Wed, 13 May 1998 15:44:51 EDT. <199805131944.AA25865@wasted.zk3.dec.com> Date: Wed, 10 Jun 1998 23:44:13 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I believe we need to resume the discussion... Perhaps this should be on the implementor mailing-list but the API has not only to be implemented in the kernel but it has to be used! First the whole stuff is related to the so called weak and strong models for multihomed nodes (cf RFC 1122 section 3.3.4.2): - with strong model we have to give the outgoing interface - with weak model the outgoing interface is discovered by the OS. In the whole discussion unicast and anycast addresses are indiscernible then unicast will stand for both. I believe there are two problems, scopes and interfaces (then the proposal has both a scope_id and an ifindex). Both depends of the type of address : - unicast global addresses don't need a scope_id nor an ifindex. Even we can provide a route table per interface I am *strongly against* this idea because it is a major change for users, for instance I shouldn't like to add an interface name/index parameter to ftp, telnet, ... The forwarding of packets (where there is no outgoing interface provided) is more complicated too. The last argument is obvious, IPv4 nodes use in general the weak model today. - multicast addresses are very different, with the standard IPv4 API for multicast if you don't provide the outgoing interface the OS pickup one with a strange default rule then it is a good idea to force users to provide it. The scope doesn't matter (if it is more than node-local :-) even for site-local multicasts if you have no multisited interfaces (reasonable assumption). - unicast site-local addresses are a special case because they are an issue only for multisited nodes: * without multisited nodes there are like global addresses * on a multisited nodes without multisited interfaces you have to provide a way to make sites unambiguous, obviously a scope_id is necessary here. But the extra parameter for all the applications argument still applies (for routers intersite routing is forbidden), then I believe multisited nodes should be made impossible by the (not yet available) definition of a site... Remarks you need to know only the site, not the outgoing interface itself (which must belong to the site of course). * on multisited nodes with multisited interfaces you're dead! - the last case is unicast link-local addresses which are *ambiguous* without the outgoing interface. Today some programs *need* in6_pktinfo stuff then it is not possible to remove all ways to provide the outgoing interface. But if link-local addresses are used only when there are needed, ie: * on a "site" with only one link like the dentist office * by neighbor discovery and management applications (like ping) then it is possible to make the provision of the outgoing interface mandatory (aka strong model) without an extra harm for users. In first conclusion scope_id can be needed for site-local unicast addresses and ifindex is needed for link-local addresses then we can have one field with both semantics or two fields, scope_id ignored for addresses not in fec0::/48 and ifindex ignored for addresses not in fe80::/64 or ff00::/8. In fact if you'd like to put one 32 bit field near the beginning of the sockaddr_in6 structure and keep 64 bit alignment (not as in DHCPv6 or multicast IPv6 over ATM :-) then we need a second 32 bit field and hop limit is a good candidate (limited scope addresses should come with a hop limit). They are two other issues: - do we need default values or rules ? For a multisited node I don't understand what should be the default site (but I don't understand the whole multisited stuff :-). For link-local unicast a default interface has a meaning in many cases then I'll buy it as an option. - own link-local addresses are a special case, they can belong to the loopback interface (a very "logical" interface) or/and to their interfaces. It is an implementation problem but even with IPv4 you can get strange results... (for instance on Ciscos for point-to-point interfaces a ping on an own link-local address does a remote loop which is both a good and bad idea according to what you'd like to do and what you expect to get :-). Regards Francis.Dupont@inria.fr PS: "Take Two" proposed a major change in the API (ie everything should be modified) then I'd like to *know* if we keep the current API (with in6_pktinfo) or we move to a new world (I am not convinced the change is really needed but I'll change as soon as it becomes the new standard if this happens). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 15 07:23:54 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id HAA04583 for ipng-dist; Mon, 15 Jun 1998 07:16:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id HAA04576 for ; Mon, 15 Jun 1998 07:16:16 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA04942 for ; Mon, 15 Jun 1998 07:16:14 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA23602 for ; Mon, 15 Jun 1998 07:16:15 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA27333; Mon, 15 Jun 1998 10:16:11 -0400 (EDT) Message-Id: <199806151416.KAA27333@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@CNRI.Reston.VA.US; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 5882) I-D ACTION:draft-ietf-ipngwg-tla-assignment-04.txt Date: Mon, 15 Jun 1998 10:16:10 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Proposed TLA and NLA Assignment Rules Author(s) : B. Hinden Filename : draft-ietf-ipngwg-tla-assignment-04.txt Pages : 10 Date : 12-Jun-98 This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as defined in [AGGR]. These proposed rules apply to registries allocating TLA ID's and to organizations receiving TLA ID's. This proposal is intended as input from the IPng working group to the IANA and Registries. It is not intended for any official IETF status. Its content represents the result of extensive discussion between the IPng working group, IANA, and Registries. Internet-Drafts are 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-tla-assignment-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-tla-assignment-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-tla-assignment-04.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: <19980612131017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-tla-assignment-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-tla-assignment-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980612131017.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 Jun 15 11:57:33 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id LAA04869 for ipng-dist; Mon, 15 Jun 1998 11:49:55 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id LAA04862 for ; Mon, 15 Jun 1998 11:49:43 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA26284 for ; Mon, 15 Jun 1998 11:49:41 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA10144 for ; Mon, 15 Jun 1998 11:49:41 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail13.digital.com (8.8.8/8.8.8/WV1.0e) with SMTP id OAA15893; Mon, 15 Jun 1998 14:49:39 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA03748; Mon, 15 Jun 1998 14:49:36 -0400 Message-Id: <199806151849.AA03748@wasted.zk3.dec.com> To: Jun-ichiro itojun Itoh Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5883) Re: Take Two: API sockaddr_in6 Update Discussion In-Reply-To: Your message of "Thu, 04 Jun 1998 12:39:48 +0900." <1742.896931588@coconut.itojun.org> Date: Mon, 15 Jun 1998 14:49:36 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Folks, Sorry for the late response but I had a personal tragedy and had to go offline for a few weeks. Jim, Our project is trying to find out what are necessary/need to be considered with sin6_ifindex, so we already included sin6_ifindex into our sockaddr_in6 structure (visit http://www.kame.net for implementation). OK. Richard and I will be connecting later this week to parse all the input and hope to get a draft out early July. Right now it appears a few folks have put it in their API structure too. Letting us know how that went would be useful, but maybe that should be sent to the implementors list. And I already got a question:-) What is endian-ness requirement for sin6_ifindex and sin6_scope_id? It has to be in host, or net order? Thanks. Host order. These fields are not sent across the wire. thanks and sorry again for the late response, /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 Jun 15 12:08:18 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id MAA04902 for ipng-dist; Mon, 15 Jun 1998 12:00:58 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id MAA04895 for ; Mon, 15 Jun 1998 12:00:50 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA29478 for ; Mon, 15 Jun 1998 12:00:33 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA16287 for ; Mon, 15 Jun 1998 12:00:33 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail13.digital.com (8.8.8/8.8.8/WV1.0e) with SMTP id PAA19396; Mon, 15 Jun 1998 15:00:32 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA04657; Mon, 15 Jun 1998 15:00:29 -0400 Message-Id: <199806151900.AA04657@wasted.zk3.dec.com> To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5884) Re: Take Two: API sockaddr_in6 Update Discussion In-Reply-To: Your message of "Wed, 10 Jun 1998 23:44:13 +0200." <199806102144.XAA08645@givry.inria.fr> Date: Mon, 15 Jun 1998 15:00:29 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Francis, >I believe we need to resume the discussion... >Perhaps this should be on the implementor mailing-list but >the API has not only to be implemented in the kernel but >it has to be used! I think the implementors list is a good idea as that is most of the issue now. Do you want to take it there? >First the whole stuff is related to the so called weak and >strong models for multihomed nodes (cf RFC 1122 section 3.3.4.2): > - with strong model we have to give the outgoing interface > - with weak model the outgoing interface is discovered by the OS. Theoretically yes. >In the whole discussion unicast and anycast addresses are >indiscernible then unicast will stand for both. Agreed. >I believe there are two problems, scopes and interfaces >(then the proposal has both a scope_id and an ifindex). >Both depends of the type of address : > - unicast global addresses don't need a scope_id > nor an ifindex. Even we can provide a route table per interface > I am *strongly against* this idea because it is a major change > for users, for instance I shouldn't like to add an interface > name/index parameter to ftp, telnet, ... The forwarding of > packets (where there is no outgoing interface provided) is > more complicated too. The last argument is obvious, IPv4 nodes > use in general the weak model today. Agreed. > - multicast addresses are very different, with the standard > IPv4 API for multicast if you don't provide the outgoing > interface the OS pickup one with a strange default rule > then it is a good idea to force users to provide it. > The scope doesn't matter (if it is more than node-local :-) > even for site-local multicasts if you have no multisited > interfaces (reasonable assumption). Agreed this is how IPv4 works. > - unicast site-local addresses are a special case because > they are an issue only for multisited nodes: > * without multisited nodes there are like global addresses > * on a multisited nodes without multisited interfaces > you have to provide a way to make sites unambiguous, > obviously a scope_id is necessary here. But the extra > parameter for all the applications argument still applies > (for routers intersite routing is forbidden), then > I believe multisited nodes should be made impossible by > the (not yet available) definition of a site... > Remarks you need to know only the site, not the outgoing > interface itself (which must belong to the site of course). > * on multisited nodes with multisited interfaces you're dead! Agree with you in spirit but the flesh is weak. > - the last case is unicast link-local addresses which are > *ambiguous* without the outgoing interface. Today > some programs *need* in6_pktinfo stuff then it is not > possible to remove all ways to provide the outgoing interface. > But if link-local addresses are used only when there are needed, ie: > * on a "site" with only one link like the dentist office > * by neighbor discovery and management applications (like ping) > then it is possible to make the provision of the outgoing interface > mandatory (aka strong model) without an extra harm for users. Yep. >In first conclusion scope_id can be needed for site-local unicast >addresses and ifindex is needed for link-local addresses then >we can have one field with both semantics or two fields, >scope_id ignored for addresses not in fec0::/48 and ifindex >ignored for addresses not in fe80::/64 or ff00::/8. >In fact if you'd like to put one 32 bit field near the beginning >of the sockaddr_in6 structure and keep 64 bit alignment (not >as in DHCPv6 or multicast IPv6 over ATM :-) then we need a >second 32 bit field and hop limit is a good candidate >(limited scope addresses should come with a hop limit). So use a macro to determine the behavior? >They are two other issues: > - do we need default values or rules ? For a multisited node Yes I think so. > I don't understand what should be the default site (but I don't > understand the whole multisited stuff :-). For link-local > unicast a default interface has a meaning in many cases then > I'll buy it as an option. Let Rich and I get out a new draft and see what folks think. > - own link-local addresses are a special case, they can belong > to the loopback interface (a very "logical" interface) or/and to > their interfaces. It is an implementation problem but even with > IPv4 you can get strange results... (for instance on Ciscos > for point-to-point interfaces a ping on an own link-local address > does a remote loop which is both a good and bad idea according > to what you'd like to do and what you expect to get :-). Yep. thanks this will help us complete our draft for sure, /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 Jun 16 10:32:45 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id KAA05961 for ipng-dist; Tue, 16 Jun 1998 10:26:02 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id KAA05954 for ; Tue, 16 Jun 1998 10:25:53 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA12574 for ; Tue, 16 Jun 1998 10:25:52 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA07784 for ; Tue, 16 Jun 1998 10:25:50 -0700 (PDT) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA05554; Tue, 16 Jun 1998 10:25:33 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199805131815.DAA08621@necom830.hpcl.titech.ac.jp> References: <199805051055.GAA01887@ietf.org>; from "The IESG" at May 5, 98 6:55 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Jun 1998 10:26:13 -0700 To: Masataka Ohta From: Steve Deering Subject: (IPng 5885) Re: Last Call: Internet Protocol, Version 6 (IPv6) to Draft Standard Cc: ipng@sunroof.eng.sun.com, iesg@ietf.org Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a response to the comments by Masataka Ohta on the IESG's Last Call for advancing the base IPv6 spec to Draft Standard. At 11:15 AM -0700 5/13/98, Masataka Ohta wrote: > I'm agaist the promotion because: > > 1) The change on minimal MTU is significant to worth it be > a proposed standard again. > ... > > 1) is a procedural problem, which may be technically ignored. I would argue that the change of minimum MTU should not be considered a reason to delay advancement to Draft Standard, because: (a) It is not a change of the protocol (i.e., an addition or deletion of a feature or behavior), but rather just an adjustment of one of the protocol's parameters. (If you wish to argue that the specification of a "large" minimum MTU is a change, well that change was present in the Proposed Standard version -- which replaced IPv4's 68-octet min MTU with 576 -- so the use of a "large" min MTU has already passed the number-of-implementations and passage-of-time requirements to advance to Draft.) (b) The decision to make the change of min MTU from 576 to 1280, the documentation of that change, and the implementation of that change in most (probably all) of the many IPv6 host and router implementations occurred more than six months ago, with no reported interoperability problems or any other kinds of problems. Thus the necessary multiple-implementations and passage-of-time requirements of the IETF have in fact been met, and insisting on another six month delay is very unlikely to uncover problems that would not already have surfaced. > 2) The current specification does not limit the length > of the header. > > ... 2) is a fatal problem. No, it is not a fatal problem, it is a feature, an improvement that makes IPv6 more flexible than IPv4. > However, there seems to be a persistent confusion in IPNG WG that the > problem could have been solved by fragmentation. I don't remember anyone -- prior to your Last Call comments -- claiming on the ipngwg mailing list or in an IPng WG meeting that the lack of a fixed bound on header(s) size was a problem for IPv6. Therefore, suggesting that the WG suffers from "persistent confusion" about the solution to this newly alleged problem seems unjustified to me. > The problem 2) is that, even though there are some non-TCP > protocols such as DNS over UDP which needs a standard on smallest > payload size, which is not given by IPv6. > > With IPv4, reassembly buffer is assured to be 576 byte long > and headers are, at most, 64 byte long, which means 512 bytes > of payload data can be safely transmitted betweeen IPv4 networks > and a sender. To make the network more active, however, even > though the size of the reassembly buffer of IPv6 The final sentence in the paragraph above is incomplete, so I cannot understand your description of the alleged problem. > Worse, the kernel may insert some header unknown to the applications. That's an implementation problem, not a protocol problem. If a kernel is capable of inserting headers (other than Fragment headers) into outgoing packets, it must also have some way of telling the upper-layer protocols how many bytes of headers are being inserted, so that the upper layers can take that into account when choosing how many bytes of payload to send. Whatever API is used to tell the upper layers about the Path MTU (as required for Path MTU Discovery) would be a natural place to include this information. If a node's kernel has been configured to insert so many header bytes into all outgoing packets that specific upper-layer protocols won't work on that node because their minimum payload size requirements cannot be satisfied within the reassembly buffer size of the destination(s), then you have the choice of not running those upper-layer protocols on that node or fixing the kernel configuration. Imposing a limit on the number of header bytes in an IPv6 packet would unnecessarily limit the capabilities of IPv6 for upper-layer protocols that do *not* have a particular payload size constraint. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 18 09:31:49 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id JAA11684 for ipng-dist; Thu, 18 Jun 1998 09:20:30 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id JAA11677 for ; Thu, 18 Jun 1998 09:20:14 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA04764 for ; Thu, 18 Jun 1998 09:20:12 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA14959 for ; Thu, 18 Jun 1998 09:20:11 -0700 (PDT) From: Masataka Ohta Message-Id: <199806181611.BAA11992@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA11992; Fri, 19 Jun 1998 01:11:21 +0900 Subject: (IPng 5889) Re: Last Call: Internet Protocol, Version 6 To: deering@cisco.com (Steve Deering) Date: Fri, 19 Jun 98 1:11:20 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com, iesg@ietf.org In-Reply-To: ; from "Steve Deering" at Jun 16, 98 10:26 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve; > I would argue that the change of minimum MTU should not be considered a > reason to delay advancement to Draft Standard, because: > > (a) It is not a change of the protocol (i.e., an addition or > deletion of a feature or behavior), but rather just an > adjustment of one of the protocol's parameters. > > (If you wish to argue that the specification of a "large" > minimum MTU is a change, well that change was present in the > Proposed Standard version -- which replaced IPv4's 68-octet > min MTU with 576 -- so the use of a "large" min MTU has already > passed the number-of-implementations and passage-of-time > requirements to advance to Draft.) The change from 576 to 1280 is significant at least because it may make PMTU discovery totally unnecessary, which is a protocol change. > (b) The decision to make the change of min MTU from 576 to 1280, > the documentation of that change, and the implementation of > that change in most (probably all) of the many IPv6 host and > router implementations occurred more than six months ago, with > no reported interoperability problems or any other kinds of > problems. Thus the necessary multiple-implementations and > passage-of-time requirements of the IETF have in fact been met, > and insisting on another six month delay is very unlikely > to uncover problems that would not already have surfaced. Then, can we measure the actual path MTUs used? Or, you can argue that the operational experiences we have collected so far are not real ones. :-) The operational experiences of proposed standard protocols are required also to remove unnecessary features. > > 2) The current specification does not limit the length > > of the header. > > > > ... 2) is a fatal problem. > > No, it is not a fatal problem, it is a feature, an improvement that makes > IPv6 more flexible than IPv4. > > > However, there seems to be a persistent confusion in IPNG WG that the > > problem could have been solved by fragmentation. > > I don't remember anyone -- prior to your Last Call comments -- claiming > on the ipngwg mailing list or in an IPng WG meeting that the lack of a > fixed bound on header(s) size was a problem for IPv6. I pointed it out at the WG last call and there has been a confusion that the issue can be solved by fragmentation. > > The problem 2) is that, even though there are some non-TCP > > protocols such as DNS over UDP which needs a standard on smallest > > payload size, which is not given by IPv6. > > > > With IPv4, reassembly buffer is assured to be 576 byte long > > and headers are, at most, 64 byte long, which means 512 bytes > > of payload data can be safely transmitted betweeen IPv4 networks > > and a sender. To make the network more active, however, even > > though the size of the reassembly buffer of IPv6 > > The final sentence in the paragraph above is incomplete, so I cannot > understand your description of the alleged problem. Oops, sorry. The problem is that the increase size of the reassembly buffer of IPv6 does not assure that we can trasmit 512 byte of payload. Again, the issue can not be solved by forcing an insertion of the fragmentation header. > > Worse, the kernel may insert some header unknown to the applications. > > That's an implementation problem, not a protocol problem. It is a protocol problem. See below. > If a kernel > is capable of inserting headers (other than Fragment headers) into outgoing > packets, it must also have some way of telling the upper-layer protocols > how many bytes of headers are being inserted, so that the upper layers can > take that into account when choosing how many bytes of payload to send. Wrong. Upper layer protocol specifications are written independent of kernels, which makes the problem a protocol problem. To assist the design of the upper layer protocols, it is necessary to specify within the standard, how many bytes are left for the payload. > Whatever API is used to tell the upper layers about the Path MTU (as > required for Path MTU Discovery) would be a natural place to include this > information. You are the live example of the persistent confusion. This is NOT the MTU problem. This is the problem of reassmebly buffer size. When a header is 1490 byte long, you can use only 10 bytes of payload, which means even TCP do not work, regardless of whether the packet is fragmented or not. > If a node's kernel has been configured to insert so many header bytes into > all outgoing packets that specific upper-layer protocols won't work on that > node because their minimum payload size requirements cannot be satisfied > within the reassembly buffer size of the destination(s), then you have the > choice of not running those upper-layer protocols on that node or fixing > the kernel configuration. Wether some node runs some protocol or not is an operational, not protocol, problem, of course. However, as a protocol issue, the upper layer protocols need a kernel-independent value on the safe payload length. For the compatibility to IPv4, the value MUST be not less than 512 bytes long. Moreover, a kernel may be asked to insert some header invisible to the application, for example, for mobility. > Imposing a limit on the number of header bytes in an IPv6 packet would > unnecessarily limit the capabilities of IPv6 for upper-layer protocols > that do *not* have a particular payload size constraint. ??? Can you show me some example? Even TCP needs some minimum assured payload length because it need a fixed size header in every packet. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 18 11:38:31 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id LAA12042 for ipng-dist; Thu, 18 Jun 1998 11:31:12 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id LAA12035 for ; Thu, 18 Jun 1998 11:31:01 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA17884 for ; Thu, 18 Jun 1998 11:30:58 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id LAA11494 for ; Thu, 18 Jun 1998 11:30:59 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id NAA14111; Thu, 18 Jun 1998 13:30:41 -0500 Message-Id: <199806181830.NAA14111@gungnir.fnal.gov> To: Masataka Ohta Cc: deering@cisco.com (Steve Deering), ipng@sunroof.eng.sun.com, iesg@ietf.org From: "Matt Crawford" Subject: (IPng 5890) Re: Last Call: Internet Protocol, Version 6 In-reply-to: Your message of Fri, 19 Jun 1998 01:11:20 +0200. <199806181611.BAA11992@necom830.hpcl.titech.ac.jp> Date: Thu, 18 Jun 1998 13:30:41 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The change from 576 to 1280 is significant at least because it > may make PMTU discovery totally unnecessary, which is a protocol > change. It does not eliminate the usefulness of PMTU discovery. By itself that doesn't quite contradict your statement, but add to it the presumption that systems will use the full MTU of their local link when possible and you are refuted. Your other complaint, about the protocol spec. not limiting the headers the kernel can insert, is just another, and more unlikely, example of a problem that could occur in IPv4 but which, in practice, does not. Some routers block fragments with small offset values to avoid certain attacks. If a link exists with the minimum allowed MTU value of 68 bytes, then a node which inserts the maximum IPv4 options cannot communicate through that link and that router. > Even TCP needs some minimum assured payload length because it need > a fixed size header in every packet. 1. It's not fixed in size. 2. It must appear in every *reassembled* packet. TCP could work (although very badly!) with just one available byte per packet. Masataka, could you please state your goal? If IPv6 were recycled at PS, what would you change? Are you aware that your first objection (mn. allowed MTU increase) diminishes the significance of your second objection (unlimited extension headers)? ______________________________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab "A5.1.5.2.7.1. Remove all classified and CCI boards from the COMSEC equipment, thoroughly smash them with a hammer or an ax, and scatter the pieces." -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 18 19:26:37 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id TAA12533 for ipng-dist; Thu, 18 Jun 1998 19:17:57 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id TAA12526 for ; Thu, 18 Jun 1998 19:17:40 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA11096 for ; Thu, 18 Jun 1998 19:17:40 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id TAA09964 for ; Thu, 18 Jun 1998 19:17:40 -0700 (PDT) From: Masataka Ohta Message-Id: <199806190206.LAA12913@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA12913; Fri, 19 Jun 1998 11:06:10 +0900 Subject: (IPng 5891) Re: Last Call: Internet Protocol, Version 6 To: crawdad@fnal.gov (Matt Crawford) Date: Fri, 19 Jun 98 11:06:09 JST Cc: mohta@necom830.hpcl.titech.ac.jp, deering@cisco.com, ipng@sunroof.eng.sun.com, iesg@ietf.org In-Reply-To: <199806181830.NAA14111@gungnir.fnal.gov>; from "Matt Crawford" at Jun 18, 98 1:30 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt; > > The change from 576 to 1280 is significant at least because it > > may make PMTU discovery totally unnecessary, which is a protocol > > change. > > It does not eliminate the usefulness of PMTU discovery. It does not elminate PMTUD but make it almost uselss. > By itself > that doesn't quite contradict your statement, but add to it the > presumption that systems will use the full MTU of their local link > when possible and you are refuted. "when possible"? What do you mean? Systems should use the full MTU of their local link when possible and meaningful. We may use link local MTU when the destination is located link local, for example. > Your other complaint, about the protocol spec. not limiting the > headers the kernel can insert, is just another, and more unlikely, > example of a problem that could occur in IPv4 but which, in practice, > does not. Some routers block fragments with small offset values to > avoid certain attacks. If a link exists with the minimum allowed MTU > value of 68 bytes, then a node which inserts the maximum IPv4 options > cannot communicate through that link and that router. Matt, you are another live example of the persistent misunderstanding. It is not a fragmentation issue. > > Even TCP needs some minimum assured payload length because it need > > a fixed size header in every packet. > > 1. It's not fixed in size. > 2. It must appear in every *reassembled* packet. > > TCP could work (although very badly!) with just one available byte > per packet. TCP may work with just one available byte per fragmented packet, as long as the payload length of the reassembled packet is not less than 21 bytes. However, when the payload of a unfragmented or reassembled packet is 10 byte long, which is smaller than TCP header, TCP does not work. > Masataka, could you please state your goal? To make IPv6 work. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 19 02:20:03 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id CAA13096 for ipng-dist; Fri, 19 Jun 1998 02:11:16 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id CAA13089 for ; Fri, 19 Jun 1998 02:11:07 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA24691 for ; Fri, 19 Jun 1998 02:10:59 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id CAA13577 for ; Fri, 19 Jun 1998 02:10:59 -0700 (PDT) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id CAA21827; Fri, 19 Jun 1998 02:10:21 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199806181611.BAA11992@necom830.hpcl.titech.ac.jp> References: ; from "Steve Deering" at Jun 16, 98 10:26 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Jun 1998 02:11:00 -0700 To: Masataka Ohta From: Steve Deering Subject: (IPng 5892) Re: Last Call: Internet Protocol, Version 6 Cc: ipng@sunroof.eng.sun.com, iesg@ietf.org Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:11 AM -0700 6/18/98, Masataka Ohta wrote: > The change from 576 to 1280 is significant at least because it > may make PMTU discovery totally unnecessary, which is a protocol > change. Masataka, PMTU Discovery has never been "totally necessary", regardless of the minumum MTU. It is *beneficial* to perform PMTU Discovery whether the minimum MTU is 68, 576 or 1280. *How* beneficial it is depends on the actual MTUs encountered in the Internet. Currently there are many paths with MTU of 1500, which is larger than 1280, and there are some paths with MTUs significantly larger than 1500. Within the lifetime of IPv6, the Internet may well change to have very many paths with MTUs significantly larger than 1280. Therefore, changing the minimum MTU to 1280 does not eliminate the desirability of performing PMTU Discovery, and we have not changed the protocol as a consequence of increasing the minimum MTU to 1280. > > (b) The decision to make the change of min MTU from 576 to 1280, > > the documentation of that change, and the implementation of > > that change in most (probably all) of the many IPv6 host and > > router implementations occurred more than six months ago, with > > no reported interoperability problems or any other kinds of > > problems. Thus the necessary multiple-implementations and > > passage-of-time requirements of the IETF have in fact been met, > > and insisting on another six month delay is very unlikely > > to uncover problems that would not already have surfaced. > > Then, can we measure the actual path MTUs used? That sounds like a big job with very little likelihood of any payoff, but if you think that by doing such measurements you can prove some unknown and unanticipated failure introduced by the increase of minimum MTU, you are welcome to try. > The operational experiences of proposed standard protocols are > required also to remove unnecessary features. If you are trying to argue that Path MTU Discovery should be removed from IPv6, then please just say so directly. I presume that features will be added to and removed from IPv6 over its lifetime as conditions and requirements change and as more experience is acquired, just as has been the case with IPv4. But unless you can show that Path MTU Discovery as currently specified for IPv6 has a serious interoperability problem, I don't think your displeasure with the presence of that feature should be sufficient grounds to delay the advancement of the protocol along the standards track. > > I don't remember anyone -- prior to your Last Call comments -- claiming > > on the ipngwg mailing list or in an IPng WG meeting that the lack of a > > fixed bound on header(s) size was a problem for IPv6. > > I pointed it out at the WG last call... But as I said, prior to your message, no one raised the issue. > ...and there has been a confusion that the issue can be solved by > fragmentation. In the same message that raised the issue for the first time, you accused the WG of "persistent confusion" about the issue. Since the WG had never discussed it, you had no basis for such an accusation. > Oops, sorry. The problem is that the increase size of the reassembly > buffer of IPv6 does not assure that we can trasmit 512 byte of payload. That's correct, the protocol made no such assurance when the min MTU was 576, nor when it changed to 1280. The assurance is obtained operationally: it would stupid to configure a node to insert more than 768 bytes of header into *every* outgoing packet, not only because it would prevent the use of protocols of the sort you are worried about, but also because it would be a terribly inefficient use of bandwidth. However, that does not mean it is stupid to allow the use of more than 768 bytes of header in *some* packets (preferably infrequent ones). > Again, the issue can not be solved by forcing an insertion of the > fragmentation header. I never said it could. > > If a kernel > > is capable of inserting headers (other than Fragment headers) into outgoing > > packets, it must also have some way of telling the upper-layer protocols > > how many bytes of headers are being inserted, so that the upper layers can > > take that into account when choosing how many bytes of payload to send. > > Wrong. > > Upper layer protocol specifications are written independent of > kernels, which makes the problem a protocol problem. The notion of "kernels" is OS-specific, and indeed has no place in a protocol spec. However, protocols designed to operate over IP must take into account the needs and constraints of IP. There is a tradeoff beween payload size and IP-layer header size (and, ideally, path MTU), and that tradeoff may differ for different upper-layer protocols and in different environments. The more adaptable the upper-layer protocols and the more adaptable the IP layer, the better. Communication between the layers is essential to enable such adaptivity. > To assist the design of the upper layer protocols, it is necessary > to specify within the standard, how many bytes are left for the > payload. If you *really* need to wire a single payload size number into your upper- layer protocol, go ahead and use 1024. That would allow up to 476 bytes of headers within the required reassembly buffer size, which had better be more than enough for most packets (that's 32% header overhead -- if we need more than that, datagrams are doomed). But that's an operational recommendation, not a protocol requirement. > > Whatever API is used to tell the upper layers about the Path MTU (as > > required for Path MTU Discovery) would be a natural place to include this > > information. > > You are the live example of the persistent confusion. > > This is NOT the MTU problem. This is the problem of reassmebly > buffer size. I understand that. The fact that you are confused by my answer does not imply that I am confused. :-) There is an API needed between IPv6 and the upper layers to support Path MTU Discovery; I was suggesting extending that API to include other IP length information -- in particular, information about how many bytes of header will be inserted by the IP layer. For an upper-layer protocol that adapts to Path MTU, that value would be subtracted from the discovered MTU. For non-adaptive upper-layers, that value would be subtracted from 1280 (if it wished to avoid any chance of fragmentation) or from the reassembly buffer size of the destination (either the minimum value of 1500 or a larger value learned through a protocol exchange). > When a header is 1490 byte long, you can use only 10 bytes of payload, > which means even TCP do not work, regardless of whether the packet > is fragmented or not. Correct. That's a good reason not to put 1490 bytes of header in a TCP packet. > However, as a protocol issue, the upper layer protocols need a > kernel-independent value on the safe payload length. For the > compatibility to IPv4, the value MUST be not less than 512 bytes long. I don't know where you got the 512 number from. For IPv4, the maximum assured payload size is 576 - 60 = 516. For applications above the "kernel" (i.e., above the transport layer), the maximum assured payload size is 576 - 60 - 60 = 456 for users of TCP, and 576 - 60 - 8 = 508 for users of UDP. > Moreover, a kernel may be asked to insert some header invisible > to the application, for example, for mobility. The content of an inserted header may be invisible to the application, but there must be some way for the application to discover its presence and its size. That is necessary for proper application adaptation to path MTU. The same header-size discovery mechanism may also be used for applications that do not adapt to path MTU. > > Imposing a limit on the number of header bytes in an IPv6 packet would > > unnecessarily limit the capabilities of IPv6 for upper-layer protocols > > that do *not* have a particular payload size constraint. > > ??? > > Can you show me some example? "Signalling" protocols like RSVP need to send infrequent messages to routers along a path or multicast tree. In IPv6, such signalling could be accomplished with a Hop-by-Hop Options header (to touch every router along a path) or with a Destination Options header preceding a Routing header (to touch specific routers). It is desirable not to place an artificial constraint on the size of those headers. (In the extreme case, a packet may carry nothing but IP-layer headers -- i.e., no information for an upper-layer at the packet's destination, which would be indicated by the "No Next Header" next header value in the last IPv6 extension header.) 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 Jun 19 08:26:07 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id IAA13294 for ipng-dist; Fri, 19 Jun 1998 08:17:51 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id IAA13287 for ; Fri, 19 Jun 1998 08:17:33 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA05689 for ; Fri, 19 Jun 1998 08:17:32 -0700 Received: from imo26.mx.aol.com (imo26.mx.aol.com [198.81.17.70]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA26882 for ; Fri, 19 Jun 1998 08:17:29 -0700 (PDT) Received: from Telford001@aol.com by imo26.mx.aol.com (IMOv14_b1.1) id AOZOa04520; Fri, 19 Jun 1998 11:16:30 -0400 (EDT) Message-ID: Date: Fri, 19 Jun 1998 11:16:30 EDT To: deering@cisco.com, mohta@necom830.hpcl.titech.ac.jp Cc: ipng@sunroof.eng.sun.com, iesg@ietf.org Mime-Version: 1.0 Subject: (IPng 5893) Re: Last Call: Internet Protocol, Version 6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 6/19/98 5:23:32 AM Eastern Daylight Time, deering@cisco.com writes: > > > Whatever API is used to tell the upper layers about the Path MTU (as > > > required for Path MTU Discovery) would be a natural place to include this > > > information. > > You are the live example of the persistent confusion. > > This is NOT the MTU problem. This is the problem of reassmebly > > buffer size. > I understand that. The fact that you are confused by my answer does not > imply that I am confused. :-) There is an API needed between IPv6 and the > upper layers to support Path MTU Discovery; I was suggesting extending > that API to include other IP length information -- in particular, > information about how many bytes of header will be inserted by the IP layer. > For an upper-layer protocol that adapts to Path MTU, that value would be > subtracted from the discovered MTU. For non-adaptive upper-layers, that > value would be subtracted from 1280 (if it wished to avoid any chance > of fragmentation) or from the reassembly buffer size of the destination > (either the minimum value of 1500 or a larger value learned through > a protocol exchange). Is providing IP header length information necessarily meaningful at this point? Suppose the destination is group or multicast. The packet may be transmitted on multiple interfaces with different amounts of header information transmitted on each interface. > > When a header is 1490 byte long, you can use only 10 bytes of payload, > > which means even TCP do not work, regardless of whether the packet > > is fragmented or not. > Correct. That's a good reason not to put 1490 bytes of header in a TCP > packet. > > However, as a protocol issue, the upper layer protocols need a > > kernel-independent value on the safe payload length. For the > > compatibility to IPv4, the value MUST be not less than 512 bytes long. > I don't know where you got the 512 number from. For IPv4, the maximum > assured payload size is 576 - 60 = 516. For applications above the > "kernel" (i.e., above the transport layer), the maximum assured payload > size is 576 - 60 - 60 = 456 for users of TCP, and 576 - 60 - 8 = 508 for > users of UDP. > > Moreover, a kernel may be asked to insert some header invisible > > to the application, for example, for mobility. > The content of an inserted header may be invisible to the application, > but there must be some way for the application to discover its presence > and its size. That is necessary for proper application adaptation to path > MTU. The same header-size discovery mechanism may also be used for > applications that do not adapt to path MTU. > > > Imposing a limit on the number of header bytes in an IPv6 packet would > > > unnecessarily limit the capabilities of IPv6 for upper-layer protocols > > > that do *not* have a particular payload size constraint. > > ??? > > Can you show me some example? > "Signalling" protocols like RSVP need to send infrequent messages to > routers along a path or multicast tree. In IPv6, such signalling could > be accomplished with a Hop-by-Hop Options header (to touch every router > along a path) or with a Destination Options header preceding a Routing > header (to touch specific routers). It is desirable not to place an > artificial constraint on the size of those headers. (In the extreme case, > a packet may carry nothing but IP-layer headers -- i.e., no information > for an upper-layer at the packet's destination, which would be indicated by > the "No Next Header" next header value in the last IPv6 extension header.) I have not been giving full attention to this discussion, but I have the impression that Masataka Ohta is actually asking for a new parameter to characterize the protocol, a minimum transmit unit payload size. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 19 08:48:20 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id IAA13336 for ipng-dist; Fri, 19 Jun 1998 08:39:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id IAA13329 for ; Fri, 19 Jun 1998 08:39:32 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA11099 for ; Fri, 19 Jun 1998 08:39:31 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA09482 for ; Fri, 19 Jun 1998 08:39:29 -0700 (PDT) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA12721; Fri, 19 Jun 1998 08:38:41 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Jun 1998 08:39:23 -0700 To: Telford001@aol.com From: Steve Deering Subject: (IPng 5894) Re: Last Call: Internet Protocol, Version 6 Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com, iesg@ietf.org Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:16 AM -0700 6/19/98, Telford001@aol.com wrote: > Is providing IP header length information necessarily meaningful > at this point? Suppose the destination is group or multicast. > The packet may be transmitted on multiple interfaces with > different amounts of header information transmitted on > each interface. A source of an IP multicast packet transmits that packet on one interface only; it is the routers' responsibility to forward the packet to all necessary links. When a router originates a multicast packet, the same model applies, in that logically the packet is "originated" on one interface and then "forwarded" to any other interfaces required. Forwarders are not permitted to insert headers into IPv6 packets. (If they wish to add information to a packet, they can do so by encapsulation.) 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 Jun 19 10:17:04 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id KAA13727 for ipng-dist; Fri, 19 Jun 1998 10:05:02 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id KAA13720 for ; Fri, 19 Jun 1998 10:04:52 -0700 (PDT) From: Telford001@aol.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA00194 for ; Fri, 19 Jun 1998 10:04:49 -0700 Received: from imo27.mx.aol.com (imo27.mx.aol.com [198.81.17.71]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA25399 for ; Fri, 19 Jun 1998 10:04:49 -0700 (PDT) Received: from Telford001@aol.com by imo27.mx.aol.com (IMOv14_b1.1) id AZKDa06640; Fri, 19 Jun 1998 12:54:20 -0400 (EDT) Message-ID: <455b47bc.358a97bd@aol.com> Date: Fri, 19 Jun 1998 12:54:20 EDT To: deering@cisco.com Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com, iesg@ietf.org Mime-Version: 1.0 Subject: (IPng 5895) Re: Last Call: Internet Protocol, Version 6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 6/19/98 11:38:45 AM Eastern Daylight Time, deering@cisco.com writes: > At 8:16 AM -0700 6/19/98, Telford001@aol.com wrote: > > Is providing IP header length information necessarily meaningful > > at this point? Suppose the destination is group or multicast. > > The packet may be transmitted on multiple interfaces with > > different amounts of header information transmitted on > > each interface. > A source of an IP multicast packet transmits that packet on one interface > only; it is the routers' responsibility to forward the packet to all > necessary links. When a router originates a multicast packet, the same > model applies, in that logically the packet is "originated" on one > interface and then "forwarded" to any other interfaces required. > Forwarders are not permitted to insert headers into IPv6 packets. > (If they wish to add information to a packet, they can do so by > encapsulation.) Telford Tools' VLAN Router contains a standard Berkeley network and socket layer. Whether it runs as a host (pure LAN switching mode) or as a router (VLAN routing moder), packet transmission takes place the same way. The source address is filled in and the destination is looked up in the routing table, and the packet is forwarded out the appropriate interface(s) with the appropriate IP headers. The VLAN router supports several multicast receive interfaces, but the existence of such interfaces are independent of multicast transmit and these receive interfaces have no associated transmit logic. In any case with IPv4, it would not necessarily make sense to choose the same SERVICE TYPE on all outgoing interfaces and there would be no obvious reason to choose SERVICE TYPE on the basis of the source address that happens to be chosen. IPv4 options are not obviously outgoing interface specific but there is no reason options should not be outgoing interface specific in the future. The point is the following. In a router there are multiple interfaces. I think the claim is that one interface is the source that should govern that nature of the IPv6 header and the packet is then forwarded to all other interfaces that are not permitted to insert headers into IPv6 packets. In point of fact, in Berkeley and VLAN Router architecture, a source address is selected, but the packet does not actually go through the output logic associated with the transmit interface associated with the receive interface associated with that IP address, and there is no obvious reason why that output interface should define the IP header for the packet on the interface(s) from which the packet is being transmitted. Joachim Carlo Santos Martillo Ajami Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 19 11:20:08 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id LAA13795 for ipng-dist; Fri, 19 Jun 1998 11:11:04 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id LAA13788 for ; Fri, 19 Jun 1998 11:10:37 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA23171 for ; Fri, 19 Jun 1998 11:10:28 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA07437 for ; Fri, 19 Jun 1998 11:10:04 -0700 (PDT) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA29889; Fri, 19 Jun 1998 11:09:56 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <455b47bc.358a97bd@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Jun 1998 11:10:56 -0700 To: Telford001@aol.com From: Steve Deering Subject: (IPng 5896) Re: Last Call: Internet Protocol, Version 6 Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have removed iesg@ietf.org from the Cc: line, since this is wandering beyond the issue of Last Call comments. At 9:54 AM -0700 6/19/98, Telford001@aol.com wrote: > [author's router product] contains a standard Berkeley network and socket > layer. Then you should already know what I explained, because what I described is how the BSD kernel multicast support works. > Whether it runs as a host (pure LAN switching mode) or > as a router (VLAN routing moder), packet transmission takes > place the same way. We were talking about IP multicast, not about LAN switching or VLANs. In the normal usage of that jargon in this industry, those are distinct concepts. (I do *not* want to enter into a debate here about whether they *ought* to be distinct. Regardless, using fairly standard jargon in non-standard ways tends to inhibit rather than facilitate clear communication.) > In point of fact, in Berkeley and VLAN > Router architecture, a source address > is selected, but the packet does > not actually go through the output > logic associated with the transmit > interface associated with the receive > interface associated with that IP > address,... I don't know about the "VLAN Router", but you are incorrect about the BSD architecture. I know because I designed the IP multicast architecture and wrote the IP multicast code that is in the BSD kernel. (More precisely, I wrote the earliest versions of that code; it has since been enhanced by other people working with me, and probably by some of the BSD stack vendors.) > ...and there is no obvious > reason why that output interface should > define the IP header for the packet > on the interface(s) from which the > packet is being transmitted. The reasons may not be obvious to you, but they exist. 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 Jun 19 12:50:51 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id MAA13882 for ipng-dist; Fri, 19 Jun 1998 12:42:23 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id MAA13875 for ; Fri, 19 Jun 1998 12:42:15 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA17799 for ; Fri, 19 Jun 1998 12:41:57 -0700 Received: from imo12.mx.aol.com (imo12.mx.aol.com [198.81.17.2]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA28583 for ; Fri, 19 Jun 1998 12:41:46 -0700 (PDT) Received: from Telford001@aol.com by imo12.mx.aol.com (IMOv14_b1.1) id AEVVa11468; Fri, 19 Jun 1998 15:41:31 -0400 (EDT) Message-ID: Date: Fri, 19 Jun 1998 15:41:31 EDT To: deering@cisco.com Cc: ipng@sunroof.eng.sun.com, Telford001@aol.com Mime-Version: 1.0 Subject: (IPng 5897) Re: Last Call: Internet Protocol, Version 6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 6/19/98 2:34:31 PM Eastern Daylight Time, deering@cisco.com writes: > Then you should already know what I explained, because what I described is > how the BSD kernel multicast support works. > > Whether it runs as a host (pure LAN switching mode) or > > as a router (VLAN routing mode), packet transmission takes > > place the same way. > We were talking about IP multicast, not about LAN switching or VLANs. > In the normal usage of that jargon in this industry, those are distinct > concepts. (I do *not* want to enter into a debate here about whether > they *ought* to be distinct. Regardless, using fairly standard jargon > in non-standard ways tends to inhibit rather than facilitate clear > communication.) I mentioned LAN switching mode because in that mode the VLAN router is a simple host with a single network interface. In VLAN Router mode, the VLAN router has multiple interfaces. As the same ip_output routine, which comes from the BSD distribution that we licensed, is used in all cases, outputing ip multicast works exactly the same way in both simple host and multi-interface forwarder mode (router mode). > > In point of fact, in Berkeley and VLAN > > Router architecture, a source address > > is selected, but the packet does > > not actually go through the output > > logic associated with the transmit > > interface associated with the receive > > interface associated with that IP > > address,... > I don't know about the "VLAN Router", but you are incorrect about the > BSD architecture. I know because I designed the IP multicast architecture > and wrote the IP multicast code that is in the BSD kernel. (More precisely, > I wrote the earliest versions of that code; it has since been enhanced by > other people working with me, and probably by some of the BSD stack vendors.) Options come from the socket configuration. In the case of multicast destination, the destination address is resolved into a list of output interfaces. If the socket has a defined source address, this source address is used for every interface the multicast IP packet is output. If the socket does not have a defined source address, for each multicast IP packet out, the source address of the interface from which it is being output is put into the packet and the configuration of the output interface determines the detailed fields of the multicast IP packet header. > > ...and there is no obvious > > reason why that output interface should > > define the IP header for the packet > > on the interface(s) from which the > > packet is being transmitted. > The reasons may not be obvious to you, but they exist. Now maybe there are different variants of the ip_output code, but if this is the algorithm being used, it seems that in the case of a socket with no defined source address, all output interfaces are considered equal and the header characteristics (including header length) of the multicast packet transmitted out each interface could be quite different. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 22 11:26:35 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id LAA16027 for ipng-dist; Mon, 22 Jun 1998 11:18:06 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id LAA16015 for ; Mon, 22 Jun 1998 11:17:31 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA02920 for ; Mon, 22 Jun 1998 11:17:11 -0700 Received: from inner.net (avarice.inner.net [198.82.204.99]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA16429 for ; Mon, 22 Jun 1998 11:17:08 -0700 (PDT) Received: from inner.net (stan.ipv6.nrl.navy.mil [132.250.90.8]) by inner.net (8.9.0/8.8.5) with ESMTP id SAA05780 for ; Mon, 22 Jun 1998 18:12:45 GMT Message-Id: <199806221812.SAA05780@inner.net> To: ipng@sunroof.eng.sun.com Subject: (IPng 5899) IPV6_ADDRFORM X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Mon, 22 Jun 1998 14:15:48 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A co-worker's recent question showed that I missed the removal of IPV6_ADDRFORM option from the Basic API as of the November, 1997 draft. I hate to re-open a past discussion, but, as someone who uses this option operationally every day, I believe that the AF_INET6 IPv4-mapped socket downgrade function is required for a graceful transition to IPv6. For example, I have two FTP daemons on my system. My inetd equivalent listens on an AF_INET6 socket. If the incoming connection is IPv4-mapped, it downgrades the socket and fires of the OPIE ftp daemon, which doesn't support IPv6 (and isn't going to for a while because I have too much other work to do). If the incoming connection isn't IPv4-mapped, it fires off the inet6-apps ftp daemon, which does support IPv6, but doesn't support OTP. Would anyone object to the re-introduction of this setsockopt() (possibly with more restrictions on it, so it only does the easy AF_INET6 IPv4-mapped <-> AF_INET transitions), possibly in the Advanced API? -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 22 14:45:28 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id OAA16298 for ipng-dist; Mon, 22 Jun 1998 14:39:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id OAA16291 for ; Mon, 22 Jun 1998 14:39:10 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA01125 for ; Mon, 22 Jun 1998 14:39:08 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA07500 for ; Mon, 22 Jun 1998 14:39:09 -0700 (PDT) From: Masataka Ohta Message-Id: <199806222130.GAA04791@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA04791; Tue, 23 Jun 1998 06:30:20 +0900 Subject: (IPng 5900) Re: Last Call: Internet Protocol, Version 6 To: deering@cisco.com (Steve Deering) Date: Tue, 23 Jun 98 6:30:19 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com, iesg@ietf.org In-Reply-To: ; from "Steve Deering" at Jun 19, 98 2:11 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve; > > The change from 576 to 1280 is significant at least because it > > may make PMTU discovery totally unnecessary, which is a protocol > > change. > PMTU Discovery has never been "totally necessary", regardless of the > minumum MTU. It is *beneficial* to perform PMTU Discovery whether > the minimum MTU is 68, 576 or 1280. *How* beneficial it is depends on > the actual MTUs encountered in the Internet. When the minimum MTU is sufficiently large, PMTUD is totally unnecessary. Currently there are many paths > with MTU of 1500, which is larger than 1280, and there are some paths with > MTUs significantly larger than 1500. Within the lifetime of IPv6, the > Internet may well change to have very many paths with MTUs significantly > larger than 1280. Therefore, changing the minimum MTU to 1280 does not > eliminate the desirability of performing PMTU Discovery, and we have not > changed the protocol as a consequence of increasing the minimum MTU to > 1280. When MTU larger than 1280 is not so desirable, there is no desirability of performing PMTUD. > > The operational experiences of proposed standard protocols are > > required also to remove unnecessary features. > > If you are trying to argue that Path MTU Discovery should be removed from > IPv6, then please just say so directly. You miss the point. The point of the thread is that whether the change on minimum MTU may affect protocol or not. And it is. As you already stated that the change on minimum MTU is a significant change, we should just follow the normal procedure. The header size problem is answered in a separae mail. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 22 15:51:21 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id PAA16385 for ipng-dist; Mon, 22 Jun 1998 15:45:32 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id PAA16378 for ; Mon, 22 Jun 1998 15:45:21 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA19435 for ; Mon, 22 Jun 1998 15:45:20 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id PAA12781 for ; Mon, 22 Jun 1998 15:45:18 -0700 (PDT) From: Masataka Ohta Message-Id: <199806222236.HAA04856@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id HAA04856; Tue, 23 Jun 1998 07:36:37 +0900 Subject: (IPng 5901) Re: Last Call: Internet Protocol, Version 6 To: deering@cisco.com (Steve Deering) Date: Tue, 23 Jun 98 7:36:36 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com, iesg@ietf.org In-Reply-To: ; from "Steve Deering" at Jun 19, 98 2:11 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve; > That's correct, the protocol made no such assurance when the min MTU was > 576, nor when it changed to 1280. That is, the confusion has been persistent. > > I pointed it out at the WG last call... > > But as I said, prior to your message, no one raised the issue. I pointed it out at the WG last call, only because you have unintentionally posted a mail with incorrect summary of the current specification the problem fixed. > > Oops, sorry. The problem is that the increase size of the reassembly > > buffer of IPv6 does not assure that we can trasmit 512 byte of payload. > The assurance is obtained operationally: it would stupid to configure a > node to insert more than 768 bytes of header into *every* outgoing packet, > not only because it would prevent the use of protocols of the sort you > are worried about, but also because it would be a terribly inefficient > use of bandwidth. However, that does not mean it is stupid to allow the > use of more than 768 bytes of header in *some* packets (preferably > infrequent ones). As the problem is a protocol one, the assurance can not be obtained operationally. Unless there is a protocol specificaiton on precisely when a long header is allowed, upper level protocol designers can not assume that 512 byte payload can be allowed in a specific protocol. > The notion of "kernels" is OS-specific, and indeed has no place in a > protocol spec. However, protocols designed to operate over IP must > take into account the needs and constraints of IP. There is a tradeoff > beween payload size and IP-layer header size (and, ideally, path MTU), > and that tradeoff may differ for different upper-layer protocols and in > different environments. The more adaptable the upper-layer protocols and > the more adaptable the IP layer, the better. Communication between the > layers is essential to enable such adaptivity. I don't think it ideal to make the issue path MTU dependent here. > > To assist the design of the upper layer protocols, it is necessary > > to specify within the standard, how many bytes are left for the > > payload. > > If you *really* need to wire a single payload size number into your upper- > layer protocol, go ahead and use 1024. That would allow up to 476 bytes of > headers within the required reassembly buffer size, which had better be > more than enough for most packets (that's 32% header overhead -- if we need > more than that, datagrams are doomed). I'd rather think it better to limit maximum header size 256 bytes, becasue applications can send 1024 bytes of payload without PMTU discovery. Or, if you insists on loger headers, we can say, instead, that with maximum limit of 476 bytes, applications can send 756 bytes of payload without PMTUD or fragmentation header. The former is better to reduce header overhead in multicast environment where PMTUD is NOT applicable. > But that's an operational > recommendation, not a protocol requirement. An operational recommendtation without which upper layer protocols such as TCP can not work is a protocol requirement. > I understand that. The fact that you are confused by my answer does not > imply that I am confused. :-) There is an API needed between IPv6 and the > upper layers to support Path MTU Discovery; We don't need such an API, though such it may exist in some environment. > I was suggesting extending > that API to include other IP length information -- in particular, > information about how many bytes of header will be inserted by the IP layer. It is not enough. We still need a protocol specified standard value on minimally allowed header length to let generic IP layer protocols, such as mobility, work safely. > > When a header is 1490 byte long, you can use only 10 bytes of payload, > > which means even TCP do not work, regardless of whether the packet > > is fragmented or not. > > Correct. That's a good reason not to put 1490 bytes of header in a TCP > packet. It is also not good to put 1476 bytes of header in a TCP packet, either for obvious reasons. > I don't know where you got the 512 number from. For IPv4, the maximum > assured payload size is 576 - 60 = 516. For applications above the > "kernel" (i.e., above the transport layer), the maximum assured payload > size is 576 - 60 - 60 = 456 for users of TCP, and 576 - 60 - 8 = 508 for > users of UDP. OK. > > Moreover, a kernel may be asked to insert some header invisible > > to the application, for example, for mobility. > > The content of an inserted header may be invisible to the application, > but there must be some way for the application to discover its presence > and its size. That is necessary for proper application adaptation to path > MTU. Assuming PMTUD meaningful, yes. > The same header-size discovery mechanism may also be used for > applications that do not adapt to path MTU. It does not help such applications, when the maximu header length is unlimited. > > > Imposing a limit on the number of header bytes in an IPv6 packet would > > > unnecessarily limit the capabilities of IPv6 for upper-layer protocols > > > that do *not* have a particular payload size constraint. > > > > ??? > > > > Can you show me some example? > > "Signalling" protocols like RSVP need to send infrequent messages to > routers along a path or multicast tree. Sure, and such protocols contain several objects modified hop-by-hop. > In IPv6, such signalling could > be accomplished with a Hop-by-Hop Options header (to touch every router > along a path) or with a Destination Options header preceding a Routing > header (to touch specific routers). In theory, maybe. > It is desirable not to place an > artificial constraint on the size of those headers. In practice, if a packet must carry some length data for hop-by-hop notification, it is necessary that the content and its length varies hop-by-bop. > Then, (In the extreme case, > a packet may carry nothing but IP-layer headers -- i.e., no information > for an upper-layer at the packet's destination, which would be indicated by > the "No Next Header" next header value in the last IPv6 extension header.) I really want to see an example. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 22 17:43:06 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id RAA16627 for ipng-dist; Mon, 22 Jun 1998 17:35:43 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id RAA16620 for ; Mon, 22 Jun 1998 17:35:28 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA17824 for ; Mon, 22 Jun 1998 17:35:29 -0700 Received: from imo26.mx.aol.com (imo26.mx.aol.com [198.81.17.70]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id RAA04621 for ; Mon, 22 Jun 1998 17:35:29 -0700 (PDT) Received: from Telford001@aol.com by imo26.mx.aol.com (IMOv14_b1.1) id 1JHVa04520; Mon, 22 Jun 1998 20:34:39 +2000 (EDT) Message-ID: Date: Mon, 22 Jun 1998 20:34:39 EDT To: mohta@necom830.hpcl.titech.ac.jp, deering@cisco.com Cc: ipng@sunroof.eng.sun.com, iesg@ietf.org, Telford001@aol.com Mime-Version: 1.0 Subject: (IPng 5902) Re: Last Call: Internet Protocol, Version 6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: Unknown (No Version) sub 7 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 6/22/98, 7:05:42 PM, mohta@necom830.hpcl.titech.ac.jp writes: >> Then, (In the extreme case, >> a packet may carry nothing but IP-layer headers -- i.e., no information >> for an upper-layer at the packet's destination, which would be indicated by >> the "No Next Header" next header value in the last IPv6 extension header.) >I really want to see an example. I have to admit to not completely following the argument, but between alternate routing and load sharing between equal cost or near-equal cost routes, there is no reason to assume that the packet sent after the PMTUD has taken place will actually follow the path on which the MTU has been discovered. Therefore, the only safe size for transmitting an IP packet is 1280. Therefore, IP header size should never go beyond a maximum of 1280. Ohta merely seems to be arguing that the maximum header size should be set at something less than 1280 because 1280 is fairly arbitrary and provides no guaranteed payload. Why not choose another smaller arbitrary maximum header size that guarantees a useful payload? If such is Ohta's argument (and I will admit to not being completely sure that such is what he is arguing), Ohta's point is not unreasonable because Ohta seems simply to be saying that there should be a minimum payload size greater than 0. Joachim Martillo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 02:48:08 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id CAA17000 for ipng-dist; Tue, 23 Jun 1998 02:44:33 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id CAA16993 for ; Tue, 23 Jun 1998 02:44:20 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA14536 for ; Tue, 23 Jun 1998 02:44:19 -0700 Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.161]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id CAA20779 for ; Tue, 23 Jun 1998 02:44:16 -0700 (PDT) Received: from cauchy.cs.uni-bonn.de (cauchy.cs.uni-bonn.de [131.220.4.169]) by theory.cs.uni-bonn.de (8.8.8/8.8.8) with ESMTP id LAA22350; Tue, 23 Jun 1998 11:41:59 +0200 (MET DST) From: Ignatios Souvatzis Received: (ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.6.9) id LAA12841; Tue, 23 Jun 1998 11:41:58 +0200 (MET DST) Message-Id: <199806230941.LAA12841@cauchy.cs.uni-bonn.de> Subject: (IPng 5903) Re: Last Call: Internet Protocol, Version 6 In-Reply-To: <199806222130.GAA04791@necom830.hpcl.titech.ac.jp> from Masataka Ohta at "Jun 23, 98 06:30:19 am" To: mohta@necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 23 Jun 1998 11:41:57 +0200 (MET DST) Cc: deering@cisco.com, mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com, iesg@ietf.org X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masataka Ohta wrote: > > When the minimum MTU is sufficiently large, PMTUD is totally > unnecessary. Any "sufficiently large" value of the minimum MTU will be 2^32 bytes (for the payload) + an indefinite amount of bytes for the headers, with IPv6. I don't think this is useful as an enforce minimum MTU. -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 Tue Jun 23 04:05:34 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id EAA17085 for ipng-dist; Tue, 23 Jun 1998 04:01:46 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id EAA17078 for ; Tue, 23 Jun 1998 04:01:37 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA19850 for ; Tue, 23 Jun 1998 04:01:35 -0700 Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id EAA08546 for ; Tue, 23 Jun 1998 04:01:13 -0700 (PDT) Received: from relay3.server.ibm.com (relay3.server.ibm.com [9.14.2.100]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id GAA27220 for ; Tue, 23 Jun 1998 06:51:28 -0400 Received: from d12lmsrelay.emea.ibm.com (d12lmsrelay.emea.ibm.com [9.165.215.20]) by relay3.server.ibm.com (8.8.7/8.8.7) with ESMTP id GAA18172 for ; Tue, 23 Jun 1998 06:55:37 -0400 Received: from DE.IBM.COM (d12lms01.emea.ibm.com [9.165.215.18]) by d12lmsrelay.emea.ibm.com (8.8.7/8.8.7) with SMTP id LAA29610 for ; Tue, 23 Jun 1998 11:03:07 GMT Received: by DE.IBM.COM (Soft-Switch LMS 2.1.0.0) with snapi via D12AU001 id 5120010011262188; Tue, 23 Jun 1998 10:57:34 +0000 From: Alexander Schmid To: Subject: (IPng 5904) Guidelines for designing IPv4 networks to mitigate a future Message-ID: <5120010011262188000002L182*@MHS> Date: Tue, 23 Jun 1998 10:57:34 +0000 MIME-Version: 1.0 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 EAA17079 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am designing a large IPv6-based network (more than 100.000 Users). Where can I find guidelines (concerning IP-addresses) I should follow to make a future IPv6 migration easier thanks a lot, Alexander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 04:21:57 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id EAA17107 for ipng-dist; Tue, 23 Jun 1998 04:15:31 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id EAA17100 for ; Tue, 23 Jun 1998 04:15:09 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA21147 for ; Tue, 23 Jun 1998 04:15:08 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id EAA13044 for ; Tue, 23 Jun 1998 04:15:04 -0700 (PDT) From: Masataka Ohta Message-Id: <199806231101.UAA05820@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA05820; Tue, 23 Jun 1998 20:01:09 +0900 Subject: (IPng 5905) Re: Last Call: Internet Protocol, Version 6 To: ignatios@theory.cs.uni-bonn.de (Ignatios Souvatzis) Date: Tue, 23 Jun 98 20:01:08 JST Cc: mohta@necom830.hpcl.titech.ac.jp, deering@cisco.com, ipng@sunroof.eng.sun.com, iesg@ietf.org In-Reply-To: <199806230941.LAA12841@cauchy.cs.uni-bonn.de>; from "Ignatios Souvatzis" at Jun 23, 98 11:41 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > When the minimum MTU is sufficiently large, PMTUD is totally > > unnecessary. > > Any "sufficiently large" value of the minimum MTU will be 2^32 bytes (for > the payload) + an indefinite amount of bytes for the headers, with IPv6. For you, maybe. So, you are against the current IPv6 specification and disagree to promote it DS. OK. However, the problem of your proposal is that your IPv6 won't run over Ethernet nor ATM, which support MTU of mere 1,500 or 64K bytes. For most of us practical engineers, "suffenciently large" minimum MTU means: 1) normal header size is negligiblly small compared to the packet size 2) header processing time is negligiblly small compared to packet transfer delay 3) reasonable amount of data can be sent within each fragment. As you might know, some thought that 64 bytes payload with 5 bytes satisfies the condition when ATM was being developped, which was wrong. But, 40 bytes of header is negligible compared to the 1280 bytes of packet size, Header processing time is negligible even at 10 or 20 Gbps, which is a speed of WDM. The only thing to do is to make maximum header size well less than 1280 bytes to let fragments carry reasonable amount of data. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 04:52:31 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id EAA17223 for ipng-dist; Tue, 23 Jun 1998 04:47:37 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with ESMTP id EAA17216 for ; Tue, 23 Jun 1998 04:47:26 -0700 (PDT) Received: from lillen (storac11.Sweden.Sun.COM [129.159.137.39]) by jurassic.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id EAA22919; Tue, 23 Jun 1998 04:47:19 -0700 (PDT) Date: Tue, 23 Jun 1998 04:47:12 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5906) Re: IPV6_ADDRFORM To: Craig Metz Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199806221812.SAA05780@inner.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > A co-worker's recent question showed that I missed the removal of > IPV6_ADDRFORM option from the Basic API as of the November, 1997 draft. I > hate to re-open a past discussion, but, as someone who uses this option > operationally every day, I believe that the AF_INET6 IPv4-mapped socket > downgrade function is required for a graceful transition to IPv6. I don't think it is required and the details of the semantics and implementation are difficult since there could be datagrams (UDP) or connections (TCP) that have already been queued (or are getting queued) on the socket when you change the addrform. In order for addrform to be useful the API would have to require that all queued as well as all future (including concurrent with the changing of addrform) datagrams/connections get the new addrform. If this is not required then your application might see race conditions where AF_INET6 addresses show up after switching to AF_INET. > For example, I have two FTP daemons on my system. My inetd equivalent > listens on an AF_INET6 socket. If the incoming connection is IPv4-mapped, it > downgrades the socket and fires of the OPIE ftp daemon, which doesn't support > IPv6 (and isn't going to for a while because I have too much other work to > do). If the incoming connection isn't IPv4-mapped, it fires off the > inet6-apps ftp daemon, which does support IPv6, but doesn't support OTP. This can be done more simply by having inetd have one AF_INET and one AF_INET6 socket for the ftp service. Then the kernel gets to do the work of selecting the proper socket and inetd doesn't need to do anything special. BTW: Does your current solution work with all combinations of UDP/TCP and wait/nowait servers? > Would anyone object to the re-introduction of this setsockopt() (possibly > with more restrictions on it, so it only does the easy AF_INET6 IPv4-mapped > <-> AF_INET transitions), possibly in the Advanced API? Yes, I'd object. 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 Jun 23 05:09:07 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id FAA17263 for ipng-dist; Tue, 23 Jun 1998 05:05:55 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id FAA17256 for ; Tue, 23 Jun 1998 05:05:46 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA24177 for ; Tue, 23 Jun 1998 05:05:45 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.8.8/8.8.8) with SMTP id FAA25129 for ; Tue, 23 Jun 1998 05:02:48 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id LA18086; Tue, 23 Jun 1998 21:56:38 +1000 (from kre@munnari.OZ.AU) To: Masataka Ohta Cc: ignatios@theory.cs.uni-bonn.de (Ignatios Souvatzis), deering@cisco.com, ipng@sunroof.eng.sun.com, iesg@ietf.org Subject: (IPng 5907) Re: Last Call: Internet Protocol, Version 6 In-Reply-To: Masataka Ohta's message of "Tue, 23 Jun 1998 20:01:08 +0200." References: <199806231101.UAA05820@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Jun 1998 21:56:32 +1000 Message-Id: <3464.898602992@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 23 Jun 98 20:01:08 JST From: Masataka Ohta Message-ID: <199806231101.UAA05820@necom830.hpcl.titech.ac.jp> | The only thing to do is to make maximum header size well | less than 1280 bytes to let fragments carry reasonable amount | of data. If this was needed at all, it should not be an IPv6 limit, but a limit imposed by the various transport protocols, so that they can transport however much data makes sense to them (TCP, UDP, and others, might all choose different limits). There is no need for IPv6 itself to set any such limit - it is easy to imagine (though perhaps a little frightening) someone designing a protocol where all of the real send user data is carried in a destination option - if you limit the header size then you would be restricting the available payload space for that protocol, whereas your aim is clearly to allow as much for that as possible. I think the error is in assuming that TCP (UDP etc) data is in some sense different from other IPv6 "headers". True, those things have to come last, as they have no "next header" field, but that should be the only difference visible. (The lack of a next header field for those old headers was part of what I was trying to overcome with the payload header, sadly now just a relic). That is, all protocol headers, be they Routing, Fragmentation, or TCP, should be considered alike - they're all headers. Limit the "header" space and you are imposing a maximum datagram size. Let's just leave this alone. 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 Jun 23 05:45:25 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id FAA17380 for ipng-dist; Tue, 23 Jun 1998 05:41:17 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id FAA17373 for ; Tue, 23 Jun 1998 05:41:07 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA27013 for ; Tue, 23 Jun 1998 05:41:05 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id FAA06473 for ; Tue, 23 Jun 1998 05:40:43 -0700 (PDT) From: Masataka Ohta Message-Id: <199806231227.VAA06059@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA06059; Tue, 23 Jun 1998 21:27:29 +0900 Subject: (IPng 5908) Re: Last Call: Internet Protocol, Version 6 To: kre@munnari.OZ.AU (Robert Elz) Date: Tue, 23 Jun 98 21:27:28 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ignatios@theory.cs.uni-bonn.de, deering@cisco.com, ipng@sunroof.eng.sun.com, iesg@ietf.org In-Reply-To: <3464.898602992@munnari.OZ.AU>; from "Robert Elz" at Jun 23, 98 9:56 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kre; > | The only thing to do is to make maximum header size well > | less than 1280 bytes to let fragments carry reasonable amount > | of data. > > If this was needed at all, it should not be an IPv6 limit, but a limit > imposed by the various transport protocols, so that they can transport > however much data makes sense to them (TCP, UDP, and others, might all > choose different limits). Not. RSVP, for example, may carry as many data of its own as it want. However, there should be some transport layer protocol which offer reasonably large payload. The point is that applications can choose its transport protocol. > There is no need for IPv6 itself to set any such limit - There is, because applications can have no selection at the internetworking layer. > it is easy to > imagine (though perhaps a little frightening) someone designing a protocol > where all of the real send user data is carried in a destination option - if > you limit the header size then you would be restricting the available payload > space for that protocol, whereas your aim is clearly to allow as much for > that as possible. So? Isn't it good to not to allow to do the same thing in several different ways? Destination options should be used only when the options are generic enough to be useful with various transport or application protocol, shouldn't it? > I think the error is in assuming that TCP (UDP etc) data is in some sense > different from other IPv6 "headers". > That is, all protocol headers, be they Routing, Fragmentation, or TCP, should Transport and internetworking layer headers are, of course, different. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 05:46:53 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id FAA17393 for ipng-dist; Tue, 23 Jun 1998 05:44:50 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id FAA17386 for ; Tue, 23 Jun 1998 05:44:39 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA27280 for ; Tue, 23 Jun 1998 05:44:38 -0700 Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.161]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id FAA07725 for ; Tue, 23 Jun 1998 05:44:34 -0700 (PDT) Received: from cauchy.cs.uni-bonn.de (cauchy.cs.uni-bonn.de [131.220.4.169]) by theory.cs.uni-bonn.de (8.8.8/8.8.8) with ESMTP id OAA02269; Tue, 23 Jun 1998 14:44:21 +0200 (MET DST) From: Ignatios Souvatzis Received: (ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.6.9) id OAA13183; Tue, 23 Jun 1998 14:44:18 +0200 (MET DST) Message-Id: <199806231244.OAA13183@cauchy.cs.uni-bonn.de> Subject: (IPng 5909) Re: Last Call: Internet Protocol, Version 6 In-Reply-To: <199806231101.UAA05820@necom830.hpcl.titech.ac.jp> from Masataka Ohta at "Jun 23, 98 08:01:08 pm" To: ipng@sunroof.eng.sun.com, iesg@ietf.org Date: Tue, 23 Jun 1998 14:44:16 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masataka Ohta writes: > > > When the minimum MTU is sufficiently large, PMTUD is totally > > > unnecessary. I replied that "sufficiently large" in this context is 2^32 + header. Masataka Ohta replies to this: > > For you, maybe. So, you are against the current IPv6 specification and > disagree to promote it DS. OK. > > However, the problem of your proposal is that your IPv6 won't run > over Ethernet nor ATM, which support MTU of mere 1,500 or 64K bytes. I don't propose that. I understood that you proposed that. I just wanted to point out that maximum IPv6 packets is over 2^32 bytes, and that it is impractical to run without PMTUD (well, or fragmentation). 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 Tue Jun 23 05:59:39 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id FAA17422 for ipng-dist; Tue, 23 Jun 1998 05:56:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id FAA17415 for ; Tue, 23 Jun 1998 05:56:17 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA28361; Tue, 23 Jun 1998 05:56:15 -0700 Received: from inner.net (avarice.inner.net [198.82.204.99]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id FAA11275; Tue, 23 Jun 1998 05:56:13 -0700 (PDT) Received: from inner.net (stan.ipv6.nrl.navy.mil [132.250.90.8]) by inner.net (8.9.0/8.8.5) with ESMTP id MAA07088; Tue, 23 Jun 1998 12:51:17 GMT Message-Id: <199806231251.MAA07088@inner.net> To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: (IPng 5910) Re: IPV6_ADDRFORM In-reply-to: Your message of "Tue, 23 Jun 1998 04:47:12 PDT." X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Tue, 23 Jun 1998 08:55:30 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , you write: >I don't think it is required and the details of the semantics >and implementation are difficult since there could be datagrams (UDP) >or connections (TCP) that have already been queued (or are getting queued) >on the socket when you change the addrform. In order for addrform to >be useful the API would have to require that all queued as well as >all future (including concurrent with the changing of addrform) >datagrams/connections get the new addrform. If this is not required >then your application might see race conditions where AF_INET6 addresses >show up after switching to AF_INET. These are implementation problems; they're not hard to solve on BSD and Linux. On BSD, it should be a splnet(), twiddle socket and PCB, walk the socket receiver buffer and twiddle the addresses, splx(). >This can be done more simply by having inetd have one AF_INET and one >AF_INET6 socket for the ftp service. Then the kernel gets to do the work >of selecting the proper socket and inetd doesn't need to do anything special. This depends on a specific behavior of bind() that does not appear to be required by the API spec. >BTW: Does your current solution work with all combinations of UDP/TCP >and wait/nowait servers? We don't implement queue conversion. We're too close to our next release for me to get it in there, but I'll get this implemented in the release after that. Where I (and the users I know of) use it is for downgrading AF_INET6 IPv4-mapped TCP child sockets to AF_INET. This is a much simpler case than the general case. I would not object to a constrained version of ADDRFORM that is only guaranteed to work in this case. >> Would anyone object to the re-introduction of this setsockopt() (possibly >> with more restrictions on it, so it only does the easy AF_INET6 IPv4-mapped >> <-> AF_INET transitions), possibly in the Advanced API? > >Yes, I'd object. Well, then I guess this will be useful feature that some implementations won't have. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 06:50:21 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id GAA17536 for ipng-dist; Tue, 23 Jun 1998 06:43:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id GAA17529 for ; Tue, 23 Jun 1998 06:43:34 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA04346 for ; Tue, 23 Jun 1998 06:43:26 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.8.8/8.8.8) with SMTP id GAA01732 for ; Tue, 23 Jun 1998 06:43:23 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id NA31542; Tue, 23 Jun 1998 23:42:25 +1000 (from kre@munnari.OZ.AU) To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5911) Re: Last Call: Internet Protocol, Version 6 In-Reply-To: Masataka Ohta's message of "Tue, 23 Jun 1998 21:27:28 +0200." References: <199806231227.VAA06059@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Jun 1998 23:42:23 +1000 Message-Id: <3958.898609343@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 23 Jun 98 21:27:28 JST From: Masataka Ohta Message-ID: <199806231227.VAA06059@necom830.hpcl.titech.ac.jp> | However, there should be some transport layer protocol which | offer reasonably large payload. Sure, and if a transport protocol wants to do that, it can, and it can require that the IP layer make available that much (not fill the MTU with other data). But if some other transport protocol doesn't need so much, why should the extra space be not available for headers? Eg: consider that someday we may re-invent the record route header, or something like it. Any packet can use it. If I want to record the route to X and back, I build a packet with this (currently non-existent) record route header, as big as possible, and a source route header, so the packet will go to X, then come back to me. If you limit the header size to some arbitrary amount, then you are limiting the usefulness of that, as space available for the recorded routes would be arbitrarily limited, with no rational reason at all (the actual packet sent would likely have no transport headers at all, not even ICMP). Basically what you are saying is that every packet must be able to carry N octets of transport data, whether it has a need for that or not. That makes no sense as an IPv6 wide limit. If TCP wants to say "The IP layer must provide me with at least 500 bytes of space per packet", let it do so, but that's a TCP issue, not an IPv6 issue. | There is, because applications can have no selection at the | internetworking layer. Of course they can. Even in IPv4 applications routinely set IPv4 type options (not many applications perhaps, but they do exist). But even if that were true, the transport layer clearly has control over the internet layer, it decides what it wants. If the IP layer isn't providing what is needed - is shoving in too much overhead and not allowing enough space for the transport to do its thing (or even to do it efficiently) then the IP layer should be scrapped, and a better implementation provided. Note, the IPv6 protocol requires no such nonsense - it can only be an implementation of it which would be defective. | Destination options should be used only when the options are generic | enough to be useful with various transport or application protocol, | shouldn't it? They're just data sent from one system to another. As long as there is agreement as to what the data means, I see no reason to constrain things. | Transport and internetworking layer headers are, of course, different. Nonsense. If you really want to believe in the OSIRM, then you can treat the data carried at the transport level as different from the internet level data, but the headers? There is no logical reason at all not to have IP headers, TCP header, more IP headers, UCP header, more IP headers, ICMP header, TCP header, TCP header, more IP headers, ... all in one IP datagram. We can't do that today, because there is no way to say what comes after the TCP header, nor how long the associated data is, but if we were redesigning its header now, to fit the IPv6 scheme, there would certainly be "next header" and "length" fields in the header. 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 Jun 23 06:51:09 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id GAA17545 for ipng-dist; Tue, 23 Jun 1998 06:47:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id GAA17538 for ; Tue, 23 Jun 1998 06:46:49 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA05070 for ; Tue, 23 Jun 1998 06:46:47 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA03640 for ; Tue, 23 Jun 1998 06:46:46 -0700 (PDT) From: Masataka Ohta Message-Id: <199806231337.WAA07216@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id WAA07216; Tue, 23 Jun 1998 22:37:13 +0900 Subject: (IPng 5912) Re: Last Call: Internet Protocol, Version 6 To: ignatios@theory.cs.uni-bonn.de (Ignatios Souvatzis) Date: Tue, 23 Jun 98 22:37:12 JST Cc: ipng@sunroof.eng.sun.com, iesg@ietf.org In-Reply-To: <199806231244.OAA13183@cauchy.cs.uni-bonn.de>; from "Ignatios Souvatzis" at Jun 23, 98 2:44 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IS; > > > > When the minimum MTU is sufficiently large, PMTUD is totally > > > > unnecessary. > > I replied that "sufficiently large" in this context is 2^32 + header. Sufficiently large minimum MTU. OK? Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 07:20:03 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id HAA17608 for ipng-dist; Tue, 23 Jun 1998 07:16:06 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id HAA17601 for ; Tue, 23 Jun 1998 07:15:51 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA09759 for ; Tue, 23 Jun 1998 07:15:49 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id HAA18216 for ; Tue, 23 Jun 1998 07:15:50 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA05930; Tue, 23 Jun 1998 09:15:39 -0500 Message-Id: <199806231415.JAA05930@gungnir.fnal.gov> To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5913) Re: Last Call: Internet Protocol, Version 6 In-reply-to: Your message of Tue, 23 Jun 1998 22:37:12 +0200. <199806231337.WAA07216@necom830.hpcl.titech.ac.jp> Date: Tue, 23 Jun 1998 09:15:39 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > When the minimum MTU is sufficiently large, PMTUD is totally > > > > unnecessary. > > I replied that "sufficiently large" in this context is 2^32 + header. > > Sufficiently large minimum MTU. OK? No, not OK. To make PMTUD "totally unnecessary" (your words), every link must be able to carry the largest legal packet. Today the largest legal packet is 2^32 - 1 + 40. If you want to do away with PMTU discovery you must revoke that limit and impose a smaller one on IPv6, and/or require that every link be able to carry a larger packet without IP fragmentation. Lots of luck. In another zany message you say: > For most of us practical engineers, "suffenciently large" minimum > MTU means: Nope, you can't have it both ways. Either you are arguing a theoretical point which might never arise in a properly designed system, or you are arguing about a practical consideration. Please choose or be silent. > The only thing to do is to make maximum header size well > less than 1280 bytes to let fragments carry reasonable amount > of data. KRE answered you fully and completely. I would only add that the lower layers of an implementation do have means to inform the upper layer when an "atomic" data transmission is too large to be carried as a unit for whatever reason. I request that you to drop the subject instantly. Thank you in advance. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 09:00:30 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id IAA17684 for ipng-dist; Tue, 23 Jun 1998 08:55:08 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id IAA17677 for ; Tue, 23 Jun 1998 08:54:59 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA29786 for ; Tue, 23 Jun 1998 08:54:53 -0700 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA13949 for ; Tue, 23 Jun 1998 08:54:52 -0700 (PDT) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id LAA27838; Tue, 23 Jun 1998 11:54:11 -0400 (EDT) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id LAA18329; Tue, 23 Jun 1998 11:54:05 -0400 (EDT) Date: Tue, 23 Jun 1998 11:54:05 -0400 (EDT) From: Christian Huitema Message-Id: <980623115405.ZM18327@seawind.bellcore.com> In-Reply-To: Masataka Ohta "(IPng 5912) Re: Last Call: Internet Protocol, Version 6" (Jun 23, 10:37pm) References: <199806231337.WAA07216@necom830.hpcl.titech.ac.jp> X-Mailer: Z-Mail (5.0.0 30July97) To: Masataka Ohta , ignatios@theory.cs.uni-bonn.de (Ignatios Souvatzis) Subject: (IPng 5914) Re: Last Call: Internet Protocol, Version 6 Cc: ipng@sunroof.eng.sun.com, iesg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masataka has a point. If you take the example of a binary file transfer, even throwing in IPSEC, TCP headers and TCP ACK, an MTU of 1280 bytes results in approximately 91% efficiency, while a PMTU of 1500 bytes results in 92% efficiency. (Efficiency being the number of total bytes sent on the network versus the number of bytes in the file.) So, if you are in a mostly Ethernet environment, there is not a great incentive to properly implement PMTU discovery. The situation changes if the station can send large frames, of say 4K. In that case, the efficiency raises to 97%, and, maybe more important, the number of packets is divided by three, which reduce the number of interrupts, software cycles, etc. In short, if the guaranteed MTU is large enough, implementers wont bother with PMTU discovery. Large enough depends on the application: * The DNS today uses an "MTU" of 512 octets, but that is probably not large enough anymore, with the advent of DNSSEC. * A typical audio packet is no more than 80 bytes, but a video application could easily 4K, and in some cases 64K. * The median web page size, in my cache, is about 2K. The average is about 4K, and about 40% would fit in a single 1280 byte packet. But the real question is, is this important? The working group actually debated it, and came to the conclusion that, no, raising the limit would not dramatically harm any of the popular underlying networks. The key argument were multicast and DNS. We don't really know how to do a multicast PMTU discovery, and we certainly don't know how to embed PMTU discovery within a single round trip delay. So, on balance, raising the minimum MTU to 1280 helps, and only hurts those who are lazy enough to settle for 91% efficiency when they could get 92%. -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 10:26:21 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id KAA18037 for ipng-dist; Tue, 23 Jun 1998 10:20:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id KAA18030 for ; Tue, 23 Jun 1998 10:20:18 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA24047 for ; Tue, 23 Jun 1998 10:20:16 -0700 Received: from imo25.mx.aol.com (imo25.mx.aol.com [198.81.17.69]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA08103 for ; Tue, 23 Jun 1998 10:20:13 -0700 (PDT) Received: from Telford001@aol.com by imo25.mx.aol.com (IMOv14_b1.1) id DZJDa07259; Tue, 23 Jun 1998 13:18:47 -0400 (EDT) Message-ID: Date: Tue, 23 Jun 1998 13:18:47 EDT To: crawdad@fnal.gov, mohta@necom830.hpcl.titech.ac.jp Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 5915) Re: Last Call: Internet Protocol, Version 6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 62 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 98-06-23 10:31:07 EDT, crawdad@fnal.gov writes: > KRE answered you fully and completely. I would only add that the > lower layers of an implementation do have means to inform the upper > layer when an "atomic" data transmission is too large to be carried > as a unit for whatever reason. I request that you to drop the > subject instantly. Thank you in advance. Just out of curiosity, would not the ability of the lower layers of an implementation to inform the upper layers when an "atomic" data transmission is too large to be carried as a unit depend on performing path MTU discovery before each packet transmission? Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 23 10:32:46 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id KAA18107 for ipng-dist; Tue, 23 Jun 1998 10:28:11 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id KAA18100 for ; Tue, 23 Jun 1998 10:27:53 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA26095 for ; Tue, 23 Jun 1998 10:27:50 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id KAA12884 for ; Tue, 23 Jun 1998 10:27:49 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id MAA06670; Tue, 23 Jun 1998 12:27:47 -0500 Message-Id: <199806231727.MAA06670@gungnir.fnal.gov> To: Telford001@aol.com Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5916) Re: Last Call: Internet Protocol, Version 6 In-reply-to: Your message of Tue, 23 Jun 1998 13:18:47 EDT. Date: Tue, 23 Jun 1998 12:27:47 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Just out of curiosity, would not the ability of the lower layers > of an implementation to inform the upper layers when > an "atomic" data transmission is too large to be carried as > a unit depend on performing path MTU discovery before > each packet transmission? > Joachim Martillo Just out of momentary tolerance, "No." -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 12:10:02 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id MAA18270 for ipng-dist; Tue, 23 Jun 1998 12:05:43 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id MAA18263 for ; Tue, 23 Jun 1998 12:05:34 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA25964 for ; Tue, 23 Jun 1998 12:05:33 -0700 Received: from imo25.mx.aol.com (imo25.mx.aol.com [198.81.17.69]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA14336 for ; Tue, 23 Jun 1998 12:05:33 -0700 (PDT) Received: from Telford001@aol.com by imo25.mx.aol.com (IMOv14_b1.1) id DCXWa03745; Tue, 23 Jun 1998 15:04:55 -0400 (EDT) Message-ID: <4809d1a2.358ffc58@aol.com> Date: Tue, 23 Jun 1998 15:04:55 EDT To: crawdad@fnal.gov Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 5917) Re: Last Call: Internet Protocol, Version 6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 62 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 98-06-23 13:43:54 EDT, crawdad@fnal.gov writes: > > Just out of curiosity, would not the ability of the lower layers > > of an implementation to inform the upper layers when > > an "atomic" data transmission is too large to be carried as > > a unit depend on performing path MTU discovery before > > each packet transmission? > > Joachim Martillo > Just out of momentary tolerance, "No." Then, I must ask. As there is no guarantee that succeeding packets follow the same path, how is the validity of the MTU previously discovered guaranteed? Are the upper layers supposed to depend on subsequent notification from the network that the MTU has changed -- a notification that itself may no longer be valid by the time the upper layers process the notification? Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 23 13:01:40 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id MAA18365 for ipng-dist; Tue, 23 Jun 1998 12:55:23 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id MAA18358 for ; Tue, 23 Jun 1998 12:55:15 -0700 (PDT) From: akephart@austin.ibm.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA06926 for ; Tue, 23 Jun 1998 12:55:06 -0700 Received: from ausmail.austin.ibm.com (ausmail.austin.ibm.com [192.35.232.19]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA11364 for ; Tue, 23 Jun 1998 12:54:58 -0700 (PDT) Received: from netmail1.austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96]) by ausmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id OAA14090; Tue, 23 Jun 1998 14:54:55 -0500 Received: from aguila.austin.ibm.com (aguila.austin.ibm.com [9.53.150.192]) by netmail1.austin.ibm.com (8.8.5/8.8.5) with ESMTP id OAA109186; Tue, 23 Jun 1998 14:54:55 -0500 Received: (from akephart@localhost) by aguila.austin.ibm.com (AIX4.3/UCB 8.7/8.7-client1.01) id OAA27496; Tue, 23 Jun 1998 14:54:54 -0500 (CDT) Message-Id: <199806231954.OAA27496@aguila.austin.ibm.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Telford001@aol.com cc: ipng@sunroof.eng.sun.com Reply-To: akephart@austin.ibm.com Subject: (IPng 5918) Re: Last Call: Internet Protocol, Version 6 In-reply-to: (Your message of Tue, 23 Jun 98 15:04:55 -0500.)<4809d1a2.358ffc58@aol.com> Date: Tue, 23 Jun 98 14:54:54 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In a message dated 98-06-23 13:43:54 EDT, crawdad@fnal.gov writes: > > > > Just out of curiosity, would not the ability of the lower layers > > > of an implementation to inform the upper layers when > > > an "atomic" data transmission is too large to be carried as > > > a unit depend on performing path MTU discovery before > > > each packet transmission? > > > Joachim Martillo > > > Just out of momentary tolerance, "No." > > Then, I must ask. As there is no guarantee that > succeeding packets follow the same path, how > is the validity of the MTU previously discovered > guaranteed? Are the upper layers supposed to > depend on subsequent notification from the > network that the MTU has changed -- a notification > that itself may no longer be valid by the time the > upper layers process the notification? Is this an argument for a defined, limited header size or an argument against the general utility of PMTU? With path changes, no PMTU is "guaranteed" to be valid for any packet. Even if PMTU is completely useless, it is fairly easy to envision a link with a large (e.g. 64K) mtu, and header requirements greater than some arbitrary value (e.g. 1280). Maybe I'm just an implementor, but I thought the whole purpose of the IPng header layout was for extensibility. It seems quite contrary to the spirit of the design to start applying arbitrary limits at this point. In any case, what would be your hard limit? 1279? 512? 1280-n? (Where n is the largest minimum payload requirement for all reasonable transport protocols?) How would you begin to calculate n? -andrew > > Joachim Martillo > Telford Tools, Inc. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- +---------------------------------------------------------------------------+ | Andrew Kephart, AIX TCP/IP These are my opinions only...IBM might | | SMTP: akephart@austin.ibm.com agree, but I wouldn't count on it. | +---------------------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 23 18:31:13 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id SAA18814 for ipng-dist; Tue, 23 Jun 1998 18:28:17 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id SAA18807 for ; Tue, 23 Jun 1998 18:28:09 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA29596 for ; Tue, 23 Jun 1998 18:28:10 -0700 Received: from imo28.mx.aol.com (imo28.mx.aol.com [198.81.17.72]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id SAA03820 for ; Tue, 23 Jun 1998 18:28:10 -0700 (PDT) Received: from Telford001@aol.com by imo28.mx.aol.com (IMOv14_b1.1) id NPDNa17154; Tue, 23 Jun 1998 21:27:27 +2000 (EDT) Message-ID: Date: Tue, 23 Jun 1998 21:27:27 EDT To: akephart@austin.ibm.com Cc: ipng@sunroof.eng.sun.com, Telford001@aol.com Mime-Version: 1.0 Subject: (IPng 5919) Re: Last Call: Internet Protocol, Version 6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 62 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 98-06-23 15:54:58 EDT, akephart@austin.ibm.com writes: > Is this an argument for a defined, limited header size or an > argument against the general utility of PMTU? With path changes, no > PMTU is "guaranteed" to be valid for any packet. I agree, and the problem is serious, for routing protocols have been standardized like OSPF continuously introduce path changes. > Even if PMTU is completely useless, it is fairly easy to > envision a link with a large (e.g. 64K) mtu, and header requirements > greater than some arbitrary value (e.g. 1280). And if for some reason the path traverses a link where MTU is 1280? > Maybe I'm just an implementor, but I thought the whole purpose > of the IPng header layout was for extensibility. It seems quite contrary to > the spirit of the design to start applying arbitrary limits at this > point. In any case, what would be your hard limit? 1279? 512? 1280-n? > (Where n is the largest minimum payload requirement for all reasonable > transport protocols?) How would you begin to calculate n? Perhaps, a concrete description of the problem is worthwhile. Telford Tools occasionally does work a DEC/Compaq location that has a lot of 100 Mbps ethernet and a lot of FDDI. The MTU size on the ethernet is ~1500 while on FDDI the MTU size is ~4K. I believe the installation uses Cisco routers configured for RIP routing with load sharing between equal cost paths. Path MTU between two hosts will sometimes be ~1500 and will sometimes be ~4K. In the case of IPv4, the headers are always less than 1500 and the routers carry out fragmentation during those periods when large packets are traversing an ethernet. In the case of IPv6, fragmentation would take place at the host, and headers could not be larger than 1500 (actually some space would have to be left for payload). If the situation is not abnormal, I think we could expect that IPv6 packets would tend to get transmitted with sizes of 1280 or less and would have to leave space for payload. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 23 22:46:17 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id WAA19061 for ipng-dist; Tue, 23 Jun 1998 22:42:43 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id WAA19054 for ; Tue, 23 Jun 1998 22:42:35 -0700 (PDT) From: MOSTHAVM@plcman.siemens.co.uk Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA29405 for ; Tue, 23 Jun 1998 22:42:36 -0700 Received: from ariane.sni.co.uk ([194.42.250.68]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id WAA23711 for ; Tue, 23 Jun 1998 22:42:31 -0700 (PDT) Received: from manpost001.sni.co.uk (manpost001.sni.co.uk [137.223.63.12]) by ariane.sni.co.uk (8.8.8/8.8.7) with ESMTP id GAA16690 for ; Wed, 24 Jun 1998 06:41:40 +0100 (BST) Received: by manpost001.sni.co.uk with Internet Mail Service (5.0.1460.8) id ; Wed, 24 Jun 1998 06:46:08 +0100 Message-ID: To: ipng@sunroof.eng.sun.com Subject: (IPng 5920) Re: Last Call: Internet Protocol, Version 6 Date: Wed, 24 Jun 1998 06:46:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree, that the packet could encounter a MTU that is too small to actually carry the header. The solution to this is fairly easy though. The router that discovers the problem has to send an ICMP Packet Too Big message. As this message must be past to upper layers it becomes an implementation issue. Marc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 23:50:22 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id XAA19107 for ipng-dist; Tue, 23 Jun 1998 23:46:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id XAA19100 for ; Tue, 23 Jun 1998 23:45:50 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA04981 for ; Tue, 23 Jun 1998 23:45:51 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id XAA09205 for ; Tue, 23 Jun 1998 23:34:26 -0700 (PDT) From: Masataka Ohta Message-Id: <199806240620.PAA08461@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA08461; Wed, 24 Jun 1998 15:20:18 +0900 Subject: (IPng 5921) Re: Last Call: Internet Protocol, Version 6 To: crawdad@fnal.gov (Matt Crawford) Date: Wed, 24 Jun 98 15:20:17 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <199806231415.JAA05930@gungnir.fnal.gov>; from "Matt Crawford" at Jun 23, 98 9:15 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt; > as a unit for whatever reason. I request that you to drop the > subject instantly. Thank you in advance. I thank you for your polite attitude. Good by. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 24 00:33:22 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id AAA19165 for ipng-dist; Wed, 24 Jun 1998 00:30:02 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id AAA19158 for ; Wed, 24 Jun 1998 00:29:46 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id AAA09312 for ; Wed, 24 Jun 1998 00:29:47 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id AAA25440 for ; Wed, 24 Jun 1998 00:28:04 -0700 (PDT) From: Masataka Ohta Message-Id: <199806240716.QAA08600@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA08600; Wed, 24 Jun 1998 16:16:22 +0900 Subject: (IPng 5922) Re: Last Call: Internet Protocol, Version 6 To: huitema@bellcore.com (Christian Huitema) Date: Wed, 24 Jun 98 16:16:22 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ignatios@theory.cs.uni-bonn.de, ipng@sunroof.eng.sun.com, iesg@ietf.org In-Reply-To: <980623115405.ZM18327@seawind.bellcore.com>; from "Christian Huitema" at Jun 23, 98 11:54 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian; > In short, if the guaranteed MTU is large enough, implementers wont bother > with PMTU discovery. Large enough depends on the application: For header processing overhead, it rather depends on chip speed. Network engineers may tend to think that the network speed increases while chip speed stays the same. The proper argument is that the application speed stays the same while the chip speed exponentially increases. Today, it is already obvious that 1280 bytes of minimum MTU is large enough for video applications, even if it is unicast ones. Well, it must have been large enough to make multicast applications work. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 24 01:21:15 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id BAA19214 for ipng-dist; Wed, 24 Jun 1998 01:17:14 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id BAA19207 for ; Wed, 24 Jun 1998 01:17:03 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA13685 for ; Wed, 24 Jun 1998 01:17:02 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id BAA08319 for ; Wed, 24 Jun 1998 01:15:04 -0700 (PDT) From: Masataka Ohta Message-Id: <199806240804.RAA08885@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA08885; Wed, 24 Jun 1998 17:04:39 +0900 Subject: (IPng 5923) Re: Last Call: Internet Protocol, Version 6 To: Telford001@aol.com Date: Wed, 24 Jun 98 17:04:38 JST Cc: akephart@austin.ibm.com, ipng@sunroof.eng.sun.com In-Reply-To: ; from "Telford001@aol.com" at Jun 23, 98 9:27 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Joachim; > > Even if PMTU is completely useless, it is fairly easy to > > envision a link with a large (e.g. 64K) mtu, and header requirements > > greater than some arbitrary value (e.g. 1280). > > And if for some reason the path traverses a link where MTU is > 1280? Good point. When the header requirement is greater than 1280, all the possible links between two hosts must have LARGE MTU values and can not be a generic Internet. In such a case, PMTUD is unnecessary. In general, there can not be a large header requirement. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 24 08:18:41 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id IAA19616 for ipng-dist; Wed, 24 Jun 1998 08:13:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id IAA19609 for ; Wed, 24 Jun 1998 08:13:43 -0700 (PDT) From: akephart@austin.ibm.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA26030 for ; Wed, 24 Jun 1998 08:13:42 -0700 Received: from ausmail.austin.ibm.com (ausmail.austin.ibm.com [192.35.232.19]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA18325 for ; Wed, 24 Jun 1998 08:13:42 -0700 (PDT) Received: from netmail1.austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96]) by ausmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id KAA45068; Wed, 24 Jun 1998 10:13:39 -0500 Received: from aguila.austin.ibm.com (aguila.austin.ibm.com [9.53.150.192]) by netmail1.austin.ibm.com (8.8.5/8.8.5) with ESMTP id KAA52892; Wed, 24 Jun 1998 10:13:38 -0500 Received: (from akephart@localhost) by aguila.austin.ibm.com (AIX4.3/UCB 8.7/8.7-client1.01) id KAA33660; Wed, 24 Jun 1998 10:13:38 -0500 (CDT) Message-Id: <199806241513.KAA33660@aguila.austin.ibm.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Telford001@aol.com cc: ipng@sunroof.eng.sun.com Reply-To: akephart@austin.ibm.com Subject: (IPng 5925) Re: Last Call: Internet Protocol, Version 6 In-reply-to: (Your message of Tue, 23 Jun 98 21:27:27 -0500.) Date: Wed, 24 Jun 98 10:13:37 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From <(IPng 5919) Re: Last Call: Internet Protocol, Version 6>: > In a message dated 98-06-23 15:54:58 EDT, akephart@austin.ibm.com writes: > [some deleted] > > Even if PMTU is completely useless, it is fairly easy to > > envision a link with a large (e.g. 64K) mtu, and header requirements > > greater than some arbitrary value (e.g. 1280). > > And if for some reason the path traverses a link where MTU is > 1280? See (a) below... > > > Maybe I'm just an implementor, but I thought the whole purpose > > of the IPng header layout was for extensibility. It seems quite contrary > to > > the spirit of the design to start applying arbitrary limits at this > > point. In any case, what would be your hard limit? 1279? 512? 1280-n? > > (Where n is the largest minimum payload requirement for all reasonable > > transport protocols?) How would you begin to calculate n? > > Perhaps, a concrete description of the problem is worthwhile. > Telford Tools occasionally does work a DEC/Compaq location > that has a lot of 100 Mbps ethernet and a lot of FDDI. The > MTU size on the ethernet is ~1500 while on FDDI the MTU > size is ~4K. I believe the installation uses Cisco routers > configured for RIP routing with load sharing between equal cost > paths. Path MTU between two hosts will sometimes be > ~1500 and will sometimes be ~4K. In the case of IPv4, > the headers are always less than 1500 and the routers > carry out fragmentation during those periods when > large packets are traversing an ethernet. In the case of IPv6, > fragmentation would take place at the host, and headers > could not be larger than 1500 (actually some space would > have to be left for payload). If the situation is not abnormal, > I think we could expect that IPv6 packets would tend to > get transmitted with sizes of 1280 or less and would > have to leave space for payload. > Okay, is _this_ a question about header size limitations or a compaint about the host fragmentation requirement? (See (b) below). I think you missed my point, so I'll try again (and I feel an analogy coming). The proposed change of introducing a fixed header limit is bad because it... (a) ...generates a new problem that previously did not exist in the protocol (arbitrary limitation on header size for links/paths that could use more). I would much rather be able to exchange my data over some links than none. Besides (using your example from above), what happens if the site goes fully FDDI? You'll be left with a restriction that blocks reasonable usage -- when the reason for that restriction is no longer present. (b) ...doesn't solve the problem it purports to address. Again, if we specify a maximum header size of (1280-n), how are we to select the appropriate 'n'? As 'n' approaches zero, the probability that it will be too small for some upper layer protocol approaches 1.0; as 'n' gets larger, the probability that it will be too large to allow a reasonably sized header approaches 1.0. (This is true whether it is specified as a header size limitation (e.g. 1024), or as a minimum payload requirement (e.g. 10)). If we use your example above as a guideline for setting a maximum header size (based on the lowest MTU in the environment (1500)), then we potentially harm those with links with an MTU of 1280. If we use an MTU of 1280 as the basis (which I assume you are proposing), we are forced to a smaller maximum header length, which brings us that much closer to stomping on a reasonable header. This is sort of like requiring all bicyclists who ride in mountainous areas to wear a parachute. It's a hassle for those who don't fall off a cliff, and it may not save those who do. So, to those who propose a max header length...what length do you suggest? Or, if you propose a min payload capacity...what capacity do you suggest? I would rather err on the side of allowing communication in some cases (even if it failed in others), than err on the side of restriction. That seems more "best effort" to me. -andrew > Joachim Martillo > Telford Tools, Inc. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- +---------------------------------------------------------------------------+ | Andrew Kephart, AIX TCP/IP These are my opinions only...IBM might | | SMTP: akephart@austin.ibm.com agree, but I wouldn't count on it. | +---------------------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 24 11:02:33 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id KAA19957 for ipng-dist; Wed, 24 Jun 1998 10:53:46 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id KAA19950 for ; Wed, 24 Jun 1998 10:53:25 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA10709 for ; Wed, 24 Jun 1998 10:53:23 -0700 Received: from imo25.mx.aol.com (imo25.mx.aol.com [198.81.17.69]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA01472 for ; Wed, 24 Jun 1998 10:53:24 -0700 (PDT) Received: from Telford001@aol.com by imo25.mx.aol.com (IMOv14_b1.1) id NUCFa03745; Wed, 24 Jun 1998 13:52:46 -0400 (EDT) Message-ID: Date: Wed, 24 Jun 1998 13:52:46 EDT To: akephart@austin.ibm.com Cc: ipng@sunroof.eng.sun.com, Bodzia@aol.com Mime-Version: 1.0 Subject: (IPng 5926) Re: Last Call: Internet Protocol, Version 6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 6/24/98 11:29:36 AM Eastern Daylight Time, akephart@austin.ibm.com writes: > Okay, is _this_ a question about header size limitations or a > compaint about the host fragmentation requirement? (See (b) below). The questions seem to be interrelated. > I think you missed my point, so I'll try again (and I feel an > analogy coming). > The proposed change of introducing a fixed header limit is bad > because it... > (a) ...generates a new problem that previously did not exist in > the protocol (arbitrary limitation on header size for links/paths that > could use more). I would much rather be able to exchange my data over > some links than none. Given the use of load sharing between equal cost paths in OSPF and other routing systems, I have doubts how acceptable an environment that periodically created routing black holes would be. Now I suppose we could just demand the smaller MTU size, but increasing the amount of packet processing at the host (fragmenting, transmit done interrupts) while decreasing the amount of packet processing at the routers (by eliminating router fragmentation) which are after all optimized for packet processing is not the most obvious way to build a high performance packet switching system. > Besides (using your example from above), what > happens if the site goes fully FDDI? You'll be left with a restriction > that blocks reasonable usage -- when the reason for that restriction is > no longer present. Does a restriction to headers of length 60 in IPv4 really prevent effective use of either the ethernet or FDDI media? > (b) ...doesn't solve the problem it purports to address. > Again, if we specify a maximum header size of (1280-n), how are we to > select the appropriate 'n'? As 'n' approaches zero, the probability > that it will be too small for some upper layer protocol approaches 1.0; > as 'n' gets larger, the probability that it will be too large to allow a > reasonably sized header approaches 1.0. The following question then arises. Is the problem to be solved by IPv6 perhaps not formulated properly? If it were formulated properly, perhaps the maximum sized header would be known, and this discussion would not be necessary. > (This is true whether it is > specified as a header size limitation (e.g. 1024), or as a minimum > payload requirement (e.g. 10)). If we use your example above as a > guideline for setting a maximum header size (based on the lowest MTU in > the environment (1500)), then we potentially harm those with links with > an MTU of 1280. If we use an MTU of 1280 as the basis (which I assume > you are proposing), we are forced to a smaller maximum header length, > which brings us that much closer to stomping on a reasonable header. Perhaps complete extensibility is not a good idea. For example, ASN.1 provides a way to create practically any type. Add BER or DER and practically any encoding can be created. Yet, XDR is sufficient for practically any reasonable situation. Therefore why bother with ASN.1 (+BER or DER) except for the problem that SUN owns XDR. > This is sort of like requiring all bicyclists who ride in > mountainous areas to wear a parachute. It's a hassle for those who > don't fall off a cliff, and it may not save those who do. The law does require all bicyclists to wear helmets. In any case, I am not sure that the metaphor is clarifying the issue. > So, to those who propose a max header length...what length do > you suggest? Or, if you propose a min payload capacity...what capacity > do you suggest? Min payload without a min header can create the situation where the packet exceeds the min MTU size. > I would rather err on the side of allowing communication in > some cases (even if it failed in others), than err on the side of > restriction. That seems more "best effort" to me. Defining the restrictions is usually the first step to solving an engineering problem. Joachim Martillo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 24 15:16:07 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id PAA20533 for ipng-dist; Wed, 24 Jun 1998 15:08:44 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id PAA20526 for ; Wed, 24 Jun 1998 15:08:32 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA26090 for ; Wed, 24 Jun 1998 15:08:31 -0700 Received: from imo27.mx.aol.com (imo27.mx.aol.com [198.81.17.71]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id PAA10879 for ; Wed, 24 Jun 1998 15:08:30 -0700 (PDT) Received: from Telford001@aol.com by imo27.mx.aol.com (IMOv14_b1.1) id NGXPa06638; Wed, 24 Jun 1998 18:07:56 -0400 (EDT) Message-ID: <1692e238.359178bd@aol.com> Date: Wed, 24 Jun 1998 18:07:56 EDT To: Telford001@aol.com, akephart@austin.ibm.com Cc: ipng@sunroof.eng.sun.com, Bodzia@aol.com Mime-Version: 1.0 Subject: (IPng 5927) Re: Last Call: Internet Protocol, Version 6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 6/24/98 2:13:55 PM Eastern Daylight Time, Telford001@aol.com writes: > > I would rather err on the side of allowing communication in > > some cases (even if it failed in others), than err on the side of > > restriction. That seems more "best effort" to me. > Defining the restrictions is usually the first step to solving an > engineering problem. In re: restricting the engineering problem. Even if the working group does not want to restrict the packet definitions for some reason, the need for data integrity, mathematics and the nature of the hardware being used really creates some inescapable restrictions. If very large headers and payloads are going to be used, it really necessitates the use over the IP packet of CRC-32, Fletcher checksums or some other checksum that is resistent to multiple bit errors, which become more probable as packets become larger. Such checksums generally require hardware. Is the intent to require special checksumming hardware for the network layer packets? Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 24 21:17:43 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id VAA20885 for ipng-dist; Wed, 24 Jun 1998 21:14:06 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id VAA20878 for ; Wed, 24 Jun 1998 21:13:45 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA19107 for ; Wed, 24 Jun 1998 21:13:39 -0700 Received: from imo23.mx.aol.com (imo23.mx.aol.com [198.81.17.67]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id VAA15100 for ; Wed, 24 Jun 1998 21:13:40 -0700 (PDT) Received: from Telford001@aol.com by imo23.mx.aol.com (IMOv14_b1.1) id NALa026053; Thu, 25 Jun 1998 00:12:43 -0400 (EDT) Message-ID: <629d4421.3591ce3e@aol.com> Date: Thu, 25 Jun 1998 00:12:43 EDT To: Telford001@aol.com, akephart@austin.ibm.com Cc: ipng@sunroof.eng.sun.com, Bodzia@aol.com Mime-Version: 1.0 Subject: (IPng 5928) Re: Last Call: Internet Protocol, Version 6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 6/24/98 6:07:56 PM Eastern Daylight Time, Telford001 writes: > If very large headers and payloads are going to be used, it > really necessitates the use over the IP packet of CRC-32, Fletcher > checksums or some other checksum that is resistent to multiple > bit errors, which become more probable as packets become larger. > Such checksums generally require hardware. Is the intent > to require special checksumming hardware for the network > layer packets? Typing slip -- I mean the UDP and TCP checksums that include an IPv6 address pseudo header just like UDP and TCP checksums that include an IPv4 address pseudoheader. Joachim Martillo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 25 07:46:43 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id HAA21281 for ipng-dist; Thu, 25 Jun 1998 07:42:48 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id HAA21274 for ; Thu, 25 Jun 1998 07:42:40 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA15878; Thu, 25 Jun 1998 07:42:37 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA23427; Thu, 25 Jun 1998 07:42:37 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0f) with SMTP id KAA25475; Thu, 25 Jun 1998 10:42:32 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA11522; Thu, 25 Jun 1998 10:42:29 -0400 Message-Id: <199806251442.AA11522@wasted.zk3.dec.com> To: Craig Metz Cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: (IPng 5930) Re: IPV6_ADDRFORM In-Reply-To: Your message of "Tue, 23 Jun 1998 08:55:30 -0300." <199806231251.MAA07088@inner.net> Date: Thu, 25 Jun 1998 10:42:29 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Craig, > Well, then I guess this will be useful feature that some implementations >won't have. I pretty much agree with Erik's mail exchange with you. I don't need ADDRFORM as you say you need and most of us don't either. If you really believe it to be important can we put it in the Advanced API for discusission and debate. I really don't want to add anymore to the Basic API I am trying to gat a new draft out on for early July. thanks /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 Jun 25 09:19:39 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id JAA21427 for ipng-dist; Thu, 25 Jun 1998 09:14:28 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with ESMTP id JAA21420 for ; Thu, 25 Jun 1998 09:13:52 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0+Sun/8.9.0) with ESMTP id JAA04075 for ; Thu, 25 Jun 1998 09:13:51 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA01450 for ipng@sunroof.eng.sun.com; Thu, 25 Jun 1998 09:12:41 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id GAA21218 for ; Thu, 25 Jun 1998 06:25:42 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA01277 for ; Thu, 25 Jun 1998 06:25:39 -0700 Received: from fulbert.isc-net.upenn.edu (FULBERT.ISC-NET.UPENN.EDU [130.91.72.170]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA13726 for ; Thu, 25 Jun 1998 06:25:39 -0700 (PDT) Received: (from tex@localhost) by fulbert.isc-net.upenn.edu (8.8.7/8.8.7) id JAA00644; Thu, 25 Jun 1998 09:24:17 -0400 To: ipng@sunroof.eng.sun.com Subject: (IPng 5931) Re: Last Call: Internet Protocol, Version 6 References: From: "Jon 'tex' Boone" X-Newsreader: Gnus v5.5/Emacs 20.2 Date: 25 Jun 1998 09:24:16 -0400 In-Reply-To: Telford001@aol.com's message of 24 Jun 98 17:52:46 GMT Message-ID: Lines: 125 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A few comments: Telford001@aol.com writes: > > In a message dated 6/24/98 11:29:36 AM Eastern Daylight Time, > akephart@austin.ibm.com writes: > > > (a) ...generates a new problem that previously did not exist in > > the protocol (arbitrary limitation on header size for links/paths > > that could use more). I would much rather be able to exchange my > > data over some links than none. > > Given the use of load sharing between equal cost paths in OSPF and > other routing systems, I have doubts how acceptable an environment > that periodically created routing black holes would be. I find it difficult to imagine needing to send enough header options to create this problem. It seems, intuitively, that if every packet requires enough overhead at the network layer to preclude sending non-header data over a path then some or all of the following apply: a) the MTU size of the path is too small and a media-type with a larger MTU size is required. b) there is a good case for encapsulation/tunneling. c) a higher/lower layer should be providing these services. d) a more compact representation of options is required. Now, that being said, let us assume that the situation can actually occur. The important question is where will it occur? In a NSP's backbone? Not likely, as some applications (those which require the monster-options) won't be able to traverse the backbone in question and the customers will choose another path (that doesn't use the NSP's backbone) to communicate. In an enterprise network? In this case, it is at the discretion of the enterprise as to whether or not it wants to allow this type of application to make use of the network. If it does, it can replace the infrastructure with the small MTU size with infrastructure that has a more appropriately sized MTU. If not, then by fiat, the application doesn't work for that enterprise. Do you see a scenario where there is a benefit to the community as a whole to limiting the header size? Recall the maxim: Be liberal in what you accept, conservative in what you send. It seems to apply in this case. > increasing the amount of packet processing at the host (fragmenting, > transmit done interrupts) while decreasing the amount of packet > processing at the routers (by eliminating router fragmentation) > which are after all optimized for packet processing is not the most > obvious way to build a high performance packet switching system. Please recall that the evolution of the Internet protocols has occurred in an environment where there is typically *more* computer power at a host than there is in the network devices. This, coupled with the ever-increasing transmission/reception speeds, is the primary reason for moving fragmentation out of the network and into the hosts. The "obvious" way of building a high performance packet switching system might be to build a large computer that handles the packet switching and connect less powerful devices to this large switch. That is the way that the POTS system is engineered. But, just as obviously, the infrastructure costs for the switches are phenomenal compared to the end stations. I think that the tradeoff we want to make is to minimize the complexity of the devices in the center of the network, pushing complexity to the edges. This is a proven way to scale the network infrastructure to higher and higher transmission rates while keeping costs down. > Does a restriction to headers of length 60 in IPv4 really prevent > effective use of either the ethernet or FDDI media? Not for today's applications, nor can I imagine needing monster-options tomorrow. But, if we can provide for them now, then we can avoid having to invent yet-another-IP-protocol-version to handle the fact that we chose to preclude monster-options at this point. > The following question then arises. Is the problem to be solved by > IPv6 perhaps not formulated properly? If it were formulated > properly, perhaps the maximum sized header would be known, and this > discussion would not be necessary. Why are you assuming that there is a need to specify a maximum header size? If I can't use monster-options (because my packets all become too large), then I won't. If I can (and I need/want to), then I will. What's the problem? > Perhaps complete extensibility is not a good idea. For example, > ASN.1 provides a way to create practically any type. Add BER or DER > and practically any encoding can be created. Yet, XDR is sufficient > for practically any reasonable situation. Therefore why bother with > ASN.1 (+BER or DER) except for the problem that SUN owns XDR. Point taken. Now, the counter point: Y2K. This industry loves to talk about "future-proof" networking --- by inserting arbitrary limits that serve no *necessary* purpose, we are limiting the usefulness of the system. > Min payload without a min header can create the situation where the > packet exceeds the min MTU size. I assume that you meant: "Min payload without a *max* header can create the situation where the packet exceeds the *max* MTU size." To which the response is: And the lower layer protocol handler (Ethernet, say) will reject the packet and the IP stack will know that it can't use so many options. What's the problem? This is how it is *supposed* to work. -- -------------------------------------------------- Jon 'tex' Boone Senior Network Engineer ISC Networking University of Pennsylvania tex@isc.upenn.edu (215) 898-2477 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 25 18:38:00 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id SAA22003 for ipng-dist; Thu, 25 Jun 1998 18:32:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id SAA21996 for ; Thu, 25 Jun 1998 18:31:33 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA16586 for ; Thu, 25 Jun 1998 18:31:33 -0700 Received: from imo23.mx.aol.com (imo23.mx.aol.com [198.81.17.67]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id SAA11593 for ; Thu, 25 Jun 1998 18:31:32 -0700 (PDT) Received: from Telford001@aol.com by imo23.mx.aol.com (IMOv14_b1.1) id LCIOa26052; Thu, 25 Jun 1998 21:28:16 +2000 (EDT) Message-ID: <1b2fc2c4.3592f931@aol.com> Date: Thu, 25 Jun 1998 21:28:16 EDT To: tex@isc.upenn.edu Cc: ipng@sunroof.eng.sun.com, Telford001@aol.com Mime-Version: 1.0 Subject: (IPng 5933) Re: Last Call: Internet Protocol, Version 6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 6/25/98 12:30:55 PM Eastern Daylight Time, tex@isc.upenn.edu writes: > A few comments: > Telford001@aol.com writes: > > In a message dated 6/24/98 11:29:36 AM Eastern Daylight Time, > > akephart@austin.ibm.com writes: > > > (a) ...generates a new problem that previously did not exist in > > > the protocol (arbitrary limitation on header size for links/paths > > > that could use more). I would much rather be able to exchange my > > > data over some links than none. > > Given the use of load sharing between equal cost paths in OSPF and > > other routing systems, I have doubts how acceptable an environment > > that periodically created routing black holes would be. > I find it difficult to imagine needing to send enough header options > to create this problem. I have to admit that I find the situation hard to imagine as well. I think the claim was that RSVP or some similar control or signaling protocol might need this functionality. I suppose one could remove the restrictions on the record route or source routing, but one does not see 80 hop paths between endpoints so often. But certainly the common numbers of hops on a path are regularly increasing so that 80 hops is not outrageously many. > It seems, intuitively, that if every packet > requires enough overhead at the network layer to preclude sending > non-header data over a path then some or all of the following apply: > a) the MTU size of the path is too small and a media-type with a > larger MTU size is required. > b) there is a good case for encapsulation/tunneling. > c) a higher/lower layer should be providing these services. > d) a more compact representation of options is required. I would agree. > Now, that being said, let us assume that the situation can actually > occur. The important question is where will it occur? > > In a NSP's backbone? Not likely, as some applications (those which > require the monster-options) won't be able to traverse the backbone > in question and the customers will choose another path (that doesn't > use the NSP's backbone) to communicate. I understood the issue to involve signaling packets, maybe with record route or source route options and security options. > In an enterprise network? In this case, it is at the discretion of > the enterprise as to whether or not it wants to allow this type of > application to make use of the network. If it does, it can replace > the infrastructure with the small MTU size with infrastructure that > has a more appropriately sized MTU. If not, then by fiat, the > application doesn't work for that enterprise. Then what is the point of defining a min MTU? Is not the goal to guarantee that the "application" can choose a specific size that is always guaranteed to work (but perhaps not with the best performance). > Do you see a scenario where there is a benefit to the community as a > whole to limiting the header size? Recall the maxim: Be liberal in > what you accept, conservative in what you send. It seems to apply > in this case. If my understanding of the purpose of min MTU is correct, it defines an arbitrary max header size. The question becomes whether it might be better to make the arbitrary max header size smaller. As for liberality in what an implementation accepts and conservativeness in what is sent, IPv6 seems to have pushed the principle to new limits by providing so many fields in a packet that are unprotected by checksums and by encouraging the transmission of large packets protected by possibly inadequate checksums. Liberality in the acceptance of bit errors is not obviously a good principle. > > increasing the amount of packet processing at the host (fragmenting, > > transmit done interrupts) while decreasing the amount of packet > > processing at the routers (by eliminating router fragmentation) > > which are after all optimized for packet processing is not the most > > obvious way to build a high performance packet switching system. > Please recall that the evolution of the Internet protocols has > occurred in an environment where there is typically *more* computer > power at a host than there is in the network devices. This, coupled > with the ever-increasing transmission/reception speeds, is the > primary reason for moving fragmentation out of the network and into > the hosts. Certainly, in the case of border routers where performance is limited by WAN link speeds which are usually fairly low, the comment is true. Even if we compare large inner network routers with the aggregate power of end hosts that they might be serving, the comment is true. But large network servers usually have so many other things to do. Their performance is greatly improved if they do as little packet processing (route lookups, fragmentation as possible) while large inner network routers theoretically are running application code highly optimized for packet processing like route lookups and fragmentation. While router fragmentation is extremely useful in specific cases (*) it is not generally so common a procedure in the IPv4 internet that there is much obvious benefit from creating an unenforceable rule in the IPv6 internet that only hosts should fragment. > The "obvious" way of building a high performance packet switching > system might be to build a large computer that handles the packet > switching and connect less powerful devices to this large switch. > That is the way that the POTS system is engineered. But, just as > obviously, the infrastructure costs for the switches are phenomenal > compared to the end stations. The infrastructural costs associated with circuit switching have been distorted by decades during which the manufacturers had no incentive to discover how to build these infrastructural elements cheaply. I am not sure much in the way of valid conclusions can be drawn from the cost of large toll switches, CO switches or even PRXs. > I think that the tradeoff we want to make is to minimize the > complexity of the devices in the center of the network, pushing > complexity to the edges. This is a proven way to scale the network > infrastructure to higher and higher transmission rates while keeping > costs down. Only if it is desired to kill server performance (or effective performance perceived by clients) by forcing the edge devices effectively to do lots of route lookups and keep track of lots of labels. Normally the way to minimize complexity problems is to create hierarchy. The phone network was expanded in this way. DECNET was expanded in this way. And in fact the internet has expanded in this way via NAT and firewalls. In many ways, IPv6 is contrary to the natural evolution of the internet, which would have been more effectively carried out by introducing an Address Extension option that carried a 32 bit internet number that would have interoperated well with NAT and firewalls. In this way network instability could have been confined to specific internets or to the superinternet routing layer. The IPv6 architecture has the potential for continuous instability because it enables the construction of a much larger single internet. The bigger the internet, the greater probability that instability exists somewhere and is being propagated. > > Does a restriction to headers of length 60 in IPv4 really prevent > > effective use of either the ethernet or FDDI media? > Not for today's applications, nor can I imagine needing > monster-options tomorrow. But, if we can provide for them now, then > we can avoid having to invent yet-another-IP-protocol-version to > handle the fact that we chose to preclude monster-options at this > point. Normally engineering progresses by identifying inadequacies and fixing them incrementally. Creating an IPv4 address extension option would have been an example of such an incremental improvement. Nevertheless, defining IPv6 as a radical inovation does not stop the process of identifying inadequacies and making proposals to fix them incrementally. The IPv6 header size definition, the lack of protection of large headers from bit flips, inadequate checksums on TCP and UDP packets are all areas of possible inadequacy that we should be actively investigating for possible refinement even before the specification of IPv6 is complete. > > Perhaps complete extensibility is not a good idea. For example, > > ASN.1 provides a way to create practically any type. Add BER or DER > > and practically any encoding can be created. Yet, XDR is sufficient > > for practically any reasonable situation. Therefore why bother with > > ASN.1 (+BER or DER) except for the problem that SUN owns XDR. > Point taken. Now, the counter point: Y2K. This industry loves to > talk about "future-proof" networking --- by inserting arbitrary > limits that serve no *necessary* purpose, we are limiting the > usefulness of the system. I might have argued the reverse. Y2K problems involve some obviously bad encoding choices for year fields in certain data formats and operating systems. Careful thought about constraints early might have prevented a lot of problem. There are some dependencies between min MTU and max header size whose implications we should probably understand now so that we do not get bit later. > > Min payload without a min header can create the situation where the > > packet exceeds the min MTU size. > I assume that you meant: > > "Min payload without a *max* header can create the situation where > the packet exceeds the *max* MTU size." If there were a minimum payload, the size of the header plus the size of the minimum payload could exceed the minimum defined maximum transit unit. In such cases, an application that has no reason on the basis of the protocol standards not to work will not work in the minimal networking environment. Such a situation seems to be a problem. > To which the response is: > > And the lower layer protocol handler (Ethernet, say) will reject the > packet and the IP stack will know that it can't use so many > options. What's the problem? This is how it is *supposed* to > work. I might have stated the opposite. If an implementation does nothing that is forbidden by the specifications, it should work. Currently, IPv6 seems to have at least one case, where an implementation might do nothing forbidden and yet not work in the "guaranteed minimum environment." I would consider this situation a problem. Joachim Martillo Telford Tools, Inc. (*) Because we build packet switch adapter cards 1. that contain complete hybrid L2/L3 switch routers, 2. that communicate with the host over the system bus and 3. that provide part of the performance improvement by decreasing the amount of packet processing across the system bus, in our environment it makes far more sense to fragment on the packet switch adapter card, i.e. on the router, rather than on the host. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 25 19:01:18 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id SAA22067 for ipng-dist; Thu, 25 Jun 1998 18:56:29 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id SAA22060 for ; Thu, 25 Jun 1998 18:56:18 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA20251 for ; Thu, 25 Jun 1998 18:56:17 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id SAA20362 for ; Thu, 25 Jun 1998 18:56:08 -0700 (PDT) From: Masataka Ohta Message-Id: <199806260145.KAA12150@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA12150; Fri, 26 Jun 1998 10:44:47 +0859 Subject: (IPng 5934) Re: Last Call: Internet Protocol, Version 6 To: akephart@austin.ibm.com Date: Fri, 26 Jun 98 10:44:45 JST Cc: Telford001@aol.com, ipng@sunroof.eng.sun.com In-Reply-To: <199806241513.KAA33660@aguila.austin.ibm.com>; from "akephart@austin.ibm.com" at Jun 24, 98 10:13 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andrew; > > And if for some reason the path traverses a link where MTU is > > 1280? > > See (a) below... > (a) ...generates a new problem that previously did not exist in > the protocol (arbitrary limitation on header size for links/paths that > could use more). I would much rather be able to exchange my data over > some links than none. You need ToS or QoS routing then. Worse, even if a path with small path MTU is available, you can't have communication. I would much much much rather be able to exchange my data over some pathes than none. > Besides (using your example from above), what > happens if the site goes fully FDDI? Are you saying that you need a lengthy header with hop-by-hop something with "the site"? Or, are you saying that the whole Internet will be FDDI? In the latter case, minimum MTU should be 4096. > (b) ...doesn't solve the problem it purports to address. > Again, if we specify a maximum header size of (1280-n), how are we to > select the appropriate 'n'? As 'n' approaches zero, the probability > that it will be too small for some upper layer protocol approaches 1.0; > as 'n' gets larger, the probability that it will be too large to allow a > reasonably sized header approaches 1.0. That there is some tradeoff does not mean that we can't make some engineering decision. > So, to those who propose a max header length...what length do > you suggest? Or, if you propose a min payload capacity...what capacity > do you suggest? See Steve's suggestion, for example. > I would rather err on the side of allowing communication in > some cases (even if it failed in others), than err on the side of > restriction. That seems more "best effort" to me. That's why lengthy data should be put in the payload part, not in the header part. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 10:09:56 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id KAA22925 for ipng-dist; Fri, 26 Jun 1998 10:01:59 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id KAA22918 for ; Fri, 26 Jun 1998 10:01:47 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA11159 for ; Fri, 26 Jun 1998 10:01:45 -0700 Received: from aurora.cs.ucla.edu (Aurora.CS.UCLA.EDU [131.179.96.157]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA08905 for ; Fri, 26 Jun 1998 10:01:44 -0700 (PDT) Received: (from lixia@localhost) by aurora.cs.ucla.edu (8.8.8/UCLACS-4.0) id KAA12976; Fri, 26 Jun 1998 10:01:39 -0700 (PDT) From: Lixia Zhang Message-Id: <199806261701.KAA12976@aurora.cs.ucla.edu> Subject: (IPng 5937) Re: Last Call: Internet Protocol, Version 6 To: Telford001@aol.com Date: Fri, 26 Jun 1998 10:01:39 -0700 (PDT) Cc: tex@isc.upenn.edu, ipng@sunroof.eng.sun.com In-Reply-To: <1b2fc2c4.3592f931@aol.com> from "Telford001@aol.com" at Jun 25, 98 09:28:16 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have not followed the thread closely but thought I'd make a comment about the hop count question raised below > I have to admit that I find the situation hard to imagine as well. I think > the claim was that RSVP or some similar control or signaling > protocol might need this functionality. I suppose one could > remove the restrictions on the record route or source routing, > but one does not see 80 hop paths between endpoints > so often. But certainly the common numbers of hops > on a path are regularly increasing so that 80 hops is not outrageously > many. As a term project 3 UCLA studnets did a brute force traceroute measurement last November to "see how big the Internet really is", they trace-routed to a few thousand randomly selected hosts all around the world. The finding shows that, from UCLA, - one can reach majority places within 20 or so hops - 30 hops get you almost anywhere (the max is 30+ something) And these results seem more or less consistent with measurments done (by others) one or two years earlier. Before you ask: we are revising the report (that's just been accepted by Globecom miniconf on Internet), so wait for a month if you are interested in more detail. Lixia -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 10:13:00 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id KAA22954 for ipng-dist; Fri, 26 Jun 1998 10:08:29 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with ESMTP id KAA22947 for ; Fri, 26 Jun 1998 10:08:14 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0+Sun/8.9.0) with ESMTP id KAA21227 for ; Fri, 26 Jun 1998 10:08:07 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id KAA03066 for ipng@sunroof.eng.sun.com; Fri, 26 Jun 1998 10:07:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id FAA22534 for ; Fri, 26 Jun 1998 05:21:57 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA20541 for ; Fri, 26 Jun 1998 05:21:54 -0700 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id FAA26206 for ; Fri, 26 Jun 1998 05:21:55 -0700 (PDT) Received: from era-t.ericsson.se (era-t.ericsson.se [147.214.173.8]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/glacier-1.11) with SMTP id OAA13454 for ; Fri, 26 Jun 1998 14:21:54 +0200 (MET DST) Received: from preppens by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id OAA27778; Fri, 26 Jun 1998 14:21:53 +0200 Message-Id: <3.0.32.19980626142710.00af6c40@anchor.ericsson.se> X-Sender: eratekd@anchor.ericsson.se X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 26 Jun 1998 14:27:12 +0100 To: ipng@sunroof.eng.sun.com From: Thomas Eklund Subject: (IPng 5939) IPv6 questions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi I have a couple of questions that I could not find in the drafts or RFCs: - How does the DNS work with ND? If you are not using mobile IPv6. OR must you use a DHCP stateful aproach to get a DNS name but how does that map to my "home DNS"? What is the relation to Dynamic DNS? - How does Path MTU discovery work for mobile IPv6 when you change subnet work and get a new IP adress with ND! It seems to be a bad design to do a new PMTU discovery when you enter the new subnet. Could there a good thing to let the MTU size propagate up to the router for the subnet and include it in the RA's? This could have potential benefits for mobile IPv6. - How does Path MTU discovery works for UDP? - This is perhaps a stupid question, but what is the need for jumbograms when you have PMTU? - Might there be a problem for Real time traffic if the IPv6 minimum link MTU size is increased to 1280? IT will introduce more delay the bigger MTU which is not good for delay sensitive traffic - just wondering what the objectives were behind that decision? - Is there any thoughts how to define Any cast addresses for a global scope? - I heard that, in the last IETF meeting, Mobile-IP group tried to insert Mobile-IPv6 into standard IPv6 specification, but the attempt was refused by IPng group. What is the latest news? This seems like a very bad idea because I think that one big driving force would be that IPv6 has very good capabilities for scalable mobile systems and it seem that the driving force will come in those systems and not in "Cisco" land - Have there been anyone looking into defining IPv6 over GigabitEthernet? - One good thing is the new hiearchical addrescheme but what happens when v6 is in the backbone what is the ideas on how to aggregate the v4 clouds into the v6 arch.? ---------------------------- - Is there anyone who had a evaluation why the HW can be built much easier than for v4? - Is there anyone who know about the big operators link MCI, Sprint, Nordunet etc if they have put up a date on their agenda when they start providing native v6 in their backbones? - Why havent the v6 folks responded more loud to Cisco tactic - when they say to their customers today that v6 doesn't give you anything that we cant fix with v4 and that their NAT solutions solve every problem? I think this is a big obstacle area when it comes to people's understanding about why we need to move as fast as possible to v6 if we want Internet to continue to grow and not solve it with non scalable NAT solutions and people!!! Comments? (this is not intended to offend Cisco in any way but there seems to reason to clarify their statement towards the IPv6 community) - Why can't there be a BOF in the next IETF meeting something like "IPv6 opportunities for Operators" Best Regards Thomas Eklund, Ericsson Radio Systems AB -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 10:15:49 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id KAA22945 for ipng-dist; Fri, 26 Jun 1998 10:07:56 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with ESMTP id KAA22938 for ; Fri, 26 Jun 1998 10:07:43 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0+Sun/8.9.0) with ESMTP id KAA21031 for ; Fri, 26 Jun 1998 10:07:36 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id KAA03038 for ipng@sunroof.eng.sun.com; Fri, 26 Jun 1998 10:06:56 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id QAA21906 for ; Thu, 25 Jun 1998 16:21:59 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA20266 for ; Thu, 25 Jun 1998 16:21:59 -0700 Received: from mail.reach.net (connect.reach.net [204.50.58.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id QAA05455 for ; Thu, 25 Jun 1998 16:21:57 -0700 (PDT) Received: from GhostRider (A02.reach.net [204.50.58.33]) by mail.reach.net (8.8.6/8.6.9) with SMTP id TAA13002 for ; Thu, 25 Jun 1998 19:21:17 -0400 Message-Id: <3.0.32.19980625192059.00683cd0@telos.ca> X-Sender: colt@telos.ca X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 25 Jun 1998 19:21:04 -0400 To: ipng@sunroof.eng.sun.com From: "M. Coltart/L Hupman" Subject: (IPng 5938) ARP sniffing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am a relative newbie to the LINUX/UNIX world. I am running a RedHat 5.1 system with TCP/IP wrappers on a "cable" ISP network. All R host protocols and auto mounts and NFS/NIS are turned off and Hosts allow and deny are configured and working with inetd.conf. A NetBSD system in the same subnet as ours (last two in our IP is 35.48 theirs is 34.79) keeps showing up in our ARP. The Op of the other system claims this is a feature of their UDP. They first tried portmapping in at the ypserv and the mountd. Which they corrected when I called them up and gave them a blast now this ARP thing keeps coming back after I delete it from the cache it shows up a coupl of seconds later. Any Ideas would be helpful Mike Coltart -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 13:48:49 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id NAA23360 for ipng-dist; Fri, 26 Jun 1998 13:41:31 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id NAA23353 for ; Fri, 26 Jun 1998 13:41:22 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA08794 for ; Fri, 26 Jun 1998 13:41:19 -0700 Received: from imo24.mx.aol.com (imo24.mx.aol.com [198.81.17.68]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA07088 for ; Fri, 26 Jun 1998 13:41:19 -0700 (PDT) Received: from Telford001@aol.com by imo24.mx.aol.com (IMOv14_b1.1) id SEKGa22588; Fri, 26 Jun 1998 16:40:04 -0400 (EDT) Message-ID: <9656cb1.35940725@aol.com> Date: Fri, 26 Jun 1998 16:40:04 EDT To: thomas.eklund@era.ericsson.se Cc: ipng@sunroof.eng.sun.com, Telford001@aol.com Mime-Version: 1.0 Subject: (IPng 5940) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 6/26/98 1:23:38 PM Eastern Daylight Time, thomas.eklund@era.ericsson.se writes: > - Why havent the v6 folks responded more loud to Cisco tactic - when they > say to their customers today that v6 doesn't give you anything that we cant > fix with v4 and that their NAT solutions solve every problem? They are correct. NAT+Firewalling is a very natural way to extend IPv4 to a larger address space without the radical changes that IPv6 introduces. > I think this > is a big obstacle area when it comes to people's understanding about why we > need to move as fast as possible to v6 if we want Internet to continue to > grow and not solve it with non scalable NAT solutions and people!!! Comments? The two level hierarchy that NAT solutions introduce is the common way to scale. DECNET was scaled via two level hierarchical routing. Likewise the phone network uses hierachical circuit switching to scale. The v6 solution is more likely to have scaling problems than two level hierarchy with NAT. A huge global IPv6 internet is practically guaranteed to be undergoing topological instability somewhere in the internet. Such topological instability will tend to propagate. In contrast it will be hard to propagate topological instability across network address translators+firewalls. > (this is not intended to offend Cisco in any way but there seems to reason > to clarify their statement towards the IPv6 community) Rather then try to compete with NAT+firewalling, a more incremental way for the IETF to deal with the inadequacies of IPv4 would be to create options for left and right address extensions (a left address extension to indentify internet and a right address extension as a subaddress for NAT). Sometime later the left address extension (internet number) + the IPv4 address + the right address extension (subaddress) could be mapped into an IPv6 address. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 26 13:49:34 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id NAA23369 for ipng-dist; Fri, 26 Jun 1998 13:41:51 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id NAA23362 for ; Fri, 26 Jun 1998 13:41:43 -0700 (PDT) From: Telford001@aol.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA04171 for ; Fri, 26 Jun 1998 13:41:41 -0700 Received: from imo24.mx.aol.com (imo24.mx.aol.com [198.81.17.68]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id NAA02963 for ; Fri, 26 Jun 1998 13:41:28 -0700 (PDT) Received: from Telford001@aol.com by imo24.mx.aol.com (IMOv14_b1.1) id SEKGa22588; Fri, 26 Jun 1998 16:40:04 -0400 (EDT) Message-ID: <9656cb1.35940725@aol.com> Date: Fri, 26 Jun 1998 16:40:04 EDT To: thomas.eklund@era.ericsson.se Cc: ipng@sunroof.eng.sun.com, Telford001@aol.com Mime-Version: 1.0 Subject: (IPng 5941) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 6/26/98 1:23:38 PM Eastern Daylight Time, thomas.eklund@era.ericsson.se writes: > - Why havent the v6 folks responded more loud to Cisco tactic - when they > say to their customers today that v6 doesn't give you anything that we cant > fix with v4 and that their NAT solutions solve every problem? They are correct. NAT+Firewalling is a very natural way to extend IPv4 to a larger address space without the radical changes that IPv6 introduces. > I think this > is a big obstacle area when it comes to people's understanding about why we > need to move as fast as possible to v6 if we want Internet to continue to > grow and not solve it with non scalable NAT solutions and people!!! Comments? The two level hierarchy that NAT solutions introduce is the common way to scale. DECNET was scaled via two level hierarchical routing. Likewise the phone network uses hierachical circuit switching to scale. The v6 solution is more likely to have scaling problems than two level hierarchy with NAT. A huge global IPv6 internet is practically guaranteed to be undergoing topological instability somewhere in the internet. Such topological instability will tend to propagate. In contrast it will be hard to propagate topological instability across network address translators+firewalls. > (this is not intended to offend Cisco in any way but there seems to reason > to clarify their statement towards the IPv6 community) Rather then try to compete with NAT+firewalling, a more incremental way for the IETF to deal with the inadequacies of IPv4 would be to create options for left and right address extensions (a left address extension to indentify internet and a right address extension as a subaddress for NAT). Sometime later the left address extension (internet number) + the IPv4 address + the right address extension (subaddress) could be mapped into an IPv6 address. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 26 15:54:58 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id PAA23664 for ipng-dist; Fri, 26 Jun 1998 15:50:32 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id PAA23651 for ; Fri, 26 Jun 1998 15:50:08 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA12554 for ; Fri, 26 Jun 1998 15:50:05 -0700 Received: from imo16.mx.aol.com (imo16.mx.aol.com [198.81.17.6]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id PAA03063 for ; Fri, 26 Jun 1998 15:50:05 -0700 (PDT) Received: from Telford001@aol.com by imo16.mx.aol.com (IMOv14_b1.1) id PWHNa27696; Fri, 26 Jun 1998 18:49:01 -0400 (EDT) Message-ID: Date: Fri, 26 Jun 1998 18:49:01 EDT To: lixia@CS.UCLA.EDU Cc: tex@isc.upenn.edu, ipng@sunroof.eng.sun.com, Telford001@aol.com Mime-Version: 1.0 Subject: (IPng 5942) Re: Last Call: Internet Protocol, Version 6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 6/26/98 1:22:27 PM Eastern Daylight Time, lixia@CS.UCLA.EDU writes: > As a term project 3 UCLA studnets did a brute force traceroute > measurement last November to "see how big the Internet really is", they > trace-routed to a few thousand randomly selected hosts all around the > world. The finding shows that, from UCLA, > - one can reach majority places within 20 or so hops > - 30 hops get you almost anywhere (the max is 30+ something) > And these results seem more or less consistent with measurments done (by > others) one or two years earlier. Would these hop counts include hops on the yonder side of Network Address Translators+Firewalls? For at least one TTI client it can take 30 hops just to get to the external network. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 26 17:56:38 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id RAA23983 for ipng-dist; Fri, 26 Jun 1998 17:52:04 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id RAA23964 for ; Fri, 26 Jun 1998 17:51:36 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA11084 for ; Fri, 26 Jun 1998 17:51:35 -0700 Received: from blaze-net.com (barry.blaze-net.com [199.103.238.10]) by earth.sun.com (8.8.8/8.8.8) with SMTP id RAA02387 for ; Fri, 26 Jun 1998 17:51:35 -0700 (PDT) Received: from blaze-net.com by blaze-net.com (SMI-8.6/SMI-SVR4) id UAA19932; Fri, 26 Jun 1998 20:59:33 -0400 Message-ID: <35944209.65573215@blaze-net.com> Date: Fri, 26 Jun 1998 20:51:21 -0400 From: Frank Solensky Organization: BlazeNet Inc X-Mailer: Mozilla 4.05 [en] (X11; U; SunOS 5.5.1 i86pc) MIME-Version: 1.0 To: Telford001@aol.com CC: lixia@CS.UCLA.EDU, tex@isc.upenn.edu, ipng@sunroof.eng.sun.com Subject: (IPng 5943) Re: Last Call: Internet Protocol, Version 6 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Telford001@aol.com wrote: > > In a message dated 6/26/98 1:22:27 PM Eastern Daylight Time, lixia@CS.UCLA.EDU > writes: > > > The finding shows that, from UCLA, > > - one can reach majority places within 20 or so hops > > - 30 hops get you almost anywhere (the max is 30+ something) > > Would these hop counts include hops on the yonder side > of Network Address Translators+Firewalls? For at least > one TTI client it can take 30 hops just to get to the > external network. I don't see these as affecting the findings: NATs don't generally change the TTL; firewalls probably wouldn't let the traceroute in. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 23:44:24 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id XAA24154 for ipng-dist; Fri, 26 Jun 1998 23:40:05 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id XAA24147 for ; Fri, 26 Jun 1998 23:39:52 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA20945 for ; Fri, 26 Jun 1998 23:39:52 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id XAA17187 for ; Fri, 26 Jun 1998 23:39:38 -0700 (PDT) From: Masataka Ohta Message-Id: <199806270629.PAA01492@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA01492; Sat, 27 Jun 1998 15:29:43 +0900 Subject: (IPng 5944) Re: Last Call: Internet Protocol, Version 6 To: Telford001@aol.com Date: Sat, 27 Jun 98 15:29:43 JST Cc: tex@isc.upenn.edu, ipng@sunroof.eng.sun.com In-Reply-To: <1b2fc2c4.3592f931@aol.com>; from "Telford001@aol.com" at Jun 25, 98 9:28 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Joachim; > I think > the claim was that RSVP or some similar control or signaling > protocol might need this functionality. But, RSVP can't. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 04:09:11 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id EAA24982 for ipng-dist; Sun, 28 Jun 1998 04:05:53 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id EAA24975 for ; Sun, 28 Jun 1998 04:05:36 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA12018 for ; Sun, 28 Jun 1998 04:05:34 -0700 Received: from imo13.mx.aol.com (imo13.mx.aol.com [198.81.17.3]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id EAA03984 for ; Sun, 28 Jun 1998 04:05:30 -0700 (PDT) Received: from Telford001@aol.com by imo13.mx.aol.com (IMOv14_b1.1) id SEIVa11436; Sun, 28 Jun 1998 07:04:53 -0400 (EDT) Message-ID: <61624a43.35962356@aol.com> Date: Sun, 28 Jun 1998 07:04:53 EDT To: thomas.eklund@era.ericsson.se Cc: ipng@sunroof.eng.sun.com, Telford001@aol.com Mime-Version: 1.0 Subject: (IPng 5946) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 6/27/98 7:20:10 AM Eastern Daylight Time, thomas.eklund@era.ericsson.se writes: > Telford001@aol.com skrev: > > In a message dated 6/26/98 1:23:38 PM Eastern Daylight Time, > > thomas.eklund@era.ericsson.se writes: > > > - Why havent the v6 folks responded more loud to Cisco tactic - when they > > > say to their customers today that v6 doesn't give you anything that we can't > > > fix with v4 and that their NAT solutions solve every problem? > > They are correct. NAT+Firewalling is a very natural way to extend > > IPv4 to a larger address space without the radical changes that > > IPv6 introduces. > That was not my point... Of course it is correct as you say... But my point is > that because Cisco has a very "anti-v6" attitude towards their customers, i. e. > most of the Internet backbone routers that the ISP's have, this tends to increase > the misunderstandings and myths around v6 that in the end could kill it. > And I dont see the difference if you have a NAT/FW that it makes a radical > change if you have v6 internally instead of v4? A major argument for v6 was the need for a larger address space. Adding NAT provides a larger address space. If only the larger address space was needed, the new address formats, unproven host and router implementations, silly ways of doing address resolution, lack of adequate checksumming etc. represent fairly radical changes and large risks. > This is a business issue for v6 and not a technical issue and should not be > brought up here, I know - just interested in people's opinion because to my > opinion this tends to increase people's misunderstanding about v6... > > > I think this > > > is a big obstacle area when it comes to people's understanding about why we > > > need to move as fast as possible to v6 if we want Internet to continue to > > > grow and not solve it with non scalable NAT solutions and people!!! > > > Comments? > > The two level hierarchy that NAT solutions introduce is the common > > way to scale. DECNET was scaled via two level hierarchical routing. > > Likewise the phone network uses hierachical circuit switching > > to scale. The v6 solution is more likely to have scaling problems > > than two level hierarchy with NAT. > I dont agree on this.. Of course you can scale your network with NAT > solutions but compared what you get with and aggregatable hiearchical > address arch is performance... Addresses are aggregatable with v4. NAT+Firewalling removes lots of routes from the routing tables of inner routers. In general, the two level hierarchical routing of DECNET creates much smaller routing tables, a small level 1 routing table within each area and then a small routing table for level 2 routing between areas. Hierarchical routing make it impossible for topological instability in one area to spread to other areas or across hierarchy borders. v6 provides no comparable protection. > You mentioned the phone network - if you > at this kind of systems with millions of subscribers want it to scale with > resonable performance you have to have it native in the protocol and not > with performance killing NAT. We provide NAT+Firewalling with the subscriber edition of the VLAN Router. NAT hardly affects performance at all, and most users of NAT are restricted to speeds of T3 and below anyway. > I think this new v6 address arch. eventually > will be on of the driving force that will make ISP to upgrade their backbone > to v6 because what every one want in the end is performance. This leads > to smaller routing tables IPv6 provides non-hierachical routing. IPv4 extended to a hierarchical architecture provides routing tables at least as small, higher performance, greater topological stability and far less risk. -> faster ip_forwarding, less routing traffic in the > network and because of the streamlined header format - > less processing time per ip packet in the routers (even though you have4 > times bigger addresses) and if you have a fixed basic header and the options in > ext. headers you can also built better HW support for v6 than you can for v4. > This is some simple things that v6 solves that you can't get in v4 with > exstensions (well I know about CIDR but its no where near v6 addr. arch.).. Kastenholz, Solensky and Doria used to make this argument at Clearpoint. Their version of the Clearpoint Constellation LSB Router got about 3000 -- 4000 pps in 1992. After they left the project, we rewrote the logic and fixed lots of bugs. Once we were finished, the modular version got 30,000 -- 40,000 pps, and Bradner ranked the single card version as PC Magazine Editors' Choice in March 1993. I will not mince words on this particular issue. I consider the hardware support argument the last refuge of the incompetent programmer or the result of a lack of understanding of the nature of the packet switching problem. The issue is discussed in Critical Analysis and Archived Analysis. Small Forwarding Tables for Fast Routing Lookups provides valuable analysis that relates to standard contemporary hardware platforms. In the October 1997 Computer Communication Review, Marcel Waldvogel (ETH), George Varghese (Washington University), Jon Turner (Washington University), and Bernhard Plattner (ETH) make the point in "Scalable High Speed IP Routing Lookups"(*) "Thus a CAM based solution (or indeed any hardware solution) runs the risk of being made obselete, in a few years, by software technology running on faster processors and memory." More to the point the cost of receiving packets to memory and then transmitting them from memory overwhelms the time spent in header processing. Spending a few man-years to put table lookups and some header processing into an ASIC is pointless 1) because a good software implementation gets the benefit of man-millennia of development spent on contemporary processors and 2) because unless memory is being implemented in the ASIC the main problem of high performance packet switching remains unaddressed. > > A huge global IPv6 internet > > is practically guaranteed to be undergoing topological > > instability somewhere in the internet. Such topological > > instability will tend to propagate. In contrast it will be > > hard to propagate topological instability across > > network address translators+firewalls. > > > (this is not intended to offend Cisco in any way but there seems to reason > > > to clarify their statement towards the IPv6 community) > > Rather then try to compete with NAT+firewalling, a more > > incremental way for the IETF to deal with the inadequacies > > of IPv4 would be to create options for left and right > > address extensions (a left address extension to indentify > > internet and a right address extension as a subaddress > > for NAT). Sometime later the left address extension > > (internet number) + the IPv4 address + the right address > > extension (subaddress) could be mapped into an > > IPv6 address. Joachim Martillo Telford Tools, Inc. (*)Internet address lookup is a challenging problem because of increasing routing table sizes, increased traffic, higher speed links, and the migration to 128 bit IPv6 addresses. IP routing lookup requires computing the best matching prefix, for which standard solutions like hashing were believed to be inapplicable. The best existing solution we know of, BSD radix tries, scales badly as IP moves to 128 bit addresses. Our paper describes a new algorithm for best matching prefix using binary search on hash tables organized by prefix lengths. Our scheme scales very well as address and routing table sizes increase: independent of the table size, it requires a worst case time of log(address bits) hash lookups; thus only 5 hash lookups are needed for IPv4 and 7 for IPv6. We also introduce Mutating Binary Search and other optimizations that, for a typical IPv4 backbone router with over 33,000 entries, considerably reduce the average number of hashes to less than 2, of which one hash can be simplified to an indexed array access. We expect similar average case behavior for IPv6. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 06:16:58 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id GAA25070 for ipng-dist; Sun, 28 Jun 1998 06:12:43 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id GAA25063 for ; Sun, 28 Jun 1998 06:12:04 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA21463 for ; Sun, 28 Jun 1998 06:12:02 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.8.8/8.8.8) with SMTP id GAA19473 for ; Sun, 28 Jun 1998 06:11:55 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id NA24736; Sun, 28 Jun 1998 23:08:51 +1000 (from kre@munnari.OZ.AU) To: Thomas Eklund Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5947) Re: IPv6 questions In-Reply-To: Thomas Eklund's message of "Fri, 26 Jun 1998 14:27:12 +0100." References: <3.0.32.19980626142710.00af6c40@anchor.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 28 Jun 1998 23:08:47 +1000 Message-Id: <11499.899039327@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 26 Jun 1998 14:27:12 +0100 From: Thomas Eklund Message-ID: <3.0.32.19980626142710.00af6c40@anchor.ericsson.se> | Hi I have a couple of questions that I could not find in the drafts or RFCs: Just a few attempts at answers to some of your questions. The ones I have no answer for I have simply deleted (ignored). | - How does the DNS work with ND? The hope is that Dynamic DNS will make this work - depending upon your environment, either the host will discover its address, and then use DynDNS to update the DNS server (if needed - most times of course the address obtained will be the one it had before), or a DHCP server will allocate an address, and then either the host or the server will update the DNS. | - How does Path MTU discovery work for mobile IPv6 when you change subnet | work and get a new IP adress with ND! The same way it works any time. | It seems to be a bad design to do a new PMTU discovery when you enter | the new subnet. Why? PMTU discovery is a continuous process anyway, you don't do it and forget it. A reasonable approach for a mobile host upon changing nets would be to assume the minimum of the previous PMTU and the MTU of the new link attached to (and unless hardware has changed, that is probably the same as it was before) and then continue to use standard PMTU update procedures to determine if the PMTU should be altered. | Could there a good thing | to let the MTU size propagate up to the router for the subnet and include | it in the RA's? The MTU for what? For the link? That might already be done (I suspect it is but am too lazy to pull out the spec and check). But that's not very useful really - the PMTU depends upon the destination - are you suggesting that routers figure out PMTUs to all possible destinations and advertise them in RAs? | - How does Path MTU discovery works for UDP? The same way it works for TCP. Some current implementations that remember nothing about past UDP packets may have some problems, but that is an implementation issue (it also has not much to do with IPv6, PMTU discovery for v6 isn't any different than for v4, though it is perhaps more important). Some UDP based applications (eg: the DNS) will find PMTU dscovery very difficult, because they send so many isolated packets to so many unrelated destinations (if DNS caching is working, repeat DNS packets are a rarity). Those applications will tend to stay within the guaranteed minimum MTU and hence avoid the necessity for PMTU discovery. | - This is perhaps a stupid question, but what is the need for jumbograms | when you have PMTU? PMTU and jumbograms are unrelated, as far as I can tell. There are some (perhaps many) who question the need for jumbograms at all (regardless of PMTU discovery). The idea is that on hinks with HUGE MTUs, big packets can be sent, and overheads avoided. That is, if your link will let you send MB packets, then it is a nuisance in the extreme if the protocol says no, especially if the hardware to support such huge packets imposes large per packet overheads or delays. | - Might there be a problem for Real time traffic if the IPv6 minimum link | MTU size is increased to 1280? In some cases perhaps, though in practice, those ought to be short term problems. Essentially the only slow links left in the internet are end site PPP style links, everything else is fast enough that the delay caused to wait for a 1280 byte packet is negligible (if you are going to wait for an entire stream of queued packets, and not pre-empt any, then 1280 byte packets mean less per packet overheads and hence a lower overall delay). Even on a 33.6Kb link (if I did the maths right) a 1280 byte packet is just 40ms, which isn't much of a delay for any reasonable protocol to handle. Where there is a requirement that the delays be lower than that, intra-link fragmentation can be created, with the pieces being as small as required. | - just wondering what the objectives were behind that decision? Many. One is the DNS and PMTU discovery, as above. The DNS wants to be able to avoid PMTU discovery, as the cost for that is simply too high. But it also eneds to be able to send reasonably big answers to queries, without needing to resort to TCP connections (which have an even bigger overhead than PMTU discovery). Hence, a minimum MTU big enough for the DNS to be able to contain most answers (including signatures) is needed. Second, bigger MTUs mean less packets, which means less packet switching, and packet switching is a big user of CPU time in routers (only the most expensive are able to switch minimum sized packets at maximal rates, whereas almost anything can switch maximum sized packets without problems). | - Is there any thoughts how to define Any cast addresses for a global scope? Anycast addresses are simply unicast addreses (with known magic at the destination), so scope should be no problem. Other issues related to anycast addresses are still (it seems to me) open issues. One of those is how one handles a TCP connection addressed to an anycast address. | - Have there been anyone looking into defining IPv6 over GigabitEthernet? Is there an issue there? I thought an ethernet was an ethernet was an ethernet (as far as the user was concerned, as opposed to the builder of interface equipment). Is there something IPv6 might need to do any differently for a Gigabit Ethernet than it would for 10Mbit or 100Mbit? | - Is there anyone who had a evaluation why the HW can be built much easier | than for v4? One simple one is that there are no longer header checksums to update when the hop count (was TTL) is updated (or source route pointers adjusted, etc), which should allow much simpler hardware to perform the routing functions. | - Why havent the v6 folks responded more loud to Cisco tactic - when they | say to their customers today that v6 doesn't give you anything that we cant | fix with v4 and that their NAT solutions solve every problem? Hmm. Perhaps because most of us are not into marketing... (including those here who are from cisco). Further, it would be silly to attempt to claim that (however evil NAT is) that it doesn't extend the address space, as clearly it does. However, no matter how much NAT is pushed, IPv4 still has an absolute limit (assuming no wastage at all, which itself is absurd) of 2^32 (4 billion) connections to the NAT free area. That's of the order of just one per person on the planet now, which today is enough, probably, but when the population has increased a bit more, and access to computing is even more widespread, then this will clearly not be enough. What's more, I don't think any of the knowledgable NAT as an alternative to IPv6 proponents really believe, or claim, that NAT can avoid the need for IPv6 (or some replacement to IPv4). Some, at least, are hoping that NAT will delay the need long enough that something other than IPv6 can be developed - for some the need is to get rid of any fixed sized address, and allow truly variable addressing, which is more or less guaranteed never to be able to run out. The IPv6 claim is that 128 bits is in fact enough that it will never run out (or not anytime when doing so will be relevant), as it allows for 2^48 organisations to be connected, each one being (potentially) about as bit as a current class A network (16 million hosts) - and possibly much bigger (there's address space for each to be 2^80, but realistically, 2^16 subnets each of which we might assume could reasonably connect 256 hosts - some would say many more, others many less, but that seems like a reasonable guess). 2^48 organisations is a very large number indeed (an organisation for this purpose could be a company or educational institution, etc, it could also be a whole ISP and all of its dial in type customers, each of whom might need only 2^64 address space... allowing 64K customers). 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 Jun 28 08:45:11 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id IAA25165 for ipng-dist; Sun, 28 Jun 1998 08:38:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id IAA25156 for ; Sun, 28 Jun 1998 08:38:35 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA28283 for ; Sun, 28 Jun 1998 08:38:34 -0700 Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.161]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA12231 for ; Sun, 28 Jun 1998 08:38:33 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.8.8/8.8.8) id RAA11336; Sun, 28 Jun 1998 17:38:16 +0200 (MET DST) From: Ignatios Souvatzis Message-Id: <199806281538.RAA11336@theory.cs.uni-bonn.de> Subject: (IPng 5948) Re: ARP sniffing In-Reply-To: <3.0.32.19980625192059.00683cd0@telos.ca> from "M. Coltart/L Hupman" at "Jun 25, 98 07:21:04 pm" To: colt@reach.net (M. Coltart/L Hupman) Date: Sun, 28 Jun 1998 17:38:15 +0200 (MET DST) Cc: ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I am a relative newbie to the LINUX/UNIX world. > I am running a RedHat 5.1 system with TCP/IP wrappers on a "cable" ISP > network. > All R host protocols and auto mounts and NFS/NIS are turned off and Hosts > allow and deny are configured and working with inetd.conf. > A NetBSD system in the same subnet as ours (last two in our IP is 35.48 > theirs is 34.79) keeps showing up in our ARP. > > The Op of the other system claims this is a feature of their UDP. > They first tried portmapping in at the ypserv and the mountd. > Which they corrected when I called them up and gave them a blast now this > ARP thing keeps coming back after I delete it from the cache > it shows up a coupl of seconds later. Uhm... if I understand correctly what you tell us, your system is just putting the sender data of the NetBSD machines' ARP request into your ARP cache. (ARP requests are broadcast.) To verify this is what happens, you might want to use a packet sniffer (like tcpdump on BSD machines): If I'm right, you would see - your ARP table does not contain the NetBSD system - you see an "ARP who-has" packet from the NetBSD system - now you see the NetBSD system in your ARP table [Btw... this is a pure-IPv4 problem...] Regards, Ignatios Souvatzis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 20:24:39 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id UAA25430 for ipng-dist; Sun, 28 Jun 1998 20:16:41 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id UAA25423 for ; Sun, 28 Jun 1998 20:16:33 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA06376 for ; Sun, 28 Jun 1998 20:16:32 -0700 Received: from imo21.mx.aol.com (imo21.mx.aol.com [198.81.17.65]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id UAA13550 for ; Sun, 28 Jun 1998 20:16:32 -0700 (PDT) Received: from Telford001@aol.com by imo21.mx.aol.com (IMOv14_b1.1) id 9BFJa12330; Sun, 28 Jun 1998 23:12:56 +2000 (EDT) Message-ID: <6d2fb226.3597063a@aol.com> Date: Sun, 28 Jun 1998 23:12:56 EDT To: kre@munnari.OZ.AU, thomas.eklund@era.ericsson.se Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 5949) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 6/28/98 9:37:39 AM Eastern Daylight Time, kre@munnari.OZ.AU writes: > | It seems to be a bad design to do a new PMTU discovery when you enter > | the new subnet. > Why? PMTU discovery is a continuous process anyway, you don't do it > and forget it. A reasonable approach for a mobile host upon changing > nets would be to assume the minimum of the previous PMTU and the MTU of > the new link attached to (and unless hardware has changed, that is probably > the same as it was before) and then continue to use standard PMTU update > procedures to determine if the PMTU should be altered. > | Could there a good thing > | to let the MTU size propagate up to the router for the subnet and include > | it in the RA's? > The MTU for what? For the link? That might already be done (I suspect it > is but am too lazy to pull out the spec and check). But that's not very > useful really - the PMTU depends upon the destination - are you suggesting > that routers figure out PMTUs to all possible destinations and advertise them > in RAs? > | - How does Path MTU discovery works for UDP? > The same way it works for TCP. Some current implementations that remember > nothing about past UDP packets may have some problems, but that is an > implementation issue (it also has not much to do with IPv6, PMTU discovery > for v6 isn't any different than for v4, though it is perhaps more important). > Some UDP based applications (eg: the DNS) will find PMTU dscovery very > difficult, because they send so many isolated packets to so many unrelated > destinations (if DNS caching is working, repeat DNS packets are a rarity). > Those applications will tend to stay within the guaranteed minimum MTU and > hence avoid the necessity for PMTU discovery. I am familiar with Path MTU discovery procedures on three versions of Unix. As I understand the algorithm, the host does MTU discovery. The path MTU is entered into the route table. Eventually, the MTU times out or a packet too large (DF causes drop in IPv4) comes back from the network (perhaps the path changes due to alternate routing or load sharing) and a new MTU is established. Looking at the code, I do not see where the higher layers or application receives notification if the path MTU changes, and if there is no packet about to be sent. On sending a packet that is too large for the current path MTU an EMSGSIZE is propagated up the stack. But suppose a bunch of messages are queued for transmission, and while these messages are being transmitted, the packet too large ICMP message comes back. In the implementation at which I am looking, the MTU in the route table is changed, but no indication of the error is propagated up the stack. Unless some sort of retransmission mechanism is built into the IPv6 layer, it looks like the logic just depends on higher protocol layer or application time outs to guarantee that the data gets retransmitted in packets with sizes less than the new path MTU. This situation implies that to use PATH MTU while avoiding dependence on O(second) timers -- something that seems bad -- path MTU discovery must be performed before the transmission of each packet and the application must be careful to push each packet so that packets do not hang around on kernel queues with the result that the path MTU could change before the packets are actually transmitted. A reasonable approach to dealing with the problem which did not depend on per packet path MTU discovery and individual packet push or upper layer timers would be for the IPv6 router to fragment the packet as if it had undergone host fragmentation send the packet forward and send the ICMP notification backward. Joachim Carlo Santos Martillo Ajami -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 21:55:15 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id VAA25529 for ipng-dist; Sun, 28 Jun 1998 21:50:46 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id VAA25522 for ; Sun, 28 Jun 1998 21:50:37 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA12702 for ; Sun, 28 Jun 1998 21:50:36 -0700 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id VAA05384 for ; Sun, 28 Jun 1998 21:50:37 -0700 (PDT) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id XAA24093 for ; Sun, 28 Jun 1998 23:50:36 -0500 (CDT) Comments: ( Received on motgate.mot.com from client mothost.mot.com, sender harsha@miel.mot.com ) Received: from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by mothost.mot.com (8.8.5/8.6.10/MOT-3.8) with SMTP id XAA09293 for ; Sun, 28 Jun 1998 23:50:30 -0500 (CDT) Received: from ajanta.miel.mot.com by hpux4.miel.mot.com with SMTP id AA16025 (5.67b/IDA-1.6 for ipng@sunroof.eng.sun.com); Mon, 29 Jun 1998 10:13:11 +0500 Received: from miel.mot.com by ajanta.miel.mot.com (SMI-8.6/SMI-SVR4) id KAA24058; Mon, 29 Jun 1998 10:20:19 +0530 Message-Id: <35971A53.FDD5B932@miel.mot.com> Date: Mon, 29 Jun 1998 10:08:43 +0530 From: Sriharsha J X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: "Telford001@aol.com" Cc: "thomas.eklund@era.ericsson.se" , "ipng@sunroof.eng.sun.com" Subject: (IPng 5950) Re: IPv6 questions References: <61624a43.35962356@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Telford001@aol.com wrote: > In a message dated 6/27/98 7:20:10 AM Eastern Daylight Time, > > > That was not my point... Of course it is correct as you say... But my point > is > > that because Cisco has a very "anti-v6" attitude towards their customers, > i. e. > > most of the Internet backbone routers that the ISP's have, this tends to > increase > > the misunderstandings and myths around v6 that in the end could kill it. > > > And I dont see the difference if you have a NAT/FW that it makes a radical > > change if you have v6 internally instead of v4? > > A major argument for v6 was the need for a larger address space. Adding > NAT provides a larger address space. If only the larger address space > was needed, the new address formats, unproven host and router implementations, > silly ways of doing address resolution, lack of adequate checksumming etc. > represent fairly radical changes and large risks. NAT doesn't provide a larger address space, it only creates an illusion oflarger address space. Since NAT only gives a TEMPORARY address to any host, those hosts can not act as a server. Even though no. of such hosts are small, the way internet growing we will eventually run out of addresses. NAT is not an elegant solution at all. NAT ONLY works for hierarchical routing. So the router acting as the head-end of the lower-level network becomes a bottleneck. > > You mentioned the phone network - if you > > at this kind of systems with millions of subscribers want it to scale with > > resonable performance you have to have it native in the protocol and not > > with performance killing NAT. > > We provide NAT+Firewalling with the > subscriber edition of > the > VLAN Router. > NAT hardly affects performance at all, and > most users of NAT are restricted to speeds of T3 and > below anyway. > NAT does affect performance. You also have to take into considerationembedded addresses in FTP, ICMP, etc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 02:12:57 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id CAA25805 for ipng-dist; Mon, 29 Jun 1998 02:08:33 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id CAA25798 for ; Mon, 29 Jun 1998 02:08:25 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA11532 for ; Mon, 29 Jun 1998 02:08:23 -0700 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by earth.sun.com (8.8.8/8.8.8) with SMTP id CAA07159 for ; Mon, 29 Jun 1998 02:08:23 -0700 (PDT) Received: from sp3at21.hursley.ibm.com by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20278; Mon, 29 Jun 1998 10:08:20 +0100 Received: from hursley.ibm.com (carpenterb.hursley.ibm.com [9.20.22.153]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7) with ESMTP id KAA159462; Mon, 29 Jun 1998 10:08:19 +0100 (BST) Message-Id: <359759A3.4B341556@hursley.ibm.com> Date: Mon, 29 Jun 1998 10:08:51 +0100 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: Thomas Eklund Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5951) Re: IPv6 questions References: <3.0.32.19980626142710.00af6c40@anchor.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Eklund wrote: > > - This is perhaps a stupid question, but what is the need for jumbograms > when you have PMTU? The main idea is to use them to get very high bulk data throughput om very fat pipes (multi Gigabits), where the practical limit is not the line speed, but the per-packet host CPU overhead. This would mainly be for point-to-point applications, i.e. router-free networks, in applications such as ultra high speed data acquisition. ... > > - Is there anyone who had a evaluation why the HW can be built much easier > than for v4? The header fields are carefully 64-bit aligned which is supposed to help hardware designers. > - Is there anyone who know about the big operators link MCI, Sprint, > Nordunet etc if they have put up a date on their agenda when they start > providing native v6 in their backbones? > - Why havent the v6 folks responded more loud to Cisco tactic... We don't talk about companies' business plans or tactics in the IETF. But you might look at draft-ietf-iab-case-for-ipv6-01.txt Brian Carpenter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 07:59:23 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id HAA26006 for ipng-dist; Mon, 29 Jun 1998 07:51:39 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id HAA25999 for ; Mon, 29 Jun 1998 07:51:22 -0700 (PDT) From: MOSTHAVM@plcman.siemens.co.uk Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA11671 for ; Mon, 29 Jun 1998 07:51:18 -0700 Received: from ariane.sni.co.uk ([194.42.250.68]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA22688 for ; Mon, 29 Jun 1998 07:51:18 -0700 (PDT) Received: from manpost001.sni.co.uk (manpost001.sni.co.uk [137.223.63.12]) by ariane.sni.co.uk (8.8.8/8.8.7) with ESMTP id PAA18218 for ; Mon, 29 Jun 1998 15:50:32 +0100 (BST) Received: by manpost001.sni.co.uk with Internet Mail Service (5.0.1460.8) id ; Mon, 29 Jun 1998 15:55:11 +0100 Message-ID: To: ipng@sunroof.eng.sun.com Subject: (IPng 5952) Re: IPv6 questions Date: Mon, 29 Jun 1998 15:55:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > And I dont see the difference if you have a NAT/FW that it makes a > radical > > > change if you have v6 internally instead of v4? Isn't that the whole idea? Radical changes would be counter productive. IPv6 is designed as direct evolutionary development from IPv4, not anything radical new. It's just something to cater for additional needs as for example larger address space and better maintainability. You will agree that maintaing an additional device such as NAT does not make live easier but harder (additional work). Marc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 09:18:48 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id JAA26076 for ipng-dist; Mon, 29 Jun 1998 09:12:48 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id JAA26069 for ; Mon, 29 Jun 1998 09:12:39 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA28572 for ; Mon, 29 Jun 1998 09:12:37 -0700 Received: from imo28.mx.aol.com (imo28.mx.aol.com [198.81.17.72]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA07960 for ; Mon, 29 Jun 1998 09:12:37 -0700 (PDT) Received: from Telford001@aol.com by imo28.mx.aol.com (IMOv14_b1.1) id PBBUa17153; Mon, 29 Jun 1998 12:12:19 -0400 (EDT) Message-ID: <92b872e6.3597bce5@aol.com> Date: Mon, 29 Jun 1998 12:12:19 EDT To: MOSTHAVM@plcman.siemens.co.uk Cc: ipng@sunroof.eng.sun.com, Telford001@aol.com Mime-Version: 1.0 Subject: (IPng 5953) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 6/29/98 11:15:35 AM Eastern Daylight Time, MOSTHAVM@plcman.siemens.co.uk writes: > > > > And I dont see the difference if you have a NAT/FW that it makes a > > > > radical change if you have v6 internally instead of v4? > Isn't that the whole idea? Radical changes would be counter productive. IPv6 > is designed as direct evolutionary development from IPv4, not anything > radical new. It's just something to cater for additional needs as for > example larger address space and better maintainability. You will agree that > maintaing an additional device such as NAT does not make live easier but > harder (additional work). Obviously we have fairly different ideas of evolutionary change. 1) Completely changing the IP header (including making it longer and removing checksumming), 2) Moving address resolution procedures to the virtual network layer (as if it makes sense to resolve IP address to ethernet and X.25 addresses in the same way), 3) Completely changing the addressing structure and 4) Introducing unenforceable and probably harmful rules with respect to fragmentation sure look like fairly radical changes, and I am unsure what qualifies them as evolutionary. Introducing two new IP options, an IP subaddress option (right address extension) and an internet identification option (left address extension) would have constituted minor feature additions that satisfied the needs for a larger address space, interoperated with with NAT+Firewalling and provided a means to avoid the topological instability problems that have appear as the Internet has become larger. The comment about a separate NAT device is uncorrelated. NAT is just another router feature as far as I am concerned. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 29 09:59:21 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id JAA26179 for ipng-dist; Mon, 29 Jun 1998 09:51:01 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with ESMTP id JAA26172 for ; Mon, 29 Jun 1998 09:50:41 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with ESMTP id JAA21231 for ; Mon, 29 Jun 1998 09:50:39 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA07837 for ipng@sunroof.eng.sun.com; Mon, 29 Jun 1998 09:49:51 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id EAA24475 for ; Sat, 27 Jun 1998 04:20:11 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA13168 for ; Sat, 27 Jun 1998 04:20:03 -0700 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id EAA20642 for ; Sat, 27 Jun 1998 04:20:03 -0700 (PDT) Received: from era-t.ericsson.se (era-t.ericsson.se [147.214.173.8]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/glacier-1.11) with SMTP id NAA18094; Sat, 27 Jun 1998 13:20:02 +0200 (MET DST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id NAA03886; Sat, 27 Jun 1998 13:20:00 +0200 Message-ID: <3594D4FE.72EB0BAA@era.ericsson.se> Date: Sat, 27 Jun 1998 13:18:23 +0200 From: "thomas.eklund@era.ericsson.se" Organization: Ericsson Radio Systems AB X-Mailer: Mozilla 4.03 [sv] (Win95; I) MIME-Version: 1.0 To: Telford001@aol.com CC: ipng@sunroof.eng.sun.com Subject: (IPng 5954) Re: IPv6 questions References: <9656cb1.35940725@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Telford001@aol.com skrev: > In a message dated 6/26/98 1:23:38 PM Eastern Daylight Time, > thomas.eklund@era.ericsson.se writes: > > > - Why havent the v6 folks responded more loud to Cisco tactic - when they > > say to their customers today that v6 doesn't give you anything that we cant > > fix with v4 and that their NAT solutions solve every problem? > > They are correct. NAT+Firewalling is a very natural way to extend > IPv4 to a larger address space without the radical changes that > IPv6 introduces. > That was not my point... Of course it is correct as you say... But my point is that because Cisco has a very "anti-v6" attitude towards their customers, i.e. most of the Internet backbone routers that the ISP's have, this tends to increase the misunderstandings and myths around v6 that in the end could kill it. And I dont see the difference if you have a NAT/FW that it makes a radical change if you have v6 internally instead of v4? This is a business issue for v6 and not a technical issue and should not be brought up here , I know - just interested in people's opinion because to my opinion this tends to increase people's misunderstanding about v6... > > I think this > > is a big obstacle area when it comes to people's understanding about why we > > need to move as fast as possible to v6 if we want Internet to continue to > > grow and not solve it with non scalable NAT solutions and people!!! > Comments? > > The two level hierarchy that NAT solutions introduce is the common > way to scale. DECNET was scaled via two level hierarchical routing. > Likewise the phone network uses hierachical circuit switching > to scale. The v6 solution is more likely to have scaling problems > than two level hierarchy with NAT. I dont agree on this.. Of course you can scale your network with NAT solutions but compared what you get with and aggregatable hiearchical addres arch is performance... You mentioned the phone network - if you at this kind of systems with millions of subscribers want it to scale with resonable performance you have to have it native in the protocol and not with performance killing NAT.I think this new v6 address arch. eventually will be on of the driving force that will make ISP to upgrade their backbone to v6 because what every one want in the end is performance. This leads to smaller routing tables -> faster ip_forwarding, less routing traffic in the network and because of the streamlined header format -> less processing time per ip packet in the routers (even though you have4 times bigger addresses) and if you have a fixed basic header and the options in ext. heders you can also built better HW support for v6 than you can for v4. This is some simple things that v6 solves that you can't get in v4 with exstensions (well I know about CIDR but its no where near v6 addr. arch.).. > A huge global IPv6 internet > is practically guaranteed to be undergoing topological > instability somewhere in the internet. Such topological > instability will tend to propagate. In contrast it will be > hard to propagate topological instability across > network address translators+firewalls. > > > (this is not intended to offend Cisco in any way but there seems to reason > > to clarify their statement towards the IPv6 community) > > Rather then try to compete with NAT+firewalling, a more > incremental way for the IETF to deal with the inadequacies > of IPv4 would be to create options for left and right > address extensions (a left address extension to indentify > internet and a right address extension as a subaddress > for NAT). Sometime later the left address extension > (internet number) + the IPv4 address + the right address > extension (subaddress) could be mapped into an > IPv6 address. > > Joachim Martillo > Telford Tools, Inc. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 13:40:26 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id NAA26459 for ipng-dist; Mon, 29 Jun 1998 13:31:33 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id NAA26452 for ; Mon, 29 Jun 1998 13:31:12 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA14340 for ; Mon, 29 Jun 1998 13:31:08 -0700 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA11556 for ; Mon, 29 Jun 1998 13:31:06 -0700 (PDT) Received: from era-t.ericsson.se (era-t.ericsson.se [147.214.173.8]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/glacier-1.11) with SMTP id WAA13666; Mon, 29 Jun 1998 22:31:05 +0200 (MET DST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id WAA01979; Mon, 29 Jun 1998 22:30:58 +0200 Message-ID: <3597F917.A8E805E7@era.ericsson.se> Date: Mon, 29 Jun 1998 22:29:11 +0200 From: "thomas.eklund@era.ericsson.se" Organization: Ericsson Radio Systems AB X-Mailer: Mozilla 4.03 [sv] (Win95; I) MIME-Version: 1.0 To: Telford001@aol.com CC: ipng@sunroof.eng.sun.com Subject: (IPng 5955) Re: IPv6 questions References: <61624a43.35962356@aol.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by earth.sun.com id NAA11556 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id NAA26453 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > ... > > And I dont see the difference if you have a NAT/FW that it makes a radical > > change if you have v6 internally instead of v4? > > A major argument for v6 was the need for a larger address space. Adding > NAT provides a larger address space. If only the larger address space > was needed, the new address formats, unproven host and router implementations, > silly ways of doing address resolution, lack of adequate checksumming etc. > represent fairly radical changes and large risks. > Lack adquate checksumming... Dont see that as a radical change - rather a big improvement:-)I dont say that NAT has it places in a big network - what I am saying is that it no solution to the address problem in the near future... Dont agree either that v6 is a radical change - I mean it is still the Internet Protocol!!! Much of the code in the kernel can be reused... > More to the point the cost of receiving packets to memory > and then transmitting them from memory overwhelms the > time spent in header processing. Spending a few man-years > to put table lookups and some header processing into an > ASIC is pointless > I will never agree on this:-) There is though other worlds than tradional TCP based datacom networks... Ever heard about wireless??? I'm not meaning to be offensive ehre just stating that there exsist other types of networks which has other requirements on delay and processing capacity... > 1) because a good software implementation gets the > benefit of man-millennia of development spent on > contemporary processors and > 2) because unless memory is being implemented > in the ASIC the main problem of high performance > packet switching remains unaddressed. > Had never said anything else:-) For Instance Pink et Al and their Luleå algoritm has shown indredible result in of improving routing lookups in SW and there are others... > (*)Internet address lookup is a challenging problem > because of increasing routing table sizes, increased > traffic, higher speed links, and the migration to 128 > bit IPv6 addresses. IP routing lookup requires > computing the best matching prefix, for which > standard solutions like hashing were believed to be > inapplicable. The best existing solution we know of, > BSD radix tries, scales badly as IP moves to 128 bit > addresses. Our paper describes a new algorithm for > best matching prefix using binary search on hash tables > organized by prefix lengths. Our scheme scales very > well as address and routing table sizes increase: > independent of the table size, it requires a worst > case time of log(address bits) hash lookups; thus > only 5 hash lookups are needed for IPv4 and 7 for > IPv6. We also introduce Mutating Binary Search > and other optimizations that, for a typical IPv4 > backbone router with over 33,000 entries, > considerably reduce the average number of > hashes to less than 2, of which one hash can > be simplified to an indexed array access. We > expect similar average case behavior for IPv6. Interesting is the result documented anywhere? Best Regards Thomas Eklund, Ericsson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 14:15:26 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id OAA26645 for ipng-dist; Mon, 29 Jun 1998 14:08:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id OAA26637 for ; Mon, 29 Jun 1998 14:08:15 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA25187 for ; Mon, 29 Jun 1998 14:08:12 -0700 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA02901 for ; Mon, 29 Jun 1998 14:08:12 -0700 (PDT) Received: from era-t.ericsson.se (era-t.ericsson.se [147.214.173.8]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/glacier-1.11) with SMTP id XAA17444; Mon, 29 Jun 1998 23:08:12 +0200 (MET DST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id XAA03655; Mon, 29 Jun 1998 23:08:09 +0200 Message-ID: <359801D2.8D57548@era.ericsson.se> Date: Mon, 29 Jun 1998 23:06:26 +0200 From: "thomas.eklund@era.ericsson.se" Organization: Ericsson Radio Systems AB X-Mailer: Mozilla 4.03 [sv] (Win95; I) MIME-Version: 1.0 To: Brian E Carpenter CC: ipng@sunroof.eng.sun.com Subject: (IPng 5956) Re: IPv6 questions References: <3.0.32.19980626142710.00af6c40@anchor.ericsson.se> <359759A3.4B341556@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter skrev: > Thomas Eklund wrote: > > > > - This is perhaps a stupid question, but what is the need for jumbograms > > when you have PMTU? > > The main idea is to use them to get very high bulk data throughput > om very fat pipes (multi Gigabits), where the practical limit > is not the line speed, but the per-packet host CPU overhead. This > would mainly be for point-to-point applications, i.e. router-free > networks, in applications such as ultra high speed data acquisition. > ... > > > > - Is there anyone who had a evaluation why the HW can be built much easier > > than for v4? > > The header fields are carefully 64-bit aligned which is supposed > to help hardware designers. > I know but I was wondering if someone had written a academic report about the issues... because I think this is a really interesting topic.. Ok a quick list ofI think -Hierchical address arch. leads to smaller routing tables -> faster ip_forwarding, less routing traffic in the network -> less memory required or in other wordsmore efficient use of the memory -Because of the streamlined header format that aligns on 64 bits boundary->less processing time per ip packet in the routers (even though you have4 times bigger addresses) and if you have a fixed basic header and the options in ext. headers you can also built better HW support for v6 than you can for v4 -Removal of the checksum in default Is there any other strong reason that the HW can be built easier? I posted for one and a half year ago results from peformance measurements on these issues and a lot of other people responded that they have noticed the same behaviour, that v6 has sligtly better perfomance over a LAN than v4 - and I think this is a really strong argument if this is a common behaviour over other links... > > - Is there anyone who know about the big operators link MCI, Sprint, > > Nordunet etc if they have put up a date on their agenda when they start > > providing native v6 in their backbones? > Could this be an issue for NGTrans or 6bone to set up such a BOF? > > - Why havent the v6 folks responded more loud to Cisco tactic... > > We don't talk about companies' business plans or tactics in the IETF. > But you might look at draft-ietf-iab-case-for-ipv6-01.txt I know and I'm sorry if I wasted peoples time...:-)But what I want to stress is that here in v6 I consider some of the Cisco guys as gurus and really infuential to the WG and I get confused when their marketing guys gives a message that Cisco does not belive in v6 for a LONG time... But I also understand that Cisco is a big company and everyone can't know about everyone in such a company... They are not alone with these problem - that the technicians and marketing guys are out of sycnc. Best Regards Thomas Eklund, Ericsson Radio Systems AB > Brian Carpenter > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 --------------------------------------------------------------------