From owner-ipng@sunroof.eng.sun.com Tue Sep 1 07:49:31 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA02919 for ipng-dist; Tue, 1 Sep 1998 07:44:06 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA02912 for ; Tue, 1 Sep 1998 07:43:55 -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 HAA20535 for ; Tue, 1 Sep 1998 07:43:53 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA01329 for ; Tue, 1 Sep 1998 07:43:54 -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 KAA23342; Tue, 1 Sep 1998 10:43:50 -0400 (EDT) Message-Id: <199809011443.KAA23342@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6391) I-D ACTION:draft-ietf-ipngwg-site-prefixes-02.txt Date: Tue, 01 Sep 1998 10:43:49 -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 : Site prefixes in Neighbor Discovery Author(s) : E. Nordmark Filename : draft-ietf-ipngwg-site-prefixes-02.txt Pages : 19 Date : 31-Aug-98 This document specifies extensions to IPv6 Neighbor Discovery to carry site prefixes. The site prefixes are used to reduce the effect of site renumbering by ensuring that the communication inside a site uses site-local addresses. This protocol requires that all IPv6 implementations, even those that do not implement this protocol, ignore all site-local addresses that they retrieve from the DNS. 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-site-prefixes-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-site-prefixes-02.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-site-prefixes-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980831163950.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-site-prefixes-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-site-prefixes-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980831163950.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 Tue Sep 1 09:03:52 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA03003 for ipng-dist; Tue, 1 Sep 1998 08:59:04 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id IAA02996 for ; Tue, 1 Sep 1998 08:58:45 -0700 (PDT) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id IAA09828; Tue, 1 Sep 1998 08:58:41 -0700 (PDT) Date: Tue, 1 Sep 1998 08:58:41 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6392) Re: Security hole in 6over4 To: Cyndi Jung Cc: Richard Draves , "'Erik Nordmark'" , Brian E Carpenter , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3.0.32.19980831171300.00f61d54@pop.nsd.3com.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The filter for protocol 41 would break that, and force all v6 communication > through v6 routers. I count that as a loss - I'm not sure what the > network administrator would count it as. Do you have an alternative proposal that would close the security hole? (Without a fix for it I can't see recommending folks to deploy 6over4 since it would allow any node on the IPv4 Internet to e.g. invalidate their IPv6 addresses.) 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 Sep 1 09:20:44 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA03032 for ipng-dist; Tue, 1 Sep 1998 09:14:24 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA03025 for ; Tue, 1 Sep 1998 09:14: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 JAA13016; Tue, 1 Sep 1998 09:13:56 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id JAA23692; Tue, 1 Sep 1998 09:13:54 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id LAA19343; Tue, 1 Sep 1998 11:13:52 -0500 Message-Id: <199809011613.LAA19343@gungnir.fnal.gov> To: Erik Nordmark Cc: Cyndi Jung , Richard Draves , Brian E Carpenter , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 6393) Re: Security hole in 6over4 In-reply-to: Your message of Tue, 01 Sep 1998 08:58:41 PDT. Date: Tue, 01 Sep 1998 11:13:52 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've been pondering this very slowly, and the least-ugly idea I've come up with is to require ALL ND traffic to be wrapped in IPv4 multicast even when it is IPv6 unicast. Unicast ND would have to be mapped via the IPv6 solicited-node address to the appropriate IPv4 multicast address. Timers set by RA fields should be chosen with this necessity in mind. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 1 09:22:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA03057 for ipng-dist; Tue, 1 Sep 1998 09:20:03 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA03050 for ; Tue, 1 Sep 1998 09:19:53 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA12874 for ; Tue, 1 Sep 1998 09:19:52 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA18412 for ipng@sunroof.eng.sun.com; Tue, 1 Sep 1998 09:18:38 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA02196 for ; Mon, 31 Aug 1998 17:14:54 -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 RAA11797; Mon, 31 Aug 1998 17:14:51 -0700 Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA14877; Mon, 31 Aug 1998 17:14:52 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id RAA15862; Mon, 31 Aug 1998 17:14:42 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id RAA27259; Mon, 31 Aug 1998 17:14:42 -0700 (PDT) Received: from tdc97.ops.3com.com (pnl-entp-14.OPS.3Com.COM [139.87.12.94]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id RAA18856; Mon, 31 Aug 1998 17:14:41 -0700 (PDT) Message-Id: <3.0.32.19980831171300.00f61d54@pop.nsd.3com.com> X-Sender: cmj@pop.nsd.3com.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 31 Aug 1998 17:13:01 -0700 To: Richard Draves , "'Erik Nordmark'" , Brian E Carpenter From: Cyndi Jung Subject: (IPng 6394) Re: Security hole in 6over4 Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think this was the idea: Align the v6-over-v4 subnet with the administrative boundary for IPv4 multicast. I would expect that to coincide with the IPv4 site boundary in most cases, but it might turn out to fall within the site or encompass multiple sites. But the use of admin scoping just limits the set of stations that can participate in a single v6overv4 subnet - it doesn't limit the set of systems that can send a v6 frame encapsulated in v4 into this subnet. I had been hoping that a variant of NHRP could be used here to establish "cut-through tunnels" through the IPv4 domain - that communication between IPv6 systems could take longest possible IPv4 hops to shorten their IPv6 path and benefit from the higher performance of IPv4. So long as there are no NATs in the way (or only "helpful" NATs, whatever that may be), the tunnel could be constructed from longest unobstructed IPv4 paths, often resulting in tunnels directly between the communicating end-stations. The filter for protocol 41 would break that, and force all v6 communication through v6 routers. I count that as a loss - I'm not sure what the network administrator would count it as. Cyndi Jung At 03:07 PM 8/31/98 -0700, Richard Draves wrote: >> To close this hole I think you have to make sure that the boundary >> of the 6over4 link doesn't "leak" packets. >> This can be done by, in addition to configuring the IPv4 >> multicast routing >> admin scope boundary, also having a filter (i.e. discard) all >> IPv4 packets >> with protocol = 41. > >I think this is the simplest solution. The downside of course is that it >prevents other v6-over-v4 tunnels from traversing the site boundary. Many >administrators might view that as an advantage. > >Rich >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 1 12:22:43 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA03361 for ipng-dist; Tue, 1 Sep 1998 12:11:44 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA03354 for ; Tue, 1 Sep 1998 12:11: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 MAA14351 for ; Tue, 1 Sep 1998 12:11:28 -0700 Received: from om2.gto.net.om (om2.gto.net.om [206.49.101.40]) by earth.sun.com (8.9.1/8.9.1) with SMTP id MAA20449 for ; Tue, 1 Sep 1998 12:11:28 -0700 (PDT) Received: from default(as9-63.gto.net.om[209.58.12.65]) (2165 bytes) by om2.gto.net.om via sendmail with P:esmtp/R:inet_hosts/T:smtp (sender: ) id for ; Tue, 1 Sep 1998 23:07:04 +0400 (OMAN) (Smail-3.2.0.102 1998-Aug-2 #21 built 1998-Aug-20) Message-ID: <35EC4772.51AC8F02@gto.net.om> Date: Tue, 01 Sep 1998 23:13:55 +0400 From: Peter Dawson X-Mailer: Mozilla 4.0 [en] (Win95; I) MIME-Version: 1.0 To: Matt Crawford CC: Erik Nordmark , Cyndi Jung , Richard Draves , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: (IPng 6396) Re: Security hole in 6over4 X-Priority: 3 (Normal) References: <199809011613.LAA19343@gungnir.fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk what happens if the router is running DVRMP ?? will not the router chk the source address of packet and dest of the source in forwarding table to revel which interface it would use to forward the packet. If the packet arrived on the interface that was the path to the source the router then would replicat the packet on all other interfaces correct ?? i.e farward the packet.. otherwise the packet is discarded.. can't the same analogy be used here to close this hole ?? just a thought :) /Pete Matt Crawford wrote: > I've been pondering this very slowly, and the least-ugly idea > I've > come up with is to require ALL ND traffic to be wrapped in IPv4 > > multicast even when it is IPv6 unicast. Unicast ND would have > to be > mapped via the IPv6 solicited-node address to the appropriate > IPv4 > multicast address. Timers set by RA fields should be chosen > with > this necessity in mind. > Matt > > ------------------------------------ > ------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: > http://playground.sun.com/ipng > FTP archive: > ftp://playground.sun.com/pub/ipng > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > ----------------------------- > -------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 1 14:58:24 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA03542 for ipng-dist; Tue, 1 Sep 1998 14:49:57 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id OAA03534 for ; Tue, 1 Sep 1998 14:49:36 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA28566 for ; Tue, 1 Sep 1998 14:49:35 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id OAA19148 for ipng@sunroof.eng.sun.com; Tue, 1 Sep 1998 14:48:23 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA03336 for ; Tue, 1 Sep 1998 11:43:06 -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 LAA05037; Tue, 1 Sep 1998 11:43:00 -0700 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA01955; Tue, 1 Sep 1998 11:42:57 -0700 (PDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA27906; Tue, 1 Sep 1998 11:42:56 -0700 (PDT) mail_from (sm@neteng.engr.sgi.com) Received: from neteng.engr.sgi.com (neteng.engr.sgi.com [192.26.80.10]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA32451; Tue, 1 Sep 1998 11:42:53 -0700 (PDT) mail_from (sm@neteng.engr.sgi.com) Received: (from sm@localhost) by neteng.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA61616; Tue, 1 Sep 1998 11:42:42 -0700 (PDT) From: sm@neteng.engr.sgi.com (Sam Manthorpe) Message-Id: <199809011842.LAA61616@neteng.engr.sgi.com> Subject: (IPng 6397) Re: Security hole in 6over4 To: Erik.Nordmark@Eng Date: Tue, 1 Sep 1998 11:42:42 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: from "Erik Nordmark" at Sep 1, 98 08:58:41 am X-Mailer: ELM [version 2.4 PL24 ME5a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The filter for protocol 41 would break that, and force all v6 communication > > through v6 routers. I count that as a loss - I'm not sure what the > > network administrator would count it as. > > Do you have an alternative proposal that would close the security hole? > (Without a fix for it I can't see recommending folks to deploy > 6over4 since it would allow any node on the IPv4 Internet to e.g. invalidate > their IPv6 addresses.) Is there a useful case when a 6over4 link is used between two nodes on the same net and packets from the peer need to be recognised as coming from the local net (i.e. hl=255)? Otherwise, wouldn't counting the 6over4 link as a `hop' and having the decapsulation mechanism decrement the hop limit solve the problem? -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 1 16:09:49 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA03677 for ipng-dist; Tue, 1 Sep 1998 16:01:36 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id QAA03670 for ; Tue, 1 Sep 1998 16:01:30 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id QAA08694 for ; Tue, 1 Sep 1998 16:00:56 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id PAA19340 for ipng@sunroof.eng.sun.com; Tue, 1 Sep 1998 15:59:43 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA03643 for ; Tue, 1 Sep 1998 15:52: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 PAA29955; Tue, 1 Sep 1998 15:52:14 -0700 Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA26878; Tue, 1 Sep 1998 15:52:15 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id PAA21912; Tue, 1 Sep 1998 15:52:05 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id PAA09344; Tue, 1 Sep 1998 15:52:04 -0700 (PDT) Received: from tdc97.ops.3com.com (pnl-entp-14.OPS.3Com.COM [139.87.12.94]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id PAA12610; Tue, 1 Sep 1998 15:52:04 -0700 (PDT) Message-Id: <3.0.32.19980901155024.00d615d0@pop.nsd.3com.com> X-Sender: cmj@pop.nsd.3com.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 01 Sep 1998 15:50:25 -0700 To: Peter Dawson , Matt Crawford From: Cyndi Jung Subject: (IPng 6399) Re: Security hole in 6over4 Cc: Erik Nordmark , Richard Draves , Brian E Carpenter , ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think the incoming interface in this case is the local IPv4 process, to which any physical interface can deliver. I also think that the concern here is from ND packets sent into the 6over4 subnet from the outside. Outside in this case means that the source IP address falls in a different administrative space with respect to multicast. If the v6 packets are wrapped in v4 multicast, I would expect that the multicast routers on the border of the administrative domain would not forward the packet. As Matt suggested, it would be the v6 packets that are wrapped in unicast that could get into the subnet and so do damage. How would the perpetrator acquire the v4 address of the system it is attempting to destroy? DNS would probably be helpful - assume that a system with both a v4 address and a v6 address has this functionality. Perhaps this is a good reason to completely eliminate the option of running ND over non-multicast IPv4 domains - declare that to be a security risk, as well as a non-scalable solution, and promote the use of v4 multicast from SHOULD to MUST. Cyndi At 11:13 PM 9/1/98 +0400, Peter Dawson wrote: >what happens if the router is running DVRMP ?? will not the >router chk the source address >of packet and dest of the source in forwarding table to revel >which interface it would use >to forward the packet. If the packet arrived on the interface >that was the path to the source >the router then would replicat the packet on all other interfaces >correct ?? i.e farward the packet.. otherwise the packet is >discarded.. can't the same analogy be used here to close this >hole ?? > >just a thought :) > >/Pete > >Matt Crawford wrote: > >> I've been pondering this very slowly, and the least-ugly idea >> I've >> come up with is to require ALL ND traffic to be wrapped in IPv4 >> >> multicast even when it is IPv6 unicast. Unicast ND would have >> to be >> mapped via the IPv6 solicited-node address to the appropriate >> IPv4 >> multicast address. Timers set by RA fields should be chosen >> with >> this necessity in mind. >> Matt >> >> ------------------------------------ >> ------------------------------- >> IETF IPng Working Group Mailing List >> IPng Home Page: >> http://playground.sun.com/ipng >> FTP archive: >> ftp://playground.sun.com/pub/ipng >> Direct all administrative requests to >> majordomo@sunroof.eng.sun.com >> ----------------------------- >> -------------------------------------- > > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 2 18:47:15 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id SAA04813 for ipng-dist; Wed, 2 Sep 1998 18:32:23 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id SAA04806 for ; Wed, 2 Sep 1998 18:32:08 -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 SAA27995 for ; Wed, 2 Sep 1998 18:32:04 -0700 Received: from iolite.hknet.com (iolite.hknet.com [202.67.240.87]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA04708 for ; Wed, 2 Sep 1998 18:31:55 -0700 (PDT) Received: from topaz.hknet.com (topaz.hknet.com [202.67.240.226]) by iolite.hknet.com (8.8.5/8.8.5) with ESMTP id JAA17601 for ; Thu, 3 Sep 1998 09:31:10 +0800 (HKT) Received: from fourier (mp1320.hknet.com [202.67.251.84]) by topaz.hknet.com (8.8.5/8.8.5) with SMTP id JAA18256 for ; Thu, 3 Sep 1998 09:47:19 +0800 (HKT) From: "Eric Ho" To: "Ipng (E-mail)" Subject: (IPng 6402) IPv6 field trails Date: Thu, 3 Sep 1998 09:36:52 +0800 Message-ID: <000301bdd6db$53f18140$fd2790a9@fourier.fore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal Disposition-Notification-To: "Eric Ho" X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Could anyone please advise if there is any site running IPv6 in a large scale? Just like to see how commercial sites think of IPv6 deployment. eh ============================================================== Eric Ho eric.ho@computer.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 3 02:06:31 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id BAA04980 for ipng-dist; Thu, 3 Sep 1998 01:59:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id BAA04973 for ; Thu, 3 Sep 1998 01:59: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 BAA21228 for ; Thu, 3 Sep 1998 01:59:26 -0700 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA19747 for ; Thu, 3 Sep 1998 01:59:26 -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 KAA14437 for ; Thu, 3 Sep 1998 10:59:25 +0200 (MET DST) Received: from rcur98nbn173w.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA15339; Thu, 3 Sep 1998 10:59:22 +0200 Message-Id: <3.0.1.32.19980903105442.0071238c@anchor.ericsson.se> X-Sender: eratekd@anchor.ericsson.se X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 03 Sep 1998 10:54:42 +0200 To: ipng@sunroof.eng.sun.com From: Thomas Eklund Subject: (IPng 6403) Prefix allocation over PPP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, there was a debate in last IETF meeting about prefix allocation over PPP links and the need for a new protocol. My question cant you do that today with small modifications? I mean if the router on the foreign network requests an IPv6 prefix by sending a IPCP message to the "home router", the home router gets an IPv6prefixes from a DHCPv6 server and sends it back to the host in the IPCP message??? So what you need is to define a new IPCP option for v6 that requests all prefixes on your home net (something like home prefix discovery)?? And the response is sent back in the IPCP message after either contacted the DHCP server or done something similiar to "home agent discovery" that is done in MIPv6 but for prefixes (prefix discovery?). Comments. /Regards Thomas Eklund, Ericsson Radio Systems -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 3 09:45:51 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA05522 for ipng-dist; Thu, 3 Sep 1998 09:37:22 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA05515 for ; Thu, 3 Sep 1998 09:37:06 -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 JAA07097 for ; Thu, 3 Sep 1998 09:37:02 -0700 Received: from neonet_server1.nexabit.com (neonetserver1.nexabit.com [209.6.34.254]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA27124 for ; Thu, 3 Sep 1998 09:36:58 -0700 (PDT) Received: by neonet_server1.nexabit.com with Internet Mail Service (5.0.1457.3) id ; Thu, 3 Sep 1998 12:36:57 -0400 Message-ID: <1180113EC576D011AADE0060975B88B3284B58@neonet_server1.nexabit.com> From: Dimitry Haskin To: Thomas Eklund , ipng@sunroof.eng.sun.com Subject: (IPng 6405) RE: Prefix allocation over PPP Date: Thu, 3 Sep 1998 12:36:55 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, I think what you're asking can be accomplished without modifications to IP6CP. In the IP6CP phase of PPP, both systems at the endpoints of a PPP link learn their link-local IPv6 addresses. Upon completion of PPP initialization the IPv6 node on one end of the PPP link should be able to communicate with the PPP Server/router on the other end of the link using IPv6. Thus the node can solicit whatever services can be provided by the PPP Server/router at the home network. In addition, if I am not missing something, the "home router" can send ND Router Advertisements over the PPP link to the foreign network. Am I lost? Dimitry On Thursday, September 03, 1998 4:55 AM, Thomas Eklund [SMTP:thomas.eklund@era.ericsson.se] wrote: > Hi, > there was a debate in last IETF meeting about prefix allocation over PPP > links and the need for a new protocol. > My question cant you do that today with small modifications? > I mean if the router on the foreign network requests an IPv6 prefix by > sending a IPCP message to the "home router", the home router gets an > IPv6prefixes from a DHCPv6 server and sends it back to the host in the IPCP > message??? > So what you need is to define a new IPCP option for v6 that requests all > prefixes on your home net (something like home prefix discovery)?? And the > response is sent back in the IPCP message after either contacted the DHCP > server or done something similiar to "home agent discovery" that is done > in MIPv6 but for prefixes (prefix discovery?). > > Comments. > > /Regards > Thomas Eklund, Ericsson Radio Systems > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- ------------------------------------------------------------------------ ------------------------------------- Dimitry Haskin Nexabit Networks, Inc. http://www.nexabit.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 4 03:17:59 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id DAA06501 for ipng-dist; Fri, 4 Sep 1998 03:15:05 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id DAA06490 for ; Fri, 4 Sep 1998 03:14:54 -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 DAA12424 for ; Fri, 4 Sep 1998 03:14:52 -0700 Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA00079 for ; Fri, 4 Sep 1998 03:14:53 -0700 (PDT) Received: from hpsgnrg.sgp.hp.com (hpsgnrg.sgp.hp.com [15.68.50.194]) by palrel3.hp.com (8.8.6 (PHNE_14041)/8.8.5tis) with ESMTP id DAA29512 for ; Fri, 4 Sep 1998 03:15:51 -0700 (PDT) Received: from hpsgnrg.sgp.hp.com (localhost [127.0.0.1]) by hpsgnrg.sgp.hp.com with ESMTP (8.7.1/8.7.1) id SAA26569 for ; Fri, 4 Sep 1998 18:10:54 +0800 (SGP) Message-ID: <35EFBCAE.3F0027D2@hpsgnrg.sgp.hp.com> Date: Fri, 04 Sep 1998 18:10:54 +0800 From: Mullaparthi Chandrashekhar Organization: Myself X-Mailer: Mozilla 4.05 [en] (X11; I; HP-UX B.10.20 9000/777) MIME-Version: 1.0 To: IPNG Mailing list Subject: (IPng 6408) OSI Addressing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I don't know if this is the right place to ask this question. I'm trying to understand OSI addressing. I know that for Internet addressing, an IP address and a port is enough to uniquely identify a connection end-point in a process. What is the equivalent in OSI addressing?? Should I read ACSE in detail to understand this?? TIA, Chandru -- HP, Telecom Mgmt. Division. / +65-2792881 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 4 07:57:26 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA06697 for ipng-dist; Fri, 4 Sep 1998 07:50:31 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA06690 for ; Fri, 4 Sep 1998 07:50:20 -0700 (PDT) From: bmanning@ISI.EDU 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 HAA14119 for ; Fri, 4 Sep 1998 07:50:13 -0700 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA03269 for ; Fri, 4 Sep 1998 07:50:13 -0700 (PDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id HAA00589; Fri, 4 Sep 1998 07:50:02 -0700 (PDT) Posted-Date: Fri, 4 Sep 1998 07:44:59 -0700 (PDT) Message-Id: <199809041444.AA17541@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Fri, 4 Sep 1998 07:44:59 -0700 Subject: (IPng 6409) Re: OSI Addressing To: chandru@hpsgnrg.sgp.hp.com (Mullaparthi Chandrashekhar) Date: Fri, 4 Sep 1998 07:44:59 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <35EFBCAE.3F0027D2@hpsgnrg.sgp.hp.com> from "Mullaparthi Chandrashekhar" at Sep 4, 98 06:10:54 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Hi all, > > I don't know if this is the right place to ask this question. > > I'm trying to understand OSI addressing. I know that for Internet > addressing, an IP address and a port is enough to uniquely identify > a connection end-point in a process. > > What is the equivalent in OSI addressing?? Should I read ACSE in detail > to understand this?? > > TIA, > Chandru There are any number of OSI addressing methods. Two that come to mind are NSAPs and e.164 addresses. Have to you read any materials on either of these two addressing methods? -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 4 11:07:18 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA07008 for ipng-dist; Fri, 4 Sep 1998 10:57:23 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA07001 for ; Fri, 4 Sep 1998 10:57:08 -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 KAA02024 for ; Fri, 4 Sep 1998 10:56:43 -0700 Received: from host.ott.igs.net (host.ott.igs.net [206.248.16.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA20854 for ; Fri, 4 Sep 1998 10:56:44 -0700 (PDT) Received: from [206.248.17.2] (ttyA07.ott.igs.net [206.248.17.9]) by host.ott.igs.net (8.8.5/8.6.12) with ESMTP id NAA04645; Fri, 4 Sep 1998 13:54:10 -0400 (EDT) X-Sender: kgk@host.igs.net Message-Id: In-Reply-To: <35EFBCAE.3F0027D2@hpsgnrg.sgp.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 4 Sep 1998 14:00:54 -0400 To: Mullaparthi Chandrashekhar From: Keith Knightson Subject: (IPng 6410) Re: OSI Addressing Cc: IPNG Mailing list Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Chandru, You should read ISO standard IS 8348, which is quite readable and comprehensive. Regards Keith At 6:10 AM -0400 04/9/98, Mullaparthi Chandrashekhar wrote: >Hi all, > > I don't know if this is the right place to ask this question. > > I'm trying to understand OSI addressing. I know that for Internet > addressing, an IP address and a port is enough to uniquely identify > a connection end-point in a process. > > What is the equivalent in OSI addressing?? Should I read ACSE in detail > to understand this?? > >TIA, >Chandru > >-- > >HP, Telecom Mgmt. Division. / +65-2792881 >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 4 12:44:07 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA07207 for ipng-dist; Fri, 4 Sep 1998 12:31:21 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA07200 for ; Fri, 4 Sep 1998 12:31:08 -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 MAA29544 for ; Fri, 4 Sep 1998 12:30:35 -0700 Received: from gateway.gtech.com (gateway.gtech.com [156.24.1.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id MAA13139 for ; Fri, 4 Sep 1998 12:30:34 -0700 (PDT) Received: (qmail 21156 invoked from network); 4 Sep 1998 19:30:12 -0000 Received: from ops.soft.gtech.com (156.24.33.7) by gateway.mis.gtech.com with SMTP; 4 Sep 1998 19:30:12 -0000 Received: from ccgate.gtech.com (ccgate.mis.gtech.com [156.24.68.157]) by ops.soft.gtech.com (8.8.8/8.8.8) with SMTP id PAA24389 for ; Fri, 4 Sep 1998 15:30:11 -0400 (EDT) Received: from ccMail by ccgate.gtech.com (IMA Internet Exchange 3.01 Enterprise) id 00056B84; Fri, 4 Sep 98 15:27:27 -0400 Mime-Version: 1.0 Date: Fri, 4 Sep 1998 13:53:00 -0400 Message-ID: <00056B84.CE21428@gtech.com> From: vtulli@gtech.com (Victor R. Tulli) Subject: (IPng 6411) Re: OSI Addressing To: chandru@hpsgnrg.sgp.hp.com (Mullaparthi Chandrashekhar), bmanning@ISI.EDU Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Last time I looked (a few years ago), OSI addressing was described in: International Standard ISO 7498-3 Information processing systems -- Open Systems Interconnection -- Basic Reference Model -- Part 3: Naming and addressing. and in International Standard ISO/IEC 8348 Information technology -- Open Systems Interconnection -- Network Service Definition -- Annex A Network Layer Addressing. These documents were obtainable from GLOBAL ENGINEERING DOCUMENTS 2805 McGaw Ave. Irvine, CA 92714 714-261-1455 800-854-7179 Good Luck. Vic Tulli ______________________________ Reply Separator _________________________________ Subject: (IPng 6409) Re: OSI Addressing Author: bmanning@ISI.EDU at Internet Date: 09/04/1998 7:44 AM > > Hi all, > > I don't know if this is the right place to ask this question. > > I'm trying to understand OSI addressing. I know that for Internet > addressing, an IP address and a port is enough to uniquely identify > a connection end-point in a process. > > What is the equivalent in OSI addressing?? Should I read ACSE in detail > to understand this?? > > TIA, > Chandru There are any number of OSI addressing methods. Two that come to mind are NSAPs and e.164 addresses. Have to you read any materials on either of these two addressing methods? -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 4 13:04:25 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA07254 for ipng-dist; Fri, 4 Sep 1998 12:53:44 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA07247 for ; Fri, 4 Sep 1998 12:53: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 MAA04048 for ; Fri, 4 Sep 1998 12:53:29 -0700 Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA24166 for ; Fri, 4 Sep 1998 12:53:30 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id MAA26038; Fri, 4 Sep 1998 12:43:49 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id MAA28589; Fri, 4 Sep 1998 12:43:48 -0700 (PDT) Received: from tdc97.ops.3com.com (pnl-entp-14.OPS.3Com.COM [139.87.12.94]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id MAA29812; Fri, 4 Sep 1998 12:43:44 -0700 (PDT) Message-Id: <3.0.32.19980904124209.00ad7a64@pop.nsd.3com.com> X-Sender: cmj@pop.nsd.3com.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 04 Sep 1998 12:42:13 -0700 To: Mullaparthi Chandrashekhar , IPNG Mailing list From: Cyndi Jung Subject: (IPng 6412) Re: OSI Addressing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In OSI addressing, each layer has a method for identifying a client residing in the layer above. These are called -Selectors, for a given layer , and the "connection end-point" at that layer is called a Service Access Point. The full address at any layer is formed by concatenating these layer-specific identifiers from all lower layers in sequence to form an SAP Address. The lowest layer to be included in this end-to-end addressing is the Network Layer, hence NSAP Address identifies services that are clients of the Network Layer by the last octet of the NSAP Address, the N-Selector. The leading octets of the address are similar in use to an IP address (long discussion omitted). There are some "well-known" values for N-Selectors - as I recall, the N-Selector value 00 addresses the network layer protocols, ES-IS, IS-IS, IDRP, the value 01 addresses the OSI transport layer, 06 was assigned by the IETF for TCP (TUBA), DEC used other values to select the DECNET-IV transport. At the OSI transport layer, the T-Selector value assignments were never globally managed, and really didn't need to be since the Directory could store them. The clients of TCP fall into two classes - the OSI Session Layer and everything else. In the OSI Session Layer there is an S-selector that identifies the client, which at this point is almost always the OSI Presentation Layer (except for the really old X.400 stuff that predated the Presentation and ACSE protocols). The Presentation Layer has further demultiplexing called Presentation Context, which is actually not included in the Presentation Address - now you have moved into the realm of Presentation Context, Abstract Syntax, Concrete Syntax (encoding, usually BER (Basic Encoding Rules for Abstract Syntax Notation One, ASN.1), Application Context, and more grandiose stuff I can't quite remember clearly. But the addressing ends with the PSAP Address, which gets you to the Service Access Point. I should point out here again that these selectors have local meaning, and are very flexible. For example, we made a terminal server speak ISO Virtual Terminal, and it used the P-Selectors to identify the RS232 port (in TCP/IP/TELNET, either an IP address or a TCP port other than 23 had to be used to select an RS232 port). Other systems that would spawn processes to handle terminal sessions had no such use for the P-selector, and would assign T-Selector values to identify the application - it all depended on where the demultiplexing point best fit the system, and when the Session Layer and above was bundled with the application, the T-Selector worked just fine. ISODE is an example of an implementation on Unix that demultiplexed at the T-Selector. I should say here that these OSI addresses only appeared during the connection set-up time, and only the NSAP Address appeared in the ensuing data packets. The OSI Transport allocated connection ID's, each end picking a convenient number and telling it's peer. In all the OSI Session uses I was ever involved with, there were no per-connection ID's carried in the Session layer header - it was a convenient marker for the beginning of the Presentation header that identified which application layer protocol the packet was for/from, ACSE or the functional application (FTAM, VTP, X.500). A sniffer had to capture the Session Layer CONNECT REQ/RESP pair (which carried the CONNECT/ASSOCIATE info from all higher layers) to have a prayer of decoding the following data packets. Security through Obscurity. It is a shame that you really have to sit down with the full set of protocol specifications to figure this out. The OSI Model document really didn't put it into focus for me, and I'm not sure that what I wrote above is sufficiently clear for you, but then how important is it? Surely this is all just history. Cyndi At 06:10 PM 9/4/98 +0800, Mullaparthi Chandrashekhar wrote: >Hi all, > > I don't know if this is the right place to ask this question. > > I'm trying to understand OSI addressing. I know that for Internet > addressing, an IP address and a port is enough to uniquely identify > a connection end-point in a process. > > What is the equivalent in OSI addressing?? Should I read ACSE in detail > to understand this?? > >TIA, >Chandru > >-- > >HP, Telecom Mgmt. Division. / +65-2792881 >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 4 13:04:45 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA07271 for ipng-dist; Fri, 4 Sep 1998 12:59:06 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA07264 for ; Fri, 4 Sep 1998 12:58:56 -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 MAA05441 for ; Fri, 4 Sep 1998 12:58:50 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA26984 for ; Fri, 4 Sep 1998 12:58:52 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id MAA06634; Fri, 4 Sep 1998 12:58:51 -0700 (PDT) Message-Id: <3.0.5.32.19980904125721.00b10ba0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 04 Sep 1998 12:57:21 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6413) Draft IPng Meeting Minutes Cc: hinden@iprg.nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk These have a few rough spots, but I thought it would be good to get them out today. Please send me corrections. I hope to send out the final version early next week. Bob ------------------------------------------------------------------------ IPng Meeting Chicago IETF August 25 & 27, 1998 Bob Hinden / Nokia, Co-Chair Steve Deering / Cisco, Co-Chair Minutes taken and edited by Bob Hinden ------------------------------------------------------------------------ Introduction / S. Deering ------------------------- S. Deering introduced the meeting. Review Agenda / S. Deering -------------------------- TUESDAY, August 25, 1998, 1545-1800 Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) UNH Interoperability Testing Report / W. Lenharth (5 min) Document Status / R. Hinden (10 min) New Documents to Draft Standard / R. Hinden (5 min) IPv6 Address Assignment Status / R. Hinden, R. Fink (10 min) IPv6 over NBMA & IPv6 over ATM Status / M. Jork (10 min) Mobile IPv6 Status / D. Johnson (10 min) Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering (15 min) IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter, C. Jung (30 min) DNS Extension to Support IP Version 6 / M. Crawford (30 min) PPP Extension for Prefix Allocation / K. Yamamoto THURSDAY, August 27, 1998, 0900-1130 Jumbograms / S. Deering (15 min) Maximum header length (or minimum assured payload length) / M. Ohta (15 min) & Make PMTUD purely optional Router Renumbering / M. Crawford (15 min) Multicast Listener Discovery Protocol / S. Deering (10 min) IPv6 Naming interoperabilty issues / J. Paugh (15 min) Should <...-bsd-frag-00.txt> added to Advanced API / M. Andrews IP Address Allocation Ideas / Maarc Blanchet UNH Interoperability Testing Report / W. Lenharth ------------------------------------------------- Test period last week. Eight session. Unique, two dozen representing dozen implementations. RFC conformance testing plus routing. ....Telbit, Sun, Wide, Hitachi, MS Research, IBM, .... Three routers, one hosts, six machines that were both. Ran BGP4. Some serious problems, some OK. Next test period Connecthateon 99. Will being intensive testing. Next test period next summer. Document Status / R. Hinden --------------------------- RFC Published RFC 2373 IP Version 6 Addressing Architecture (PS) RFC 2374 An IPv6 Aggregatable Global Unicast Address Format (PS) RFC 2375 IPv6 Multicast Address Assignments (Info) IESG Approved for Draft Standard IPv6 Specification ICMPv6 Path MTU Discovery for IPv6 Neighbor Discovery for IP Version 6 (IPv6) IPv6 Stateless Address Autoconfiguration Deering reported that there will be a new version of the ICMPv6 draft to fix some editorial oversights, before submission for publication as RFC. IESG Approved for Proposed Standard MIB for IPv6: UDP MIB for IPv6: TCP IESG Approved for Informational Proposed TLA and NLA Assignment Rules IESG Approved for Experimental IPv6 Testing Address Allocation IESG Previously Approved / Waiting for RFC publication MIB for IPv6: Textual Conventions & General Group (PS) MIB for IPv6: ICMPv6 Group (PS) IPv6 over PPP (PS) IPv6 Testing Address Allocation (Experimental) IPv6 Packets over Token Ring Networks (PS) Generic Packet Tunneling in IPv6 Specification (PS) IPv6 Packets over FDDI Networks (PS) IPv6 Packets over Ethernet Networks (PS) IETF Last Call completed for Proposed Standard IP Header Compression / Nov 97 Submitted to IESG for Proposed Standard IPv6 Router Alert Option - IESG wants to reconcile w/ IPv4 Router Alert IPng Working Group Last Call Completed for Proposed Standard Router Renumbering for IPv6 IPng Working Group Last Call Completed for Experimental IPv6 Name Lookups Through ICMP Carpenter also noted the Business Case for IPv6 draft, originally a Bay Networks whitepaper, most recently edited by Charlie Perkins, to eventually be published as an IAB document. Solicits review from ipngwg. We will do a WG Last Call when Charlie gives the go-ahead. ACTION: Document editor will issue a w.g. last call when author give the go ahead. New Documents to Draft Standard / R. Hinden ------------------------------------------- - Start Planning Next Set of Document for Draft Standard - Possible Candidates Addressing Architecture Aggregation Formats IPv6 over Ethernet, FDDI, TR, PPP Others? - Next Step is to Collect Implementation Information ACTION: Document editor will start process to advance Addressing Architecture, Aggregation format, and IPv6over to Draft Standard. Will also recommend any other documents currently at Proposed Standard. IPv6 Address Assignment Status / R. Hinden, R. Fink --------------------------------------------------- Address Assignment Status - "Proposed TLA/NLA Assignment Rules" o Updated based on comments from LA IETF o Presented Approach at RIPE Meeting in Stockholm o Revised based on comments received at RIPE Meeting o Revised based on email comments - Submitted to IESG for "Informational" Status o IESG Approved on 18 Aug 1998 Next Steps - Plan is for TLA/NLA Assignment Rules to become New IANA Document - First Requests made to Registries for Sub-TLA Assignments Bob Fink reported that the following IPv6 sub-TLA requests have been made: uunet-uk to RIPE-NCC ESnet to ARIN WIDE to APNIC - Primary intent of these initial requests is to assist registries in setting up their process and in interpreting the TLA/NLA rules. - We are NOT trying to start an Sub-TLA "Land Rush". - If you NEED an IPv6 Sub-TLA AND are familiar with the "Rules" RFC, please proceed, otherwise wait. IPv6 over NBMA & IPv6 over ATM Status / M. Jork ----------------------------------------------- ION WG Last call ended - draft-ietf-ion-ipv6-01.txt - draft-ietf-ion-atm-02.txt - draft-ietf-ion-fr-00.txt - draft-ietf-ion-ind-00.txt Issues around IPv6 over ATM in PVC mode raised by the WIDE project have been resolved one week after the last IETF. New ND option number in needs official blessing. Document editor reported that he has put together "tentative" assignments for this and other pending requests (e.g., IPv6 options, ICMPv6 types, etc.). These have been sent to the IANA. Expects them to be approved in a few weeks. ACTION: Put the "tentative" assignments on the IPng web site until the IANA publish them. Mobile IPv6 Status / D. Johnson ------------------------------- Changes in the latest Mobile IPv6 Draft Completed Mobile IP w.g. last call. [getslides] Modified prefix Information Option Format - On Router Advertisement: +----- | | | +----- - New flag bit Router Address (R) - Set toindicate... New Home Agent Information Option Format +----- | | | +----- - Allows home agent to advertise values about itself: o Prefrenence: Signed value (default 0) used for sorting reply list for dynamic home agent address discovery Receiving Packet while Away from Home - IPv6 suggest that nodes MAY reverse received Routing header for response packets (if authenticated) - But for mobile nodes away from home this is bad: o Routing header... Address Scope Issues - Packet addressed to a mobile node's site-local address o Consensus is SHOULD be forwarded while away from home o But this behavior MUST be configurable to disable it o This default might change as "sites" and site-local addresses become better defined - Multicast packet swith link-local < scope < global o Same as site-local unicast above o This default.... Binding Lifetime Rules - New rules specified to limit lifetimes: o On primary care-of-address registration - Home agent MUST reduce lifetime to no greater than remaining prefix lifetime o When sending a Binding Update - Mobile node MUST NOT send lifetime.... Renumbering the Home Network - Home agent watches for "important" Router Advertisements o The preferred or valid lifetime for ran existing prefix on the home link is reduced o A new prefix is introduced on the home link o State of home agent's AdvManagedFlag flag changes - When any of these occur: o xxxx Question about implementation experience. Currently CMU (adding current IPSEC (FreeBSD), Lancaster university (Linux), National Univ. of Singapore (Linux). Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering --------------------------------------------------------------- Which part of Address Space to Reserve? - Many official and unofficial Uses of low-numbered interface ID's o End os a point-point link o Tunnel endpoints o Manually configured unicast addresses when a hardware token is not available for the network interface. o Manually configured static addresses for each of the routers on a link. - Not possible in practice to "reserve" them for a new use (anycast). Thus reserve high end of space, not low end. Reserved Subnet Anycast Addresses - Reserve highest 128 interface ID values for subnet anycast - Reserved subnetanycast addresses format: n bits 121-n 7 bits +-----------------------------+-----------+------------+ | subnet prefix |1111...1111| anycast ID | +-----------------------------+-----------+------------+ - The anycast ID identifies a particular reserved anycast addresses within the subnet prefix: Decimal Hex Description ------- ------ ------------- 127 7F Reserved 126 7E Mobile IPv6 Home-Agents anycast 0-125 00-7D - Reserved in EVERY prefix on ALL links. How Many Addresses to Reserve - Minimum size of interface ID is currently undefined in IPv6 - We don't want to change that with this draft - But minimum size of interface ID must be bigger than reserved part of space: o Some part if interface ID space is for anycast o Rest of space allows some unicast addresses o Reserving 128 addresses allow 1-byte interface ID's - Careful management retains additional flexibility: o xxxx Is 127 the correct size? Suggestions? Discussion: Deering added that the issue was what is min size of interface ID. Do we think that we may have Interface ID's that are smaller than 64 bits. Nordmark: Could we move boundary to get more if we need them. Discussion about how many to have. Not strong opinion to change size. Size will be kept 127. Problem w/ bit flip, will be fixed in new version of draft. ACTION: Document editor will issue a w.g. last call after new draft is out. IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter, C. Jung ------------------------------------------------------------- Work started out in IPng, moved to NGTRANS because was related to transition, but now back here because is another cast of IPover document. Needs to be standardized in IPng w.g. - Uses IPv4 mullticast (on site) as virtual multicast LAN. - No changes of IPv6 model - Just another IPv6over Two implementations currently - Microsoft Research on NT - UCLA on FreeBSD Any issues? Advance to Proposed Standard? Question and discussion about default MTU size. Suggestion to reduce to 1460 to allow tunneling / options / etc. Discussion. Decision to leave as is. ACTION: Document editor will issue a w.g. last call after new draft is out. DNS Extension to Support IP Version 6 / M. Crawford ---------------------------------------------------- Status of -ipngwg-dns-lookups-01 - Merges dns-lookups-00 and aaaa-03. o Modified AAAA RDATA format, discussed to death in L.A. - 128 bits + prefix length + prefix DNS name - Address space delegations rely on new DNS features o Binary labels - Longest match lookups no longer needed o DNAME RR - Ready for W.G. last call MUSTs and SHOULDs - AAAA prefix name MUST NOT indicate a AAAA w/ a longer prefix. (Equal is OK). o No good way to signal an error, so offending record MUST be ignored; others may exist. o Suggest zone maintainers run a check. - Address delegations SHOULD all be through DNAME, never NS. - SUGGEST using the tag "ipv6" uniformly in the reverse zones. Examples X.EXAMPLE is dual-homed to A & B; A is dual-homed to C & D. $ORIGIN X.EXAMPLE wwww AAAA ::1234::567:9ABC:DEF0 64 subnet-1.ip6 subnet-1.ip6 AAAA 0:0:0:1:: 48 ip6 ip6 AAAA 0::0 48 subscriber-x.ip6.A.NET. AAAA 0::0 48 subscriber-x.ip6.B.NET. \[x0001/16].ip6 DNAME subnet-1.ip6 \[x123456789ABCDEF0].subnet-1.ip6 PTR www $ORIGIN ip6.A.NET subscriber-x AAAA 0:0:0011:: 40 A.NET.ip6.C.NET. AAAA 0:0:0011:: 40 A.NET.ip6.D.NET. \[x11/8] DNAME ip6.X.EXAMPLE. Usage/Deployment Notes - Higher and lower network entities (e.g., provider and site) must agree on a name like "subscriber-x" to hold the delegated prefix bits, or ... - Binary label corresponding to the delegated bits themselves could be used for that o Then the lower zone would have to be touched when renumbered, but this might be fair exchange for the unification of forward and reverse delegation data. No issues raised. Question about phase in v.s. flash cut over. When will this DNS code be available. 6BONE issue? ACTION: Document editor will issue a w.g. last call when new draft is out. PPP Extension for Prefix Allocation / Kazu Yamamoto -------------------------------------------------------------- IPv6CP extension for prefix allocation +--------+--------+ | IPv4 | IPv6 | +--------+--------+ | IPCP | IPV6CP | +--------+--------+ | LCP | +-----------------+ - IPCP can allocate only one IPv4 address - In IPv6 environment, we want more! - Prefix allocation is necessary - New IPV6CP option for prefix allocation Question about could ND be used to do this instead? Could use this to report prefixes? Wasn't sure. Might be a possibility. IPV6CP Prefix Options - Common format for Request and ACK +-------+-------+-------+---------+ | Type | Lengt | Res. | Entry # | +-------+-------+-------+---------+ | Reserved | Pref Len| +-----------------------+---------+ | Valid Lifetime | \ +---------------------------------+ | | Preferred Lifetime | | +---------------------------------+ | Entry | IPv6 Prefix 0-3 | | +---------------------------------+ | | IPv6 Prefix 4-7 | / +---------------------------------+ | next entry | | | Discussion. Question asked is prefix permanent or does it go away when the PPP connection is down? Or how is prefix refreshed when lifetime expires? Would like prefix to be permanent. If approved for PPP, we should also do this for DHCP (e.g., allocation prefix). Maybe not a good idea. Point made that Router Renumbering could be used for this as well. Not good to have multiple ways to do the same thing. Better to use current mechanism. Needs further discussion. ------------------------------------------------ THURSDAY, August 27, 1998, 0900-1130 ------------------------------------------------ Jumbograms / S. Deering ----------------------- When IESG advanced base IPv6 spec from Proposed Standard to Draft Standard, one issue the IESG had was that there wasn't enough implementation experience w/ the Jumbogram option. The option was removed from the base spec and published as a new internet draft. Deering added some text to describe some error cases that were not handled in the original text. Encourages people to do more real testing w/ this option. The chairs plan is to submit the new draft for Proposed Standard and to request Draft Standard status once interoperability has been demonstrated. Report from Kevin Lahey (NASA Ames) that they have it running on NetBSD and would like to do testing w/ other implementations. They could also host testing w/ other implementations. Maximum header length (or minimum assured payload length) & Make PMTUD purely optional / M. Ohta (15 min) ---------------------------------------------------------------------- Limit Maximum Header Lengths ---------------------------- The Header Length Problem - Header Length + Playload length <= Reconstruction Buffer Size (1500 or ...) - Fragmentation does not help - TCP does not work if headers before the TCP header >= 1480 - DNS assumes minimally assured Payload length of 512 (though with a wrong estimate of UDP header length) - Not all headers are under application control Proposal - Allow Transport Protocols assure minimum payload length (after transport header) of 1024 by making transport header length <= 64) - Limit Maximum Header Length before Transport Header 192 (or 412) (unless PMTU is larger than 1500? But your PMTU may vary dynamically...) Make PMTU Discovery Optional ---------------------------- Why Large MTU - Larger MTU means less header and packet processing overhead - You may want to have a LAN with huge MTU (even though RTT is small and CRC-error prone) - PMTU will almost always be between 1280 and 1500 PMTUD not Useful - PMTUD had limited usefulness when minimum MTU was 576 - PMTUD not applicable for one time connectionless communication - PMTUD not applicable for multicast (hosts will be efficient enough to be able to decode multicasted video with MTU of 1280) PMTUD is BAD because - Extra burden on Routers by retry - No specification on retry interval Proposal - Make PMTUD purely optional - Host should always assume PMTUD of 1280 Discussion on Limit Maximum Header Lengths: Deering: On first topic, after discussion on mailing list, doesn't think problem being handled is a real problem. Applications will not create extremely large headers. It is a theorical problem. As soon as a budget is imposed on max header size, then one is forced to create limits for every header type. Doesn't think this will work. In most cases every header will be less than the maximum length. Example of UDP of w/ IPv4 shows the problem could theoretically happen, but in practice does not. Would also limit headers in control packets where there there is not an issue w/ transport payload size. Nordmark: With IPSEC in IPv4, there does not appear to be a problem today. No limit on IPSEC headers. Thinks it is very limiting to limit size. In the future link MTU's may be different. We should not constrain the flexibility now without a strong reason. It is very hard to predict what the future will be in 20 years. We should make it flexible. Comment that we should not put arbitrary limits on header size. Discussion on Make PMTU Discovery Optional: Kazu: Dislikes problems because TCP exchanges MSS, TCP can find appropriate MTU by itself. Doesn't like this limitation. Deering: If there is not a retry interval, there should be. It should be around 10 minutes. This is not a great load on routers. Not significant. Someone reported that the retry interval in current RFC is 10 minutes. More general issue is that eliminating the PMTUD creates an "internet cell size" for all time. We should not limit this. We might want bigger MTU's later. What we have now is a wonderful scheme that has zero cost and will allow us to adapt to future changes. Comment that just because applications work well w/ 1280 or less now, doesn't mean that they will do so in the future. We should not limit what we can do in the future. Deering polled the room on each proposal. Strong consensus to not adopt proposed changes. Router Renumbering / M. Crawford -------------------------------- Issues addressed by -04 draft - Various working changes and typos - Gathering more definitions together - Random delay in responses. - Multicast target limited to an All-Routers address of site- or link-scope. o This eliminates an obscure error condition. - List address formats forbidden to create, define error flag if one is attempted. - InterfaceIndex in result message now comes from IPv6 MIB. - Clarify ICMPv6 checks - Define changes of prefix to same value so that is is never unconfigured - List ND parameters affected by RR. Not addressed by -04 , in -05 alpha - MinLen, MaxLen bounding lengths of prefixes to be tested - Add explicit bounds checking for certain fields, and an error flag if checks flag. - State that implementaion algorithm may vary as longs as results are the same. Not address by -04, in -05 beta - Limit of random response delay should be msec, not seconds - Use purely IPSEC, no custom authentication o Added a new message type to support this: Sequence Number Reset o Meaning: Invalidate all keys used for RR, reset Recorded Sequence Number to zero. Questions about network partitions. Answer is that Reset is "omnipotent" and can be retransmitted. Kazu: How could site ask request to be renumbered. Answer: no request reply, but provider could retransmit advertisement. Deering: How can this be used for initial prefix assignments? Discussion about how this could be used for initial router configuration. Comment to add clarification that routers should save this new info in non-volatile storage. ACTION: Document editor will forward to IESG for PS. W.G. last call was completed prior to previous IETF meeting. Multicast Listener Discovery Protocol / S. Deering -------------------------------------------------- Received comments on clarification of text. Believes there are several implementations. Deering explained that MLD for IPv6 is based on IGMP version 2 for IPv4. Version 3 of IGMP currently being designed, and a new working group will probably be formed to shepherd that work through the Standards process. We would expect a corresponding new version of MLD to also be an output of that work. The new version of IGMP/MLD adds the capability to specify a "source filter" when joining a multicast group, so as to request reception of multicast from ONLY a specified set of sources, or from ALL BUT a specified set of sources. The new version will be backwards compatible with the current version, that is, in the presence of current version implementations the new version will revert to current behavior. Comment that MLD requires Router Alert. Need to make sure that Router Alert moves forward. ACTION: Document editor will issue a w.g. last call when new draft is published. IPv6 Naming interoperabilty issues / J. Paugh --------------------------------------------- Current Proposal for Storing IP Addresses - IPv4 and IPv6 addresses stored separately - NIS map, NIS+ table and /etc file created for IPv6 addresses - Prevents existing IPv4 applications from unexpectedly receiving IPv6 addresses - Separate IPv6 database can be served by older slave/replica New Ipv6 Database Created - nodes.byname/nodes.byaddr maps for NIS - nodes.org_dir table for NIS+ - AAAA record for DNS - /etc/nodes file for local file - Updated utilities to create nodes database o ypmake(1M), nisaddent(1M), nispopulate(1M), etc. [slide w/ graphic] Issues W/ Current Proposal - Stuck w/two "hosts" files, for ever o No provision for deprecating "hosts" database (/etc/hosts, hosts.byname, etc.) o Nuisance administration long after transition period o AI_ALL lookups requires two call s to name services - Is it possible to put IPv4 and IPv6 addresses in one place and still preserve backward compatibility with legacy applications? An Alternative Approach - IPv4 and IPv6 addresses stored together /etc/nodes - /etc/hosts preserved for legacy applications - IPv6 applications will use /etc/nodes for v4 and v6 addresses. IPv4 lookup will fail over to /etc/hosts - Legacy applications lookup will continue to use /etc/hosts. Long Term Benefits - One database, one lookup for IPv4 and IPv6 addresses - /etc/hosts can be deprecated, leaving one database for IP addresses - Simplified administration of one database Risks - During transition, two locations for IPv4 addresses creates synchronization issue - Requires comprehensive update policies and administration model during transition - Lookups for IPv6 hosts with no IPv4 interface will always fail over to hosts, requiring two lookups (will require code change when "hosts"is removed). Comments: Given failover, could put all IPv4 in /etc/hosts, and later add them to database w/ IPv6 addresses. Should <...-bsd-frag-00.txt> added to Advanced API / M. Andrews --------------------------------------------------------------- Draft designed to tell kernel that it needs to always fragment and not do path MTU discovery. Only comments were based on security. Wants to know if should add this to Advanced API document. Discussion. Consensus to fold this into revision of Advance API draft. IP Address Allocation Ideas / Maarc Blanchet -------------------------------------------- IPv4 - RFC1219 on the assignment of subnet numbers - Able to delay your decision for the final subnet mask of your net without renumbering. - Use leftmost bits for network numbers - Use rightmost bits for host numbers IPv4 Example +------------------------+--------+--------+ | | | | +------------------------+--------+--------+ <---> 100 001 010 010 110 011 001 100 101 101 011 110 111 111 IPv6 - Prefixes - Many allocation boundaries (TLA, subTLA, NLA, XLA, YLA, SLA, DLA, department,...)...) - Draft proposes a generalization of RFC-1219 o Use left bits for the TLA allocation prefixes o Use rightmost bits for the LLA (last level aggregator) o Use <> bits for all others IPv6 Example +--------+--------+--------+------------+--------+--------+ | | | | | | | +--------+--------+--------+------------+--------+--------+ | <-|-> <-|-> <-|-> | 100 001000 001 010 000100 010 110 001000 011 001 001100 100 101 010000 101 011 010100 110 111 011000 111 011100 000010 Considerations - This is not a new allocation scheme for IPv6 - It is there to help any organization that is allocating addresses (at any level: ex.: SLA to departments) - Informational Discussion: Deering thinks that a document discussing this would be valuable. Not everyone knows these "tricks". Nordmark thinks it makes sense to provide the correct allocations for IPv6. Document should be "Informational". Not a Standard track or BCP. Important to change title to be clearer that this document is an IPv6 address assignment plan. ACTION: Document editor will issue w.g. last call when new draft is out. AAAA Record Code Point / Matt Crawford -------------------------------------- Current RFC - Complete IPv6 Address (16) Draft - Address "suffix" (16) - Prefix length (1) - Prefix DNS Name (var) Alternate (New RR Type) - Prefix length (1) - Address "suffix" (1-16) - Prefix DNS Name (var) Augments for a new RR type - Avoid complaints of a wrong RDATA length - Can add a "Type A additional section processing" rule to the new type. - Save a few bytes in DNS replies o Estimate ~50 bytes in a "typical" NS or MX reply Arguments against ???? Discussion: Would new type require resolver to make additional requests? New resolver would not get new record. When could new resolver code be available? Adding a new type would probably make transition easier. Bounds thinks new type code is a good idea. It might take a year to deploy change, but.. Strong consensus for new type code. Comment that record name also needs to change. Suggestion for "A6". Consensus to remove unneeded initial bytes. ACTION: Document editor will issue w.g. last call when new draft is published. Prefix Allocation / Kazu Yamamoto --------------------------------- Model of Prefix Allocation +----------------+ | | | ISP | | | +-------+--------+ | +-+ | | +-+ | | | <----- prefix allocation | | +-+ | | +-+ | +-------+--------+ | | <------ Renumbering | Site | aka | | prefix distribution +----------------+ Prefix Allocation - Interaction w/ ISP - Request and Response - Shared key w/ ISP - Over tunnel? Prefix distribution - Within Site - Command and Report - Secret key within site Requirements for prefix allocation - Request and response - Key separation - Server discovery Discussion: Deering thinks that site prefix allocation being temporary is not correct model. More sites will be moving to permanent allocations. Comment autoconfiguration is very important. Doesn't like using PPP for this, but would like to see routers autoconfigure. Protocol mechanisms is useful for cable modems, xDSL modems/routers, etc. Likes models for appropriate for many situations. Some customers will not want it to be automatic, but there are scenarios that this will useful. Note made that DHCPv6 might be able to be extended to handle this service. Bringing up a new link is an implied "request". Link coming up could cause RR message to be sent. Maybe a new w.g. could be formed to handle this and related issues. Could be very broad. Important issue. Not sure proposed mechanisms are adequate. Distinction between mechanisms that require centralized administration and those that do not. This is an important issue. We should continue discussion on the mailing list. This is very good start. Well put on agenda for the next meeting. ------------------------------------------------------------------------ Charlie Perkins asked for comments on "case for IPv6" draft. Please send him comments at . This is an IAB document. Draft is: ; Fri, 4 Sep 1998 13:03: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 NAA06640 for ; Fri, 4 Sep 1998 13:03:20 -0700 Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA29327 for ; Fri, 4 Sep 1998 13:03:22 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id MAA28471; Fri, 4 Sep 1998 12:54:41 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id MAA00997; Fri, 4 Sep 1998 12:54:40 -0700 (PDT) Received: from tdc97.ops.3com.com (pnl-entp-14.OPS.3Com.COM [139.87.12.94]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id MAA00066; Fri, 4 Sep 1998 12:54:40 -0700 (PDT) Message-Id: <3.0.32.19980904125304.011dfeb8@pop.nsd.3com.com> X-Sender: cmj@pop.nsd.3com.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 04 Sep 1998 12:53:05 -0700 To: Keith Knightson , Mullaparthi Chandrashekhar From: Cyndi Jung Subject: (IPng 6414) Re: OSI Addressing Cc: IPNG Mailing list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ISO 8348 only covers Network Layer addressing, which does not get you to the connection end-point in a process. Cyndi At 02:00 PM 9/4/98 -0400, Keith Knightson wrote: >Chandru, > >You should read ISO standard IS 8348, which is quite readable and >comprehensive. > >Regards Keith > >At 6:10 AM -0400 04/9/98, Mullaparthi Chandrashekhar wrote: >>Hi all, >> >> I don't know if this is the right place to ask this question. >> >> I'm trying to understand OSI addressing. I know that for Internet >> addressing, an IP address and a port is enough to uniquely identify >> a connection end-point in a process. >> >> What is the equivalent in OSI addressing?? Should I read ACSE in detail >> to understand this?? >> >>TIA, >>Chandru >> >>-- >> >>HP, Telecom Mgmt. Division. / +65-2792881 >>-------------------------------------------------------------------- >>IETF IPng Working Group Mailing List >>IPng Home Page: http://playground.sun.com/ipng >>FTP archive: ftp://playground.sun.com/pub/ipng >>Direct all administrative requests to majordomo@sunroof.eng.sun.com >>-------------------------------------------------------------------- > > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 4 17:31:10 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA08082 for ipng-dist; Fri, 4 Sep 1998 17:20:17 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA08075 for ; Fri, 4 Sep 1998 17:20: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 RAA03459 for ; Fri, 4 Sep 1998 17:20:07 -0700 Received: from send1e.yahoomail.com (send1e.yahoomail.com [205.180.60.64]) by earth.sun.com (8.9.1/8.9.1) with SMTP id RAA18771 for ; Fri, 4 Sep 1998 17:20:09 -0700 (PDT) Message-ID: <19980905001800.21369.rocketmail@send1e.yahoomail.com> Received: from [209.94.102.180] by send1e; Fri, 04 Sep 1998 17:18:00 PDT Date: Fri, 4 Sep 1998 17:18:00 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6415) Reg: PMTU To: ipng MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear all, I have one quick question. How we arrived at the MIN.PMTUV6 value of 1280 octets. Thanks -Raghu. == ------------------------------------------------------------ _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 4 19:57:01 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA08278 for ipng-dist; Fri, 4 Sep 1998 19:48:11 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id TAA08271 for ; Fri, 4 Sep 1998 19:47: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 TAA21319 for ; Fri, 4 Sep 1998 19:47:59 -0700 Received: from hotmail.com (f194.hotmail.com [207.82.251.83]) by earth.sun.com (8.9.1/8.9.1) with SMTP id TAA24139 for ; Fri, 4 Sep 1998 19:47:59 -0700 (PDT) Received: (qmail 27561 invoked by uid 0); 5 Sep 1998 02:47:59 -0000 Message-ID: <19980905024759.27560.qmail@hotmail.com> Received: from 202.188.24.203 by www.hotmail.com with HTTP; Fri, 04 Sep 1998 19:47:59 PDT X-Originating-IP: [202.188.24.203] From: "flowcontrol PDF" To: ipng@sunroof.eng.sun.com Subject: (IPng 6416) IPv6 simulation Content-Type: text/plain Date: Fri, 04 Sep 1998 19:47:59 PDT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi everyone.. I'm interested in simulating IPv6 over ATM, does anyone know how to do it. What type of simulating tool that I need. Thanks ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 9 13:09:48 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA11842 for ipng-dist; Wed, 9 Sep 1998 12:57:10 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA11833 for ; Wed, 9 Sep 1998 12:57:00 -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 MAA16882 for ; Wed, 9 Sep 1998 12:56:57 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA21484 for ; Wed, 9 Sep 1998 12:56:59 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id MAA10279; Wed, 9 Sep 1998 12:56:57 -0700 (PDT) Message-Id: <3.0.5.32.19980909125337.009e19a0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Sep 1998 12:53:37 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6418) Chicago IPng w.g. Minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPng Meeting Chicago IETF August 25 & 27, 1998 Bob Hinden / Nokia, Co-Chair Steve Deering / Cisco, Co-Chair Minutes taken and edited by Bob Hinden ------------------------------------------------------------------------ Introduction / S. Deering ------------------------- S. Deering introduced the meeting. Review Agenda / S. Deering -------------------------- TUESDAY, August 25, 1998, 1545-1800 Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) UNH Interoperability Testing Report / W. Lenharth (5 min) Document Status / R. Hinden (10 min) New Documents to Draft Standard / R. Hinden (5 min) IPv6 Address Assignment Status / R. Hinden, R. Fink (10 min) IPv6 over NBMA & IPv6 over ATM Status / M. Jork (10 min) Mobile IPv6 Status / D. Johnson (10 min) Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering (15 min) IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter, C. Jung (30 min) DNS Extension to Support IP Version 6 / M. Crawford (30 min) PPP Extension for Prefix Allocation / K. Yamamoto THURSDAY, August 27, 1998, 0900-1130 Jumbograms / S. Deering (15 min) Maximum header length (or minimum assured payload length) / M. Ohta (15 min) & Make PMTUD purely optional Router Renumbering / M. Crawford (15 min) Multicast Listener Discovery Protocol / S. Deering (10 min) IPv6 Naming interoperabilty issues / J. Paugh (15 min) Should <...-bsd-frag-00.txt> added to Advanced API / M. Andrews IP Address Allocation Ideas / Maarc Blanchet UNH Interoperability Testing Report / W. Lenharth ------------------------------------------------- Test period the week prior to the Chicago IETF meeting. There was a total of 19 participants from 10 companies/implementations. There were 3 that were just routers, 1 hosts only and 6 router / hosts. Companies: Compac(DEC), Telebit(Denmark), Hitachi, WIDE, SUN, IBM, Masushita, and Microsoft Research. Tested Areas: Basic Spec, ND, MTU path discovery, BGP4+, RIPng and redirects. Analysis of work: We were unable to get all the routers to participate in a network configuration. Some implementations could not run "nslookup ", to get up to date info from DNS. IPv6: Some vendors have serious (halting) type v6 problems, others have solid implementations. At this test period about 25% worked well. Future Plans: The next test period will be at Connectathon99 in March of 1999. The lab will continue to provide increasingly intense testing in a v6 network environment, containing routing scenarios and network configurations using OSPF(v6) as well as BGP4+ and RIPng. Document Status / R. Hinden --------------------------- RFC Published RFC 2373 IP Version 6 Addressing Architecture (PS) RFC 2374 An IPv6 Aggregatable Global Unicast Address Format (PS) RFC 2375 IPv6 Multicast Address Assignments (Info) IESG Approved for Draft Standard IPv6 Specification ICMPv6 Path MTU Discovery for IPv6 Neighbor Discovery for IP Version 6 (IPv6) IPv6 Stateless Address Autoconfiguration Deering reported that there will be a new version of the ICMPv6 draft to fix some editorial oversights, before submission for publication as RFC. IESG Approved for Proposed Standard MIB for IPv6: UDP MIB for IPv6: TCP IESG Approved for Informational Proposed TLA and NLA Assignment Rules IESG Approved for Experimental IPv6 Testing Address Allocation IESG Previously Approved / Waiting for RFC publication MIB for IPv6: Textual Conventions & General Group (PS) MIB for IPv6: ICMPv6 Group (PS) IPv6 over PPP (PS) IPv6 Testing Address Allocation (Experimental) IPv6 Packets over Token Ring Networks (PS) Generic Packet Tunneling in IPv6 Specification (PS) IPv6 Packets over FDDI Networks (PS) IPv6 Packets over Ethernet Networks (PS) IETF Last Call completed for Proposed Standard IP Header Compression / Nov 97 Submitted to IESG for Proposed Standard IPv6 Router Alert Option - IESG wants to reconcile w/ IPv4 Router Alert IPng Working Group Last Call Completed for Proposed Standard Router Renumbering for IPv6 IPng Working Group Last Call Completed for Experimental IPv6 Name Lookups Through ICMP Carpenter also noted the Business Case for IPv6 draft, originally a Bay Networks white paper, most recently edited by Charlie Perkins, to eventually be published as an IAB document. Solicits review from ipngwg. We will do a WG Last Call when Charlie gives the go-ahead. ACTION: Document editor will issue a w.g. last call when author give the go ahead. New Documents to Draft Standard / R. Hinden ------------------------------------------- - Start Planning Next Set of Document for Draft Standard - Possible Candidates Addressing Architecture Aggregation Formats IPv6 over Ethernet, FDDI, TR, PPP Others? - Next Step is to Collect Implementation Information ACTION: Document editor will start process to advance Addressing Architecture, Aggregation format, and IPv6over to Draft Standard. Will also recommend any other documents currently at Proposed Standard. IPv6 Address Assignment Status / R. Hinden, R. Fink --------------------------------------------------- Address Assignment Status - "Proposed TLA/NLA Assignment Rules" o Updated based on comments from LA IETF o Presented Approach at RIPE Meeting in Stockholm o Revised based on comments received at RIPE Meeting o Revised based on email comments - Submitted to IESG for "Informational" Status o IESG Approved on 18 Aug 1998 Next Steps - Plan is for TLA/NLA Assignment Rules to become New IANA Document - First Requests made to Registries for Sub-TLA Assignments Bob Fink reported that the following IPv6 sub-TLA requests have been made: uunet-uk to RIPE-NCC ESnet to ARIN WIDE to APNIC - Primary intent of these initial requests is to assist registries in setting up their process and in interpreting the TLA/NLA rules. - We are NOT trying to start an Sub-TLA "Land Rush". - If you NEED an IPv6 Sub-TLA AND are familiar with the "Rules" RFC, please proceed, otherwise wait. IPv6 over NBMA & IPv6 over ATM Status / M. Jork ----------------------------------------------- ION WG Last call ended - draft-ietf-ion-ipv6-01.txt - draft-ietf-ion-atm-02.txt - draft-ietf-ion-fr-00.txt - draft-ietf-ion-ind-00.txt Issues around IPv6 over ATM in PVC mode raised by the WIDE project have been resolved one week after the last IETF. New ND option number in needs official blessing. Document editor reported that he has put together "tentative" assignments for this and other pending requests (e.g., IPv6 options, ICMPv6 types, etc.). These have been sent to the IANA. Expects them to be approved in a few weeks. ACTION: Put the "tentative" assignments on the IPng web site until the IANA publish them. Mobile IPv6 Status / D. Johnson ------------------------------- Changes in the latest Mobile IPv6 Draft Completed Mobile IP w.g. last call. Minor Changes and Corrections - Advertisement Interval option MAY be included by any router, not just by home agents - Any router MAY use relaxed limits on MaxRtrAdvInterval and MinRtrAdvInterval to allow faster Advertisements - Documented new limits on MAX RTR SOLICITATIONS and RTR SOLICITATION INTERVAL for mobile nodes sending Router Solicitations while away from home - If a mobile node has multiple home addresses using different interface identifiers, it SHOULD send a separate Binding Update to its home agent for each - Finally filled in Section 2, giving a comparison of Mobile IPv6 with Mobile IP for IPv4 Modified Prefix Information Option Format On Router Advertisement: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |L|A|R|Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ New flag bit Router Address (R): - Set to indicate whole Prefix field is router's address - Compatible with existing uses of Prefix field - Router MUST include in solicited Router Advertisement - Router SHOULD include in unsolicited Router Advertisements New Home Agent Information Option Format - On Router Advertisement: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Preference | Home Agent Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Allows home agent to advertise values about itself: o Preference: Signed value (default 0) used for sorting reply list for dynamic home agent address discovery o Lifetime: Can give lifetime separately from router lifetime - Use in dynamic home agent address discovery: o Home agents remember values in Home Agents List o In discovery reply, home agent includes self in list only if not highest preference Receiving Packets While Away From Home - IPv6 suggests that nodes MAY reverse received Routing header for response packets (if authenticated) - But for mobile node away from home this is bad: o Routing header directs packet to care-of address then to home address o Reversing Routing header would send response out looped back through care-of address too o Inefficient, and confusing to receiving node - For response packets by mobile node away from home: o SHOULD NOT include care-of address as first hop in route o If no other hops, SHOULD NOT include Routing header Address Scope Issues - Packets addressed to a mobile node's site-local address: o Consensus is SHOULD be forwarded while away from home o But this behavior MUST be configurable to disable it o This default might change as ``sites'' and site-local addresses become better defined - Multicast packets with link-local < scope < global: o Same as site-local unicast above o This default may change as multicast scopes become better defined Binding Lifetime Rules - New rules specified to limit lifetimes: o On primary care-of address registration: - Home agent MUST reduce lifetime to no greater than remaining prefix lifetime o When sending a Binding Update: - Mobile node MUST NOT send lifetime greater than remaining binding lifetime for home registration - Ensures no use of binding beyond home address lifetime Renumbering the Home Network - Home agent watches for ``important'' Router Advertisements: o The preferred or valid lifetime for an existing prefix on the home link is reduced o A new prefix is introduced on the home link o State of home agent's AdvManagedFlag flag changes - When any of these occur: o Home agent tunnels constructed Router Advertisement with changed info and Binding Request to mobile node o Retransmits until Binding Request is answered o Ensures important Router Advertisement changes seen by mobile node Question about implementation experience. Currently CMU (adding current IPSEC (FreeBSD), Lancaster university (Linux), National Univ. of Singapore (Linux). Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering --------------------------------------------------------------- Which part of Address Space to Reserve? - Many official and unofficial Uses of low-numbered interface ID's o End os a point-point link o Tunnel endpoints o Manually configured unicast addresses when a hardware token is not available for the network interface. o Manually configured static addresses for each of the routers on a link. - Not possible in practice to "reserve" them for a new use (anycast). Thus reserve high end of space, not low end. Reserved Subnet Anycast Addresses - Reserve highest 128 interface ID values for subnet anycast - Reserved subnetanycast addresses format: n bits 121-n 7 bits +-----------------------------+-----------+------------+ | subnet prefix |1111...1111| anycast ID | +-----------------------------+-----------+------------+ | Interface ID field | - The anycast ID identifies a particular reserved anycast addresses within the subnet prefix: Decimal Hex Description ------- ------ ------------- 127 7F Reserved 126 7E Mobile IPv6 Home-Agents anycast 0-125 00-7D Reserved - Reserved in EVERY prefix on ALL links. How Many Addresses to Reserve - Minimum size of interface ID is currently undefined in IPv6 - We don't want to change that with this draft - But minimum size of interface ID must be bigger than reserved part of space: o Some part if interface ID space is for anycast o Rest of space allows some unicast addresses o Reserving 128 addresses allow 1-byte interface ID's - Careful management retains additional flexibility: o Assign new anycast IDs in descending numerical order o Can reduce number of reserved IDs if not all assigned yet o Can increase number of reserved IDs if can be sure not in use for unicast (or if can change unicast assignments) Discussion: Is 127 the correct size? Suggestions? Deering added that the issue was what is min size of interface ID. Do we think that we may have Interface ID's that are smaller than 64 bits. Nordmark: Could we move boundary to get more if we need them. Discussion about how many to have. Not strong opinion to change size. Size will be kept 127. Problem w/ bit flip, will be fixed in new version of draft. ACTION: Document editor will issue a w.g. last call after new draft is out. IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter, C. Jung ------------------------------------------------------------- Work started out in IPng, moved to NGTRANS because was related to transition, but now back here because is another cast of IPover document. Needs to be standardized in IPng w.g. - Uses IPv4 multicast (on site) as virtual multicast LAN. - No changes of IPv6 model - Just another IPv6over Two implementations currently - Microsoft Research on NT - UCLA on FreeBSD Any issues? Advance to Proposed Standard? Question and discussion about default MTU size. Suggestion to reduce to 1460 to allow tunneling / options / etc. Discussion. Decision to leave as is. ACTION: Document editor will issue a w.g. last call after new draft is out. DNS Extension to Support IP Version 6 / M. Crawford ---------------------------------------------------- Status of -ipngwg-dns-lookups-01 - Merges dns-lookups-00 and aaaa-03. o Modified AAAA RDATA format, discussed to death in L.A. - 128 bits + prefix length + prefix DNS name - Address space delegations rely on new DNS features o Binary labels - Longest match lookups no longer needed o DNAME RR - Ready for W.G. last call MUSTs and SHOULDs - AAAA prefix name MUST NOT indicate a AAAA w/ a longer prefix. (Equal is OK). o No good way to signal an error, so offending record MUST be ignored; others may exist. o Suggest zone maintainers run a check. - Address delegations SHOULD all be through DNAME, never NS. - SUGGEST using the tag "ipv6" uniformly in the reverse zones. Examples X.EXAMPLE is dual-homed to A & B; A is dual-homed to C & D. $ORIGIN X.EXAMPLE wwww AAAA ::1234::567:9ABC:DEF0 64 subnet-1.ip6 subnet-1.ip6 AAAA 0:0:0:1:: 48 ip6 ip6 AAAA 0::0 48 subscriber-x.ip6.A.NET. AAAA 0::0 48 subscriber-x.ip6.B.NET. \[x0001/16].ip6 DNAME subnet-1.ip6 \[x123456789ABCDEF0].subnet-1.ip6 PTR www $ORIGIN ip6.A.NET subscriber-x AAAA 0:0:0011:: 40 A.NET.ip6.C.NET. AAAA 0:0:0011:: 40 A.NET.ip6.D.NET. \[x11/8] DNAME ip6.X.EXAMPLE. Usage/Deployment Notes - Higher and lower network entities (e.g., provider and site) must agree on a name like "subscriber-x" to hold the delegated prefix bits, or ... - Binary label corresponding to the delegated bits themselves could be used for that o Then the lower zone would have to be touched when renumbered, but this might be fair exchange for the unification of forward and reverse delegation data. No issues raised. Question about phase in v.s. flash cut over. When will this DNS code be available. 6BONE issue? ACTION: Document editor will issue a w.g. last call when new draft is out. PPP Extension for Prefix Allocation / Kazu Yamamoto -------------------------------------------------------------- IPv6CP extension for prefix allocation +--------+--------+ | IPv4 | IPv6 | +--------+--------+ | IPCP | IPV6CP | +--------+--------+ | LCP | +-----------------+ - IPCP can allocate only one IPv4 address - In IPv6 environment, we want more! - Prefix allocation is necessary - New IPV6CP option for prefix allocation Question about could ND be used to do this instead? Could use this to report prefixes? Wasn't sure. Might be a possibility. IPV6CP Prefix Options - Common format for Request and ACK +-------+-------+-------+---------+ | Type | Lengt | Res. | Entry # | +-------+-------+-------+---------+ | Reserved | Pref Len| +-----------------------+---------+ | Valid Lifetime | \ +---------------------------------+ | | Preferred Lifetime | | +---------------------------------+ | Entry | IPv6 Prefix 0-3 | | +---------------------------------+ | | IPv6 Prefix 4-7 | / +---------------------------------+ | next entry | | | Discussion. Question asked is prefix permanent or does it go away when the PPP connection is down? Or how is prefix refreshed when lifetime expires? Would like prefix to be permanent. If approved for PPP, we should also do this for DHCP (e.g., allocation prefix). Maybe not a good idea. Point made that Router Renumbering could be used for this as well. Not good to have multiple ways to do the same thing. Better to use current mechanism. Needs further discussion. ------------------------------------------------ THURSDAY, August 27, 1998, 0900-1130 ------------------------------------------------ Jumbograms / S. Deering ----------------------- When IESG advanced base IPv6 spec from Proposed Standard to Draft Standard, one issue the IESG had was that there wasn't enough implementation experience w/ the Jumbogram option. The option was removed from the base spec and published as a new internet draft. Deering added some text to describe some error cases that were not handled in the original text. Encourages people to do more real testing w/ this option. The chairs plan is to submit the new draft for Proposed Standard and to request Draft Standard status once interoperability has been demonstrated. Report from Kevin Lahey (NASA Ames) that they have it running on NetBSD and would like to do testing w/ other implementations. They could also host testing w/ other implementations. Maximum header length (or minimum assured payload length) & Make PMTUD purely optional / M. Ohta (15 min) ------------------------------------------------------------ Limit Maximum Header Lengths ---------------------------- The Header Length Problem - Header Length + Playload length <= Reconstruction Buffer Size (1500 or ...) - Fragmentation does not help - TCP does not work if headers before the TCP header >= 1480 - DNS assumes minimally assured Payload length of 512 (though with a wrong estimate of UDP header length) - Not all headers are under application control Proposal - Allow Transport Protocols assure minimum payload length (after transport header) of 1024 by making transport header length <= 64) - Limit Maximum Header Length before Transport Header 192 (or 412) (unless PMTU is larger than 1500? But your PMTU may vary dynamically...) Make PMTU Discovery Optional ---------------------------- Why Large MTU - Larger MTU means less header and packet processing overhead - You may want to have a LAN with huge MTU (even though RTT is small and CRC-error prone) - PMTU will almost always be between 1280 and 1500 PMTUD not Useful - PMTUD had limited usefulness when minimum MTU was 576 - PMTUD not applicable for one time connectionless communication - PMTUD not applicable for multicast (hosts will be efficient enough to be able to decode multicasted video with MTU of 1280) PMTUD is BAD because - Extra burden on Routers by retry - No specification on retry interval Proposal - Make PMTUD purely optional - Host should always assume PMTUD of 1280 Discussion on Limit Maximum Header Lengths: Deering: On first topic, after discussion on mailing list, doesn't think problem being handled is a real problem. Applications will not create extremely large headers. It is a theorical problem. As soon as a budget is imposed on max header size, then one is forced to create limits for every header type. Doesn't think this will work. In most cases every header will be less than the maximum length. Example of UDP of w/ IPv4 shows the problem could theoretically happen, but in practice does not. Would also limit headers in control packets where there there is not an issue w/ transport payload size. Nordmark: With IPSEC in IPv4, there does not appear to be a problem today. No limit on IPSEC headers. Thinks it is very limiting to limit size. In the future link MTU's may be different. We should not constrain the flexibility now without a strong reason. It is very hard to predict what the future will be in 20 years. We should make it flexible. Comment that we should not put arbitrary limits on header size. Discussion on Make PMTU Discovery Optional: Kazu: Dislikes problems because TCP exchanges MSS, TCP can find appropriate MTU by itself. Doesn't like this limitation. Deering: If there is not a retry interval, there should be. It should be around 10 minutes. This is not a great load on routers. Not significant. Someone reported that the retry interval in current RFC is 10 minutes. More general issue is that eliminating the PMTUD creates an "internet cell size" for all time. We should not limit this. We might want bigger MTU's later. What we have now is a wonderful scheme that has zero cost and will allow us to adapt to future changes. Comment that just because applications work well w/ 1280 or less now, doesn't mean that they will do so in the future. We should not limit what we can do in the future. Deering polled the room on each proposal. Strong consensus to not adopt proposed changes. Router Renumbering / M. Crawford -------------------------------- Issues addressed by -04 draft - Various working changes and typos - Gathering more definitions together - Random delay in responses. - Multicast target limited to an All-Routers address of site- or link-scope. o This eliminates an obscure error condition. - List address formats forbidden to create, define error flag if one is attempted. - InterfaceIndex in result message now comes from IPv6 MIB. - Clarify ICMPv6 checks - Define changes of prefix to same value so that is is never unconfigured - List ND parameters affected by RR. Not addressed by -04 , in -05 alpha - MinLen, MaxLen bounding lengths of prefixes to be tested - Add explicit bounds checking for certain fields, and an error flag if checks flag. - State that implementation algorithm may vary as longs as results are the same. Not address by -04, in -05 beta - Limit of random response delay should be msec, not seconds - Use purely IPSEC, no custom authentication o Added a new message type to support this: Sequence Number Reset o Meaning: Invalidate all keys used for RR, reset Recorded Sequence Number to zero. Questions about network partitions. Answer is that Reset is "idempotent" and can be retransmitted. Kazu: How could site ask request to be renumbered. Answer: no request reply, but provider could retransmit advertisement. Deering: How can this be used for initial prefix assignments? Discussion about how this could be used for initial router configuration. Comment to add clarification that routers should save this new info in non-volatile storage. ACTION: Document editor will forward to IESG for PS. W.G. last call was completed prior to previous IETF meeting. Multicast Listener Discovery Protocol / S. Deering -------------------------------------------------- Received comments on clarification of text. Believes there are several implementations. Deering explained that MLD for IPv6 is based on IGMP version 2 for IPv4. Version 3 of IGMP currently being designed, and a new working group will probably be formed to shepherd that work through the Standards process. We would expect a corresponding new version of MLD to also be an output of that work. The new version of IGMP/MLD adds the capability to specify a "source filter" when joining a multicast group, so as to request reception of multicast from ONLY a specified set of sources, or from ALL BUT a specified set of sources. The new version will be backwards compatible with the current version, that is, in the presence of current version implementations the new version will revert to current behavior. Comment that MLD requires Router Alert. Need to make sure that Router Alert moves forward. ACTION: Document editor will issue a w.g. last call when new draft is published. IPv6 Naming interoperabilty issues / J. Paugh --------------------------------------------- Current Proposal for Storing IP Addresses - IPv4 and IPv6 addresses stored separately - NIS map, NIS+ table and /etc file created for IPv6 addresses - Prevents existing IPv4 applications from unexpectedly receiving IPv6 addresses - Separate IPv6 database can be served by older slave/replica New IPv6 Database Created - nodes.byname/nodes.byaddr maps for NIS - nodes.org_dir table for NIS+ - AAAA record for DNS - /etc/nodes file for local file - Updated utilities to create nodes database o ypmake(1M), nisaddent(1M), nispopulate(1M), etc. [slide w/ graphic] Issues W/ Current Proposal - Stuck w/two "hosts" files, for ever o No provision for deprecating "hosts" database (/etc/hosts, hosts.byname, etc.) o Nuisance administration long after transition period o AI_ALL lookups requires two call s to name services - Is it possible to put IPv4 and IPv6 addresses in one place and still preserve backward compatibility with legacy applications? An Alternative Approach - IPv4 and IPv6 addresses stored together /etc/nodes - /etc/hosts preserved for legacy applications - IPv6 applications will use /etc/nodes for v4 and v6 addresses. IPv4 lookup will fail over to /etc/hosts - Legacy applications lookup will continue to use /etc/hosts. Long Term Benefits - One database, one lookup for IPv4 and IPv6 addresses - /etc/hosts can be deprecated, leaving one database for IP addresses - Simplified administration of one database Risks - During transition, two locations for IPv4 addresses creates synchronization issue - Requires comprehensive update policies and administration model during transition - Lookups for IPv6 hosts with no IPv4 interface will always fail over to hosts, requiring two lookups (will require code change when "hosts"is removed). Comments: Given failover, could put all IPv4 in /etc/hosts, and later add them to database w/ IPv6 addresses. Should <...-bsd-frag-00.txt> added to Advanced API / M. Andrews --------------------------------------------------------------- Draft designed to tell kernel that it needs to always fragment and not do path MTU discovery. Only comments were based on security. Wants to know if should add this to Advanced API document. Discussion. Consensus to fold this into revision of Advance API draft. IP Address Allocation Ideas / Maarc Blanchet -------------------------------------------- IPv4 - RFC1219 on the assignment of subnet numbers - Able to delay your decision for the final subnet mask of your net without renumbering. - Use leftmost bits for network numbers - Use rightmost bits for host numbers IPv4 Example +------------------------+--------+--------+ | | | | +------------------------+--------+--------+ <---> 100 001 010 010 110 011 001 100 101 101 011 110 111 111 IPv6 - Prefixes - Many allocation boundaries (TLA, subTLA, NLA, XLA, YLA, SLA, DLA, department,...)...) - Draft proposes a generalization of RFC-1219 o Use left bits for the TLA allocation prefixes o Use rightmost bits for the LLA (last level aggregator) o Use <> bits for all others IPv6 Example +--------+--------+--------+------------+--------+--------+ | | | | | | | +--------+--------+--------+------------+--------+--------+ | <-|-> <-|-> <-|-> | 100 001000 001 010 000100 010 110 001000 011 001 001100 100 101 010000 101 011 010100 110 111 011000 111 011100 000010 Considerations - This is not a new allocation scheme for IPv6 - It is there to help any organization that is allocating addresses (at any level: ex.: SLA to departments) - Informational Discussion: Deering thinks that a document discussing this would be valuable. Not everyone knows these "tricks". Nordmark thinks it makes sense to provide the correct allocations for IPv6. Document should be "Informational". Not a Standard track or BCP. Important to change title to be clearer that this document is an IPv6 address assignment plan. ACTION: Document editor will issue w.g. last call when new draft is out. AAAA Record Code Point / Matt Crawford -------------------------------------- Current RFC - Complete IPv6 Address (16) Draft - Address "suffix" (16) - Prefix length (1) - Prefix DNS Name (var) Alternate (New RR Type) - Prefix length (1) - Address "suffix" (1-16) - Prefix DNS Name (var) Augments for a new RR type - Avoid complaints of a wrong RDATA length - Can add a "Type A additional section processing" rule to the new type. - Save a few bytes in DNS replies o Estimate ~50 bytes in a "typical" NS or MX reply Arguments against ???? Discussion: Would new type require resolver to make additional requests? New resolver would not get new record. When could new resolver code be available? Adding a new type would probably make transition easier. Bounds thinks new type code is a good idea. It might take a year to deploy change, but.. Strong consensus for new type code. Comment that record name also needs to change. Suggestion for "A6". Consensus to remove unneeded initial bytes. ACTION: Document editor will issue w.g. last call when new draft is published. Prefix Allocation / Kazu Yamamoto --------------------------------- Model of Prefix Allocation +----------------+ | | | ISP | | | +-------+--------+ | +-+ | | +-+ | | | <----- prefix allocation | | +-+ | | +-+ | +-------+--------+ | | <------ Renumbering | Site | aka | | prefix distribution +----------------+ Prefix Allocation - Interaction w/ ISP - Request and Response - Shared key w/ ISP - Over tunnel? Prefix distribution - Within Site - Command and Report - Secret key within site Requirements for prefix allocation - Request and response - Key separation - Server discovery Discussion: Deering thinks that site prefix allocation being temporary is not correct model. More sites will be moving to permanent allocations. Comment autoconfiguration is very important. Doesn't like using PPP for this, but would like to see routers autoconfigure. Protocol mechanisms is useful for cable modems, xDSL modems/routers, etc. Likes models for appropriate for many situations. Some customers will not want it to be automatic, but there are scenarios that this will useful. Note made that DHCPv6 might be able to be extended to handle this service. Bringing up a new link is an implied "request". Link coming up could cause RR message to be sent. Maybe a new w.g. could be formed to handle this and related issues. Could be very broad. Important issue. Not sure proposed mechanisms are adequate. Distinction between mechanisms that require centralized administration and those that do not. This is an important issue. We should continue discussion on the mailing list. This is very good start. Well put on agenda for the next meeting. ------------------------------------------------------------------------ Charlie Perkins asked for comments on "case for IPv6" draft. Please send him comments at . This is an IAB document. Draft is: ; Thu, 10 Sep 1998 02:38:18 -0700 (PDT) From: Volsinians@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 CAA29848 for ; Thu, 10 Sep 1998 02:38:16 -0700 Received: from imo24.mx.aol.com (imo24.mx.aol.com [198.81.17.68]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA23892 for ; Thu, 10 Sep 1998 02:38:17 -0700 (PDT) Received: from Volsinians@aol.com by imo24.mx.aol.com (IMOv16.1) id NDTOa17586; Thu, 10 Sep 1998 05:37:51 -0400 (EDT) Message-ID: <9d7efd8a.35f79def@aol.com> Date: Thu, 10 Sep 1998 05:37:51 EDT To: ipng@sunroof.eng.sun.com Cc: martillo@chem2.harvard.edu Mime-Version: 1.0 Subject: (IPng 6419) Host Fragmentation 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 The article attached below that I recently received suggests that the IPv6 rule of only fragmenting at the source host really is rather ill-conceived. Joachim Martillo Telford Tools, Inc. Subject: Microsoft NT and Alteon blurb http://www.infoworld.com/cgi-bin/displayStory.pl?980817.ehntlargeframe.htm Microsoft claims large frames help boost NT's performance By Stephen Lawson InfoWorld Electric Posted at 6:47 AM PT, Aug 17, 1998 Tests by Microsoft last week are claimed to show that Windows NT 4.0 server's performance can be boosted to nearly a full 1Gbps by large-frame Ethernet technology, breaking through current performance limits. Microsoft officials said they achieved 920Mbps throughput on a server using the AceNIC 180, a Gigabit Ethernet network interface card from Alteon, which also supplied the proprietary jumbo-frame technology. Large Ethernet frames can improve the efficiency of Gigabit Ethernet by reducing the number of frames that must be created and forwarded. Packing more data in a single frame can boost performance on server-to-server applications, transmitting large amounts of data in one stream, such as backups and replication. One user expressed surprise at the throughput achieved in Microsoft's tests. "If that's the case, it's quite a feat," said Lee Damon, a senior systems administrator at Qualcomm, in San Diego. The tests were conducted using a single-processor Intel 400-MHz Xeon-based server and four 333-MHz Pentium II clients. An Alteon Gigabit Ethernet server switch connected the servers and clients. Earlier tests using standard Ethernet frames have shown performance from 500Mbps to 600Mbps, said Reza Baghai, NT performance lead engineer at Microsoft. Alteon is the only Gigabit Ethernet vendor currently supporting large Ethernet frames. However, Baghai said Microsoft has had discussions with other vendors about using large frame sizes. According to Baghai, the standard NDIS driver set for NT 4.0, as well as Windows 98, can support large frames without modification. Baghai also confirmed that some developments due in NT 5.0 are designed to boost server throughput. A checksum off-load feature that can move TCP checksum processing from the CPU to the adapter will reduce the load on the server CPU. Another feature will deserialize the sending path, which allows a dual-processor server to send data from both processors at the same time. Analysts said large frame sizes could be beneficial to large enterprises with centralized server farms and for organizations that require high-bandwidth Web serving. Microsoft Corp., in Redmond, Wash., can be reached at http://www.microsoft.com. Alteon Networks Inc., in San Jose, Calif., can be reached at http://www.alteon.com. Stephen Lawson is a senior writer for InfoWorld. Go to the Week's Top News Stories Please direct your comments to InfoWorld Deputy News Editor, Carolyn April Copyright ) 1998 InfoWorld Media Group Inc. InfoWorld Electric is a member of IDG.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 Sep 10 07:04:48 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA12600 for ipng-dist; Thu, 10 Sep 1998 06:52:18 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA12593 for ; Thu, 10 Sep 1998 06:52: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 GAA23446 for ; Thu, 10 Sep 1998 06:52:00 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id GAA20161 for ; Thu, 10 Sep 1998 06:50:40 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id IAA01015; Thu, 10 Sep 1998 08:50:38 -0500 Message-Id: <199809101350.IAA01015@gungnir.fnal.gov> To: Volsinians@aol.com Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 6421) Re: Host Fragmentation In-reply-to: Your message of Thu, 10 Sep 1998 05:37:51 EDT. <9d7efd8a.35f79def@aol.com> Date: Thu, 10 Sep 1998 08:50:38 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The article attached below that I recently received suggests that > the IPv6 rule of only fragmenting at the source host really is > rather ill-conceived. > > Joachim Martillo > > [Article about high-MTU media helping an OS with an immature IP > stack deleted.] I see no implications there for fragmentation at the source instead of at a router. In fact, nothing in the article states that IP was used for the comparison at all. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 10 09:55:57 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA13074 for ipng-dist; Thu, 10 Sep 1998 09:48:35 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA13067 for ; Thu, 10 Sep 1998 09:48:13 -0700 (PDT) From: Volsinians@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 JAA03708 for ; Thu, 10 Sep 1998 09:48:10 -0700 Received: from imo20.mx.aol.com (imo20.mx.aol.com [198.81.17.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA04795 for ; Thu, 10 Sep 1998 09:48:10 -0700 (PDT) Received: from Volsinians@aol.com by imo20.mx.aol.com (IMOv16.1) id DXSPa08191; Thu, 10 Sep 1998 12:46:34 -0400 (EDT) Message-ID: <7bf8b563.35f8026a@aol.com> Date: Thu, 10 Sep 1998 12:46:34 EDT To: crawdad@fnal.gov Cc: ipng@sunroof.eng.sun.com, martillo@chem2.harvard.edu, Bodzia@aol.com Mime-Version: 1.0 Subject: (IPng 6424) Re: Host Fragmentation 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 9/10/98 10:13:19 AM Eastern Daylight Time, crawdad@fnal.gov writes: > > The article attached below that I recently received suggests that > > the IPv6 rule of only fragmenting at the source host really is > > rather ill-conceived. > > Joachim Martillo > > [Article about high-MTU media helping an OS with an immature IP > > stack deleted.] > I see no implications there for fragmentation at the source instead > of at a router. In fact, nothing in the article states that IP was > used for the comparison at all. The NT Server works best if it can put jumbo frames on the wire. The situation is not unusual and has no obvious correllation with the maturity of the IP stack. I have found that higher networking performance is possible with DGUX and DECUNIX when FDDI is used than when 100 Mbps ethernet is being used mostly because FDDI allows larger frames on the wire. NT Server jumbo frame performance was not unexpected. Unfortunately not every client can receive jumbo frames, and it may make sense to interpose between the server and its clients a high performance packet switch that could fragment the jumbo frames into standard maximum frames. (I think such devices were called extruders in the past.) It might make sense to use a high performance router if the server is on 1 Gbps ethernet while the clients are on some other medium. Certainly the TTI VLAN Router, for which fragmentation is almost costless, works well for such a network design either in extruder mode or in pure router mode. It makes no sense to forbid network designs that can tremendously increase system performance (as IPv6 does) especially when there is no way to distinguish between host fragmentation or router fragmentation at the client anyway. The logic of the IPv6 design with regard to the issue of fragmentation is simply impenetrable. 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 Thu Sep 10 09:56:11 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA13065 for ipng-dist; Thu, 10 Sep 1998 09:45:55 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA13058 for ; Thu, 10 Sep 1998 09:45:51 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA20370 for ; Thu, 10 Sep 1998 09:45:46 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA01371 for ipng@sunroof.eng.sun.com; Thu, 10 Sep 1998 09:44:33 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA12630 for ; Thu, 10 Sep 1998 07:02: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 HAA24852 for ; Thu, 10 Sep 1998 07:02:29 -0700 Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA25274 for ; Thu, 10 Sep 1998 07:01:10 -0700 (PDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id KAA10674; Thu, 10 Sep 1998 10:01:08 -0400 To: ipng@sunroof.eng.sun.com Path: not-for-mail From: James Carlson Newsgroups: lists.ietf.ipng Subject: (IPng 6423) Re: Host Fragmentation Date: 10 Sep 1998 10:01:08 -0400 Organization: IronBridge Networks Lines: 29 Message-ID: <86u32gdq3f.fsf@helios.nis.ironbridgenetworks.com> References: <9d7efd8a.35f79def@aol.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.2 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Volsinians@aol.com writes: > The article attached below that I recently received suggests that > the IPv6 rule of only fragmenting at the source host really is > rather ill-conceived. Huh? The load on the receiver is the same for a given medium's MTU, regardless of whether the host did the fragmentation or an intermediate router did it. This leaves only the effort involved in fragmenting on transmission as the distinguishing factor for IPv6's lack of fragmentation. Saying that network performance is more affected by the speed at which things can be sent than it is by the burden of receiving the data is a rather suspect claim. In fact, it's almost certainly false. The only things that this article might suggest to me would be: - Larger MTUs are better than smaller ones if throughput is your goal (certainly not a surprise) - NT doesn't keep up with standard Gb Ethernet (probably not a surprise) -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8190 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 10 10:16:53 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA13191 for ipng-dist; Thu, 10 Sep 1998 10:05:38 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA13184 for ; Thu, 10 Sep 1998 10:05: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 KAA09480 for ; Thu, 10 Sep 1998 10:05:12 -0700 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA15216 for ; Thu, 10 Sep 1998 10:05:14 -0700 (PDT) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Thu, 10 Sep 1998 10:05:13 -0700 Message-ID: <4FD6422BE942D111908D00805F3158DF07222893@RED-MSG-52> From: Brian Zill To: "'Matt Crawford'" , Volsinians@aol.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6425) Re: Host Fragmentation Date: Thu, 10 Sep 1998 10:05:12 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt Crawford writes: I see no implications there for fragmentation at the source instead of at a router. In fact, nothing in the article states that IP was used for the comparison at all. Yes, it was IP (TCP in fact) that was used in generating the numbers mentioned in the Infoworld article. However, I agree with Matt that this contributes nothing to the debate over where to do fragmentation. It colaborates the results previously done by the Cray folks (Dave Borman?) over HiPPI which showed for all other things equal that large MTUs are good, but that probably doesn't surprise anybody. The only IPv6 issue that this might touch on, is the recent Path MTU vs. no Path MTU debate. And there I think it shows that the decision reached in the working group (doing Path MTU is good in case larger MTUs become commonplace) was the right one. --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 10 11:07:07 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA13640 for ipng-dist; Thu, 10 Sep 1998 10:56:49 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA13633 for ; Thu, 10 Sep 1998 10:56: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 KAA28895 for ; Thu, 10 Sep 1998 10:56:33 -0700 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA16274 for ; Thu, 10 Sep 1998 10:56:33 -0700 (PDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA15814; Thu, 10 Sep 1998 13:56:25 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA04980; Thu, 10 Sep 1998 13:56:28 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id NAA21450; Thu, 10 Sep 1998 13:56:26 -0400 (EDT) Message-Id: <199809101756.NAA21450@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: Volsinians@aol.com cc: ipng@sunroof.eng.sun.com, martillo@chem2.harvard.edu Subject: (IPng 6426) Re: Host Fragmentation In-reply-to: Your message of "Thu, 10 Sep 1998 05:37:51 EDT." <9d7efd8a.35f79def@aol.com> Date: Thu, 10 Sep 1998 13:56:25 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The article attached below that I recently received suggests that > the IPv6 rule of only fragmenting at the source host really is > rather ill-conceived. Before getting all excited by this "new" revelation, it might not hurt to go review an ancient article called "fragmentation considered harmful" by Kent & Mogul published way back in SIGCOMM 87. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 10 11:07:47 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA13669 for ipng-dist; Thu, 10 Sep 1998 11:02:51 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA13662 for ; Thu, 10 Sep 1998 11:02:38 -0700 (PDT) From: Volsinians@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 LAA00696 for ; Thu, 10 Sep 1998 11:02:35 -0700 Received: from imo26.mx.aol.com (imo26.mx.aol.com [198.81.17.70]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA19883 for ; Thu, 10 Sep 1998 11:02:37 -0700 (PDT) Received: from Volsinians@aol.com by imo26.mx.aol.com (IMOv16.1) id ROJFa27969; Thu, 10 Sep 1998 14:00:18 -0400 (EDT) Message-ID: Date: Thu, 10 Sep 1998 14:00:18 EDT To: narten@raleigh.ibm.com Cc: ipng@sunroof.eng.sun.com, martillo@chem2.harvard.edu Mime-Version: 1.0 Subject: (IPng 6427) Re: Host Fragmentation 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 9/10/98 1:56:41 PM Eastern Daylight Time, narten@raleigh.ibm.com writes: > > The article attached below that I recently received suggests that > > the IPv6 rule of only fragmenting at the source host really is > > rather ill-conceived. > > Before getting all excited by this "new" revelation, it might not hurt > to go review an ancient article called "fragmentation considered > harmful" by Kent & Mogul published way back in SIGCOMM 87. Maybe it was in 1987. Eleven year old results may reasonably be questioned. In any case, if someone provides a hyperlink I will review the article relative to more contemporary hardware. 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 Thu Sep 10 11:24:33 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA13733 for ipng-dist; Thu, 10 Sep 1998 11:10:15 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA13726 for ; Thu, 10 Sep 1998 11:09: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 LAA02776 for ; Thu, 10 Sep 1998 11:09:54 -0700 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA24347 for ; Thu, 10 Sep 1998 11:09:53 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA39038; Thu, 10 Sep 1998 14:09:48 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA23528; Thu, 10 Sep 1998 14:09:48 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id OAA20786; Thu, 10 Sep 1998 14:09:47 -0400 (EDT) Message-Id: <199809101809.OAA20786@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: Volsinians@aol.com cc: ipng@sunroof.eng.sun.com, martillo@chem2.harvard.edu Subject: (IPng 6428) Re: Host Fragmentation In-reply-to: Your message of "Thu, 10 Sep 1998 14:00:18 EDT." Date: Thu, 10 Sep 1998 14:09:43 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Maybe it was in 1987. Eleven year old results may reasonably > be questioned. In any case, if someone provides a hyperlink > I will review the article relative to more contemporary hardware. I wasn't sufficiently clear in my previous message. The above paper makes a strong case that fragmentation should be done by end systems (i.e., end-to-end level) rather than by routers; I believe its arguments and conclusions are largely still accurate today. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 10 11:51:12 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA13897 for ipng-dist; Thu, 10 Sep 1998 11:39:42 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA13890 for ; Thu, 10 Sep 1998 11:39:33 -0700 (PDT) From: Volsinians@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 LAA11727 for ; Thu, 10 Sep 1998 11:39:28 -0700 Received: from imo26.mx.aol.com (imo26.mx.aol.com [198.81.17.70]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA13098 for ; Thu, 10 Sep 1998 11:39:28 -0700 (PDT) Received: from Volsinians@aol.com by imo26.mx.aol.com (IMOv16.1) id 7YNMa27970; Thu, 10 Sep 1998 14:39:13 -0400 (EDT) Message-ID: <917c7c0.35f81cd1@aol.com> Date: Thu, 10 Sep 1998 14:39:13 EDT To: carlson@ironbridgenetworks.com Cc: ipng@sunroof.eng.sun.com, Bodzia@aol.com, martillo@chem2.harvard.edu Mime-Version: 1.0 Subject: (IPng 6429) Re: Host Fragmentation 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 9/10/98 1:04:36 PM Eastern Daylight Time, carlson@ironbridgenetworks.com writes: > The load on the receiver is the same for a given medium's MTU, > regardless of whether the host did the fragmentation or an > intermediate router did it. This leaves only the effort involved in > fragmenting on transmission as the distinguishing factor for IPv6's > lack of fragmentation. Saying that network performance is more > affected by the speed at which things can be sent than it is by the > burden of receiving the data is a rather suspect claim. In fact, it's > almost certainly false. In most networked systems (but not the VLAN Router I admit), transmitting one jumboframe costs a lot less than transmitting 10 small frames. Unfortunately, we can reasonably expect that servers will get jumboframe capable adapter cards long before most clients get jumboframe capable adapter cards. With modern hardware fragmentation is almost costless [even with older hardware careful implementations could provide almost costless fragmentation -- viz The Virtual Serial Packet Device (VSPD) ]. With reasonable receive message buffer management and reasonable receive hardware, it makes little difference whether the buffers of an IP packet are filled from one received IP packet or from multiple fragments of the IP packet. Thus in the current situation to get the highest performance network service it makes sense when clients cannot receive jumbograms (the common situation), 1) for the server to transmit jumbograms, 2) to interpose a device capable of rapid fragmentation and 3) for the client to receive the fragments and reassemble the IP packet from fragments of its MRU size. For some non-obvious reason, IPv6 seems designed precisely for crippling the performance of today's networks. > The only things that this article might suggest to me would be: > - Larger MTUs are better than smaller ones if throughput is > your goal (certainly not a surprise) But then one should wonder how to optimize network performance when the receiver MRU is much lower than the transmitter MTU. > - NT doesn't keep up with standard Gb Ethernet (probably not a > surprise) Whether the server is NT or not is irrelevant. Lots of Unix network drivers could be better. But one can reasonably observe that IPv6 may force suboptimal network performance until jumbogram capable receivers are installed in network clients. Forcing suboptimal network performance indicates a failure or inadequacy of IPv6. Good engineering requires modifying IPv6 to correct this inadequacy. 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 Thu Sep 10 12:34:53 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA13988 for ipng-dist; Thu, 10 Sep 1998 12:23:05 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA13981 for ; Thu, 10 Sep 1998 12:22:54 -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 MAA24658 for ; Thu, 10 Sep 1998 12:22:43 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id MAA08505 for ; Thu, 10 Sep 1998 12:22:43 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id OAA02516; Thu, 10 Sep 1998 14:22:37 -0500 Message-Id: <199809101922.OAA02516@gungnir.fnal.gov> To: Volsinians@aol.com Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 6431) Re: Host Fragmentation In-reply-to: Your message of Thu, 10 Sep 1998 12:46:34 EDT. <7bf8b563.35f8026a@aol.com> Date: Thu, 10 Sep 1998 14:22:37 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Joachim Martillo sez: > The NT Server works best if it can put jumbo frames on the wire. > The situation is not unusual... Yes, bigger packets are good when pushing big data over short trips. This is old news. > Unfortunately not every client can receive jumbo frames, > and it may make sense to interpose between the server > and its clients a high performance packet switch that > could fragment the jumbo frames into standard maximum > frames. Now that we know (from other sources) that it is indeed TCP throughput we're talking about, the receive-side performance is clearly an issue. It is quite likely the case that the best TCP performance is had with packets that match the receiver's interface and that the answer to "where to fragment?" is "nowhere." > the TTI VLAN Router, for which fragmentation is almost costless, Yes, yes, network boxes which can fragment IP at wire speed are also very old news. But that doesn't make it a good thing to do. > The logic of the IPv6 design with regard to the issue of > fragmentation is simply impenetrable. Not if you do your homework. Oops, excuse me: > if someone provides a hyperlink I will review the article Gods forbid you should put any *effort* into establishing your argument. (Actually, if you hadn't changed your return address yet again, we wouldn't be *having* this argument.) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 10 13:00:54 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA14021 for ipng-dist; Thu, 10 Sep 1998 12:48:29 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA14014 for ; Thu, 10 Sep 1998 12:48: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 MAA00892 for ; Thu, 10 Sep 1998 12:48:16 -0700 Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA21835 for ; Thu, 10 Sep 1998 12:48:17 -0700 (PDT) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id OAA03548; Thu, 10 Sep 1998 14:48:16 -0500 (CDT) Date: Thu, 10 Sep 1998 14:48:16 -0500 (CDT) From: David Borman Message-Id: <199809101948.OAA03548@frantic.bsdi.com> To: Volsinians@aol.com Subject: (IPng 6432) Re: Host Fragmentation Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Joachim, > From: Volsinians@aol.com > Date: Thu, 10 Sep 1998 14:39:13 EDT > Subject: (IPng 6429) Re: Host Fragmentation > ... > Thus in the current situation to get the highest performance > network service it makes sense when clients cannot > receive jumbograms (the common situation), > > 1) for the server to transmit jumbograms, > > 2) to interpose a device capable of rapid fragmentation and > > 3) for the client to receive the fragments and reassemble > the IP packet from fragments of its MRU size. This ignores several things: 1) Having a device that is capable of rapid fragmentation doesn't mean that the destination host is capable of rapid reassembly. 2) The client has to reassemble those fragments before it can pass up any of the data to the next layer, introducing latency. 3) If any of the fragments gets lost, all the fragments get tossed and the sender has to resend the jumbogram, and if any of the fragments get lost, all the fragments get tossed and the sender has to resend... Many years ago when Cray computers first got TCP/IP, it was originally based on the 4.2BSD code, which didn't deal with MAXSEG and remote hosts properly. The main network attachement to the Cray was via Hyperchannel, with a 16K MTU. Two machines installed at different locations were trying to transfer data across the Arpanet, and they were sending out 16K TCP packets, which got fragmented down to 1K chunks. The connection was lossy enough that many times one of the 16 fragments would get lost, TCP would time out and retransmit another 16K packet, a fragment would get lost, and so on. You could transfer data nicely between the Cray and another remote machine that was on ethernet, due to the smaller MTU, but not between the Crays. > ... > > The only things that this article might suggest to me would be: > > > - Larger MTUs are better than smaller ones if throughput is > > your goal (certainly not a surprise) > > But then one should wonder how to optimize network performance > when the receiver MRU is much lower than the transmitter MTU. That all depends on whose performance you are trying to optimize, and what part of the network you are trying to optimize. I don't believe there is one answer that solves all situations. > ... > Joachim Martillo > Telford Tools, Inc. -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 10 13:19:21 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA14078 for ipng-dist; Thu, 10 Sep 1998 13:06:11 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id NAA14071 for ; Thu, 10 Sep 1998 13:05:48 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA21759 for ; Thu, 10 Sep 1998 13:05:47 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id NAA01738 for ipng@sunroof.eng.sun.com; Thu, 10 Sep 1998 13:04:31 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA13966 for ; Thu, 10 Sep 1998 12:16:38 -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 MAA23125 for ; Thu, 10 Sep 1998 12:16:35 -0700 Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by earth.sun.com (8.9.1/8.9.1) with SMTP id MAA05349 for ; Thu, 10 Sep 1998 12:16:36 -0700 (PDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id PAA23070; Thu, 10 Sep 1998 15:13:11 -0400 Date: Thu, 10 Sep 1998 15:13:11 -0400 Message-Id: <199809101913.PAA23070@ironbridgenetworks.com> From: James Carlson To: Volsinians@aol.com CC: ipng@sunroof.eng.sun.com, Bodzia@aol.com, martillo@chem2.harvard.edu In-reply-to: <917c7c0.35f81cd1@aol.com> (Volsinians@aol.com) Subject: (IPng 6433) Re: Host Fragmentation References: <917c7c0.35f81cd1@aol.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In most networked systems (but not the VLAN Router I admit), > transmitting one jumboframe costs a lot less than transmitting > 10 small frames. Ok, prove it. My claim is that the costs are virtually the same for transmission of small and large frames. In order to set up one large block of data, the transmitter must set up a list of buffer descriptors for the hardware DMA engine, corresponding to the memory buffers to be sent. In order to set up several small blocks of data, the transmitter must also set up a list of buffer descriptors corresponding to the memory buffers to be sent. In the best case for jumbograms -- if you assume that internal network buffers are at least as large as the MTU -- this means that you go from two memory transactions (write out length + pointer for one buffer) all the way up to twenty memory transactions (same thing 10 times). In reasonable implementations, buffers will be smaller, and the difference between the two will be correspondingly smaller. For 2KB buffers and below, there is no difference at all. Additionally, the overhead of the DMA itself is the same in both cases -- it's the same number of bytes. And the number of memory transactions is large compared to the CPU work, but is the same in both cases; perhaps 16K reads for each 64KB block of data. The rest of the transmit overhead processing is a wash. On the receive side, things are quite a bit different. Every received frame must have its Ethertype checked, its IP header validated, and then run through the per-peer reassembly list. Completed frames must be reassembled into a single IP frame (note that we've been talking about *IP* reassembly, not TCP), its IP destination address matched against the local address list, its TCP header validated, its TCP pcb located, TCP header prediction/reassembly run, and then delivered to the application. On a good day, you might be able to do the Ethernet and IP checks in 30 instructions plus about 8 memory transactions PER PACKET. So, the overhead is about 4:1 compared with the transmission overhead for the same number of packets. Thus, I claim that transmission is cheap in comparison with reception. > With reasonable receive message buffer management and > reasonable receive hardware, it makes little difference > whether the buffers of an IP packet are filled from > one received IP packet or from multiple fragments > of the IP packet. That's correct in terms of the hardware, but wrong in terms of performance. The hardware for data reception not an issue -- it's the software to handle the IP header's that's the performance-hampering issue. (In fact, I strongly suspect that, given the skimpy data and nonexistent analysis, all this test *really* proved was that either NT doesn't have decent TCP header prediction, or that it doesn't have good pcb hashing, or that it has terrible context-switching properties. Or maybe it just doesn't have the TCP window scaling option.) > Thus in the current situation to get the highest performance > network service it makes sense when clients cannot > receive jumbograms (the common situation), > > 1) for the server to transmit jumbograms, > > 2) to interpose a device capable of rapid fragmentation and > > 3) for the client to receive the fragments and reassemble > the IP packet from fragments of its MRU size. If (1) and (2) above cannot be combined for a net gain in performance, then the "server" in (1) is lame and should be replaced. > > - Larger MTUs are better than smaller ones if throughput is > > your goal (certainly not a surprise) > > But then one should wonder how to optimize network performance > when the receiver MRU is much lower than the transmitter MTU. That's exactly the point. The article you posted shows the benefits of using large MTUs on media with low error rates. It tells nothing about using fragmentation. They never even mentioned it. So how can fragmentation itself be counted on as a panacea here? > Whether the server is NT or not is irrelevant. Lots of Unix network > drivers could be better. But one can reasonably observe that > IPv6 may force suboptimal network performance until jumbogram > capable receivers are installed in network clients. Forcing > suboptimal network performance indicates a failure or > inadequacy of IPv6. Good engineering requires modifying > IPv6 to correct this inadequacy. Since smallish MTUs on Gb Ethernet isn't IPv6's fault, and since Gb Ethernet is not the only medium that IPv6 will run over, there's nothing to be fixed here. IPv6 neither knows nor cares about this oddity. Perhaps it's an issue for IEEE 802.3z ... -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8190 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 10 13:31:02 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA14115 for ipng-dist; Thu, 10 Sep 1998 13:15:59 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA14108 for ; Thu, 10 Sep 1998 13:15:45 -0700 (PDT) From: Volsinians@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 NAA07613 for ; Thu, 10 Sep 1998 13:15:41 -0700 Received: from imo27.mx.aol.com (imo27.mx.aol.com [198.81.17.71]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA06675 for ; Thu, 10 Sep 1998 13:15:43 -0700 (PDT) Received: from Volsinians@aol.com by imo27.mx.aol.com (IMOv16.1) id DDFFa11930; Thu, 10 Sep 1998 16:13:50 -0400 (EDT) Message-ID: Date: Thu, 10 Sep 1998 16:13:50 EDT To: crawdad@fnal.gov Cc: ipng@sunroof.eng.sun.com, martillo@chem2.harvard.edu, Bodzia@aol.com Mime-Version: 1.0 Subject: (IPng 6434) Re: Host Fragmentation 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 9/10/98 3:22:42 PM Eastern Daylight Time, crawdad@fnal.gov writes: > > Joachim Martillo sez: > > The NT Server works best if it can put jumbo frames on the wire. > > The situation is not unusual... > Yes, bigger packets are good when pushing big data over short trips. > This is old news. Actually, we are specifically talking about server performance. > > Unfortunately not every client can receive jumbo frames, > > and it may make sense to interpose between the server > > and its clients a high performance packet switch that > > could fragment the jumbo frames into standard maximum > > frames. > Now that we know (from other sources) that it is indeed TCP > throughput we're talking about, the receive-side performance is > clearly an issue. It is quite likely the case that the best TCP > performance is had with packets that match the receiver's interface > and that the answer to "where to fragment?" is "nowhere." TCP checksums are checked after the IP packet has been reassembled. I am not sure of the relevance to the argument. > > the TTI VLAN Router, for which fragmentation is almost costless, > Yes, yes, network boxes which can fragment IP at wire speed are also > very old news. But that doesn't make it a good thing to do. If the goal is to get best server performance when the clients cannot necessarily receive the packets that the server needs to send to get the best performance, what is wrong with using fragmentation? > > The logic of the IPv6 design with regard to the issue of > > fragmentation is simply impenetrable. > Not if you do your homework. Oops, excuse me: Optimizing the performance of networking software and hardware is not my homework. Optimizing the performance of networking software and hardware is my bread and butter. From the moment when I walk into work until the moment I leave. > > if someone provides a hyperlink I will review the article > Gods forbid you should put any *effort* into establishing your > argument. (Actually, if you hadn't changed your return address yet > again, we wouldn't be *having* this argument.) I am sorry but the burden of proof is on those that make ipse dixit arguments based on 11 year old papers. Not only do we know a lot more about software and hardware today than we did back then, but the software and hardware has changed a lot. I have no problem with studying the history of high performance packet switching systems. I include such information in a course that I occasionally teach at Harvard. But engineering is not science, there are no absolute truths and those who claim such are not doing engineering. If Mogul found fragmenting systems inadequate 11 years ago, the religious approach is too declare them evil, the engineering approach is to make incremental improvements until they work right. 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 Sep 10 13:32:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA14169 for ipng-dist; Thu, 10 Sep 1998 13:26:57 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA14161 for ; Thu, 10 Sep 1998 13:26:44 -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 NAA10578 for ; Thu, 10 Sep 1998 13:26:42 -0700 Received: from relay9.uu.net (relay9.uu.net [192.48.96.85]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA12966 for ; Thu, 10 Sep 1998 13:26:40 -0700 (PDT) Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQfggv06130; Thu, 10 Sep 1998 16:26:21 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQfggv24824; Thu, 10 Sep 1998 16:26:17 -0400 (EDT) Message-Id: To: Brian Zill cc: "'Matt Crawford'" , Volsinians@aol.com, ipng@sunroof.eng.sun.com Subject: (IPng 6435) Re: Host Fragmentation In-reply-to: Your message of "Thu, 10 Sep 1998 10:05:12 PDT." <4FD6422BE942D111908D00805F3158DF07222893@RED-MSG-52> Date: Thu, 10 Sep 1998 16:26:16 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i just hate it when my host computers have to get broken up.... -mo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 10 17:58:50 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA14823 for ipng-dist; Thu, 10 Sep 1998 17:47:02 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA14816 for ; Thu, 10 Sep 1998 17:46:14 -0700 (PDT) From: Volsinians@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 RAA29663 for ; Thu, 10 Sep 1998 17:46:13 -0700 Received: from imo15.mx.aol.com (imo15.mx.aol.com [198.81.17.5]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA23902 for ; Thu, 10 Sep 1998 17:46:15 -0700 (PDT) Received: from Volsinians@aol.com by imo15.mx.aol.com (IMOv16.1) id 7VYHa12640; Thu, 10 Sep 1998 20:45:41 +2000 (EDT) Message-ID: <80bc5576.35f872b5@aol.com> Date: Thu, 10 Sep 1998 20:45:41 EDT To: carlson@ironbridgenetworks.com Cc: ipng@sunroof.eng.sun.com, Bodzia@aol.com, martillo@chem2.harvard.edu Mime-Version: 1.0 Subject: (IPng 6436) Re: Host Fragmentation 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 9/10/98 3:16:40 PM Eastern Daylight Time, carlson@ironbridgenetworks.com writes: > > In most networked systems (but not the VLAN Router I admit), > > transmitting one jumboframe costs a lot less than transmitting > > 10 small frames. > Ok, prove it. > My claim is that the costs are virtually the same for transmission of > small and large frames. In order to set up one large block of data, > the transmitter must set up a list of buffer descriptors for the > hardware DMA engine, corresponding to the memory buffers to be sent. > In order to set up several small blocks of data, the transmitter must > also set up a list of buffer descriptors corresponding to the memory > buffers to be sent. In the best case for jumbograms -- if you assume > that internal network buffers are at least as large as the MTU -- this > means that you go from two memory transactions (write out length + > pointer for one buffer) all the way up to twenty memory transactions > (same thing 10 times). In reasonable implementations, buffers will be > smaller, and the difference between the two will be correspondingly > smaller. For 2KB buffers and below, there is no difference at all. > Additionally, the overhead of the DMA itself is the same in both cases > -- it's the same number of bytes. And the number of memory > transactions is large compared to the CPU work, but is the same in > both cases; perhaps 16K reads for each 64KB block of data. > The rest of the transmit overhead processing is a wash. The analysis of transmit DMA is not complete. In many environments either the DMA device polls, which costs transactions to memory or the DMA device must be told to start when a new message is inserted into a previously empty transmit queue. Either the transmit routine kicks the DMA device everytime a new message is inserted or there is some (potentially complex logic) to determine whether to kick the DMA device. I recommend not using the DMA polling. As for DMA transmit start logic, however implemented, the less frequently (i.e. the bigger the outgoing messages) the better. For a lot of common busses (e.g. PCI) the transactions associated with DMA start are costly. While it is not necessarily true for turnkey packet switches and file servers, standard Unix and WindowsNT file servers receive network interrupts at a rate that is monotonically increasing with the number of packets sent and received. Interrupts are bad. Instruction caches have to be invalidated. Data and instruction flow becomes non-local. System mode may have to change. Page tables may have to be changed. Look-aside tables (or whatever they are called on the current system) may be invalidated. System performance goes down. But as my partner points out, the real problem of receive and transmit performance is running the protocol stack and context switching. To get the best performance PMTU procedures should never be used. If small packets are sent out as determined by PMTU consideration, for every small packet the whole protocol stack is run and at least one context switch is made. If jumbograms are used on the server, the server runs the stack/context change once for each jumbogram whereas in the PMTU case the stack/context change will be run for each of the smaller packets. At the host that receives fragments, with a reasonable driver and reasonable memory management, with a correct fragmentation reassembly implementation, there is a performance win in gathering all the fragments together for one upstack/context change call versus one upstack/context change call for each individual packet the size of one of the packet fragments. If PMTU procedures should never be used, then in the context of IPv6, the question is the following. Why is fragmentation at the host good while fragmentation at the router is bad? There is no logical answer to the question. It is possible to build router/extruders that work at full bandwidth and completely off-load all the transmit overhead (described above) associated with host fragmentation. Why forbid such off-loading and why pay attention to such a rule as an IPv6 router could certainly fragment a packet, and there would be no way to determine that the packet was not fragmented at the host? > On the receive side, things are quite a bit different. Every received > frame must have its Ethertype checked, its IP header validated, and > then run through the per-peer reassembly list. Completed frames must > be reassembled into a single IP frame (note that we've been talking > about *IP* reassembly, not TCP), its IP destination address matched > against the local address list, its TCP header validated, its TCP pcb > located, TCP header prediction/reassembly run, and then delivered to > the application. > On a good day, you might be able to do the Ethernet and IP checks in > 30 instructions plus about 8 memory transactions PER PACKET. So, the > overhead is about 4:1 compared with the transmission overhead for the > same number of packets. > Thus, I claim that transmission is cheap in comparison with reception. Not the issue and who cares? The server may be transmitting to a thousand clients while the client receives from maybe one server. > > With reasonable receive message buffer management and > > reasonable receive hardware, it makes little difference > > whether the buffers of an IP packet are filled from > > one received IP packet or from multiple fragments > > of the IP packet. > That's correct in terms of the hardware, but wrong in terms of > performance. The hardware for data reception not an issue -- it's the > software to handle the IP header's that's the performance-hampering > issue. > (In fact, I strongly suspect that, given the skimpy data and > nonexistent analysis, all this test *really* proved was that either NT > doesn't have decent TCP header prediction, or that it doesn't have > good pcb hashing, or that it has terrible context-switching > properties. Or maybe it just doesn't have the TCP window scaling > option.) A red-herring. Even if all the costs of context-switching, PCB look-up or pcb hashing were low, why would one want to do such things many times when they could be done once? The test supported an observation that I have seen in the optimization of massive file and web server performance. There is practically nothing worse for the server than transmitting frames less than the maximum size that the server can transmit. I have seen some fairly dramatic increases in performance in merely swapping a 100 Mbps ethernet interface with an FDDI interface on DECUNIX or DG/UX. PMTU is a disaster for massive file and web server performance while off-loading the cost of fragmentation is definitely a plus. > > Thus in the current situation to get the highest performance > > network service it makes sense when clients cannot > > receive jumbograms (the common situation), > > 1) for the server to transmit jumbograms, > > 2) to interpose a device capable of rapid fragmentation and > > 3) for the client to receive the fragments and reassemble > > the IP packet from fragments of its MRU size. > If (1) and (2) above cannot be combined for a net gain in performance, > then the "server" in (1) is lame and should be replaced. The exact opposite is true because the stack/context change is run for each smaller packet. > > > - Larger MTUs are better than smaller ones if throughput is > > > your goal (certainly not a surprise) > > > > But then one should wonder how to optimize network performance > > when the receiver MRU is much lower than the transmitter MTU. > That's exactly the point. The article you posted shows the benefits > of using large MTUs on media with low error rates. It tells nothing > about using fragmentation. They never even mentioned it. So how can > fragmentation itself be counted on as a panacea here? Actually, it shows the effect of packet size on server performance. > > Whether the server is NT or not is irrelevant. Lots of Unix network > > drivers could be better. But one can reasonably observe that > > IPv6 may force suboptimal network performance until jumbogram > > capable receivers are installed in network clients. Forcing > > suboptimal network performance indicates a failure or > > inadequacy of IPv6. Good engineering requires modifying > > IPv6 to correct this inadequacy. > Since smallish MTUs on Gb Ethernet isn't IPv6's fault, and since Gb > Ethernet is not the only medium that IPv6 will run over, there's > nothing to be fixed here. IPv6 neither knows nor cares about this > oddity. Perhaps it's an issue for IEEE 802.3z ... The point is not the medium. From the standpoint of impinging server performance, if it is possible to off-load full bandwidth fragmentation (as it is) it is wrong for the server not to transmit the maximum size packets that can then be fragmented at an intermediate device. 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 Thu Sep 10 18:47:16 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id SAA14996 for ipng-dist; Thu, 10 Sep 1998 18:36:40 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id SAA14989 for ; Thu, 10 Sep 1998 18:36: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 SAA11550 for ; Thu, 10 Sep 1998 18:36:14 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA13739 for ; Thu, 10 Sep 1998 18:36:16 -0700 (PDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA17725; Thu, 10 Sep 1998 18:34:41 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id SAA10900; Thu, 10 Sep 1998 18:36:03 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA07359; Thu, 10 Sep 1998 18:36:01 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA57061; Thu, 10 Sep 1998 18:36:00 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id SAA16078; Thu, 10 Sep 1998 18:35:18 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199809110135.SAA16078@bossette.engr.sgi.com> Subject: (IPng 6437) Re: Host Fragmentation In-Reply-To: <80bc5576.35f872b5@aol.com> from "Volsinians@aol.com" at "Sep 10, 98 08:45:41 pm" To: Volsinians@aol.com Date: Thu, 10 Sep 1998 18:35:17 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Even if you _are_ right and fragmentation at source results in a few percent reduction in throughput, the discussion seems irrelevant to this list, because the chances of the feautre being changed are more or less zero. Maybe a better list would be end2end-interest, or if you'd like, I can set up a new mailing list (ipng_is_crap) which would be tailor made for your mischievous postings. Unfortunately, I couldn't help but read this thread, so here are my 2 cents worth: > The point is not the medium. From the standpoint of impinging server > performance, if it is possible to off-load full bandwidth fragmentation (as > it is) it is wrong for the server not to transmit the maximum size > packets that can then be fragmented at an intermediate device. if we assume we're talking about a Web server, then the important performance parameter is the user-percieved `speed' of the server, which is fairly far-removed from the high bandwidth stress-test bits/second figures originally discussed. Having a server send out enourmous packets to low-bandwidth clients several hops away will decrease user-percieved speed because the application will only start receiving data once the first (huge) packet has been reassembled, rather than getting a trickle of small packets which can already be put to use (user can already start reading text, interleaved images etc.) if we are talking about high-bandwidth servers (e.g. databases, image libraries) where the throughput figures discussed may be more relevent, then the issue of fragmentation in routers or in hosts isn't very relevant because fragmentation probably isn't required anyway. -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 10 23:32:39 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id XAA15196 for ipng-dist; Thu, 10 Sep 1998 23:20:15 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id XAA15189 for ; Thu, 10 Sep 1998 23:20:07 -0700 (PDT) From: Volsinians@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 XAA17109 for ; Thu, 10 Sep 1998 23:20:06 -0700 Received: from imo16.mx.aol.com (imo16.mx.aol.com [198.81.17.6]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id XAA15268 for ; Thu, 10 Sep 1998 23:20:08 -0700 (PDT) Received: from Volsinians@aol.com by imo16.mx.aol.com (IMOv16.1) id 7FQRa16074; Fri, 11 Sep 1998 02:19:46 -0400 (EDT) Message-ID: <40da73f3.35f8c102@aol.com> Date: Fri, 11 Sep 1998 02:19:46 EDT To: sm@bossette.engr.sgi.com Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6438) Re: Host Fragmentation 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 9/10/98 10:19:43 PM Eastern Daylight Time, sm@bossette.engr.sgi.com writes: > Even if you _are_ right and fragmentation at source results > in a few percent reduction in throughput, the discussion seems irrelevant > to this list, because the chances of the feautre being changed are > more or less zero. It is not an issue of a few percent. From the articles I have read, with jumbogram support NT goes from being one of the worst performing file or web servers to being the best performing file or web server. In any case, as the change to the standards that I am proposing is something that routers could do undetectably within the current framework, there is no technical reason not to change the standards. > Maybe a better list would be end2end-interest, or if you'd like, > I can set up a new mailing list (ipng_is_crap) which would be > tailor made for your mischievous postings. As part of the issue is intermediate system fragmentation, end2end-interest is not obviously appropriate. > Unfortunately, I couldn't help but read this thread, so here > are my 2 cents worth: > > The point is not the medium. From the standpoint of impinging server > > performance, if it is possible to off-load full bandwidth fragmentation (as > > it is) it is wrong for the server not to transmit the maximum size > > packets that can then be fragmented at an intermediate device. > if we assume we're talking about a Web server, then the important > performance parameter is the user-percieved `speed' of the server, > which is fairly far-removed from the high bandwidth stress-test > bits/second figures originally discussed. Having a server send out > enourmous packets to low-bandwidth clients several hops away will > decrease user-percieved speed because the application will only > start receiving data once the first (huge) packet has been reassembled, > rather than getting a trickle of small packets which can already > be put to use (user can already start reading text, interleaved images > etc.) It is not a reasonable argument to assume that we are talking about low bandwidth clients a few hops away. Web servers and web clients are used in high bandwidth campus environments. Why should those environments be crippled just because there are users that have low bandwidth clients over low bandwidth connects? And in any case, I have to point out that we recently put together a dual 400 Mhz pentium processor machine with 2 independent PCI busses (thus two gigabits of I/O bandwidth) for under $2000. Where I live, I am told that I can get 6 Mbps connectivity to the internet in November for under $100/month. Assuming that high bandwidth clients will be few and far between in the near-term may not be realistic. > if we are talking about high-bandwidth servers (e.g. databases, image > libraries) where the throughput figures discussed may be more relevent, > then the issue of fragmentation in routers or in hosts isn't very relevant > because fragmentation probably isn't required anyway. This seems like precisely the environment where servers might have jumbogram capable adapter cards while clients might not. 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 Sep 11 05:19:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA15478 for ipng-dist; Fri, 11 Sep 1998 05:03:30 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA15471 for ; Fri, 11 Sep 1998 05:03:19 -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 FAA13477 for ; Fri, 11 Sep 1998 05:03:17 -0700 Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by earth.sun.com (8.9.1/8.9.1) with SMTP id FAA13627 for ; Fri, 11 Sep 1998 05:03:18 -0700 (PDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id IAA00082; Fri, 11 Sep 1998 08:03:14 -0400 Date: Fri, 11 Sep 1998 08:03:14 -0400 Message-Id: <199809111203.IAA00082@ironbridgenetworks.com> From: James Carlson To: Volsinians@aol.com CC: ipng@sunroof.eng.sun.com, Bodzia@aol.com, martillo@chem2.harvard.edu In-reply-to: <80bc5576.35f872b5@aol.com> (Volsinians@aol.com) Subject: (IPng 6439) Re: Host Fragmentation References: <80bc5576.35f872b5@aol.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The analysis of transmit DMA is not complete. In many environments > either the DMA device polls, which costs transactions to memory or the > DMA device must be told to start when a new message is inserted into a > previously empty transmit queue. Either the transmit routine kicks > the DMA device everytime a new message is inserted or there is some > (potentially complex logic) to determine whether to kick the DMA > device. I recommend not using the DMA polling. As for DMA transmit > start logic, however implemented, the less frequently (i.e. the bigger > the outgoing messages) the better. For a lot of common busses > (e.g. PCI) the transactions associated with DMA start are costly. No devices that I've ever used have a hardware transmit or receive queue of length one. Perhaps your experience is different. Again, my previous post gave details on why transmitting packets is much easier than receiving. Your post contains no such details. > While it is not necessarily true for turnkey packet switches and file > servers, standard Unix and WindowsNT file servers receive network > interrupts at a rate that is monotonically increasing with the number > of packets sent and received. True. That's why having fewer, bigger packets in general is helpful, and that's why your original article showed what it did. This is nothing new. And it proves nothing at all about fragmentation one way or the other. > Interrupts are bad. Instruction caches have to be invalidated. Data > and instruction flow becomes non-local. System mode may have to > change. Page tables may have to be changed. Look-aside tables (or > whatever they are called on the current system) may be invalidated. > System performance goes down. It depends. Many systems have optimized upper and lower interrupt handlers so that this is not so much an issue. (Think of BSD's soft interrupt scheme for IP input; the same can be done for Ethernet input handlers.) > But as my partner points out, the real problem of receive and transmit > performance is running the protocol stack and context switching. To > get the best performance PMTU procedures should never be used. PMTU has nothing to do with this. Small MTUs do have something to do with it. > If jumbograms are used on the server, the server runs the > stack/context change once for each jumbogram whereas in the PMTU case > the stack/context change will be run for each of the smaller > packets. That's not necessarily so. When your TCP window opens and you can send a number of packets, you can certainly do so with no context changes whatsoever. If multiple short trips over the IP output path cause trouble, then perhaps this is what needs to be optimized. > At the host that receives fragments, with a reasonable driver and > reasonable memory management, with a correct fragmentation reassembly > implementation, there is a performance win in gathering all the > fragments together for one upstack/context change call versus one > upstack/context change call for each individual packet the size of one > of the packet fragments. If you have a context change problem after reassembly occurs, then perhaps that's what you should spend some time optimizing. Such a context change is not necessary. > If PMTU procedures should never be used, then in the context of IPv6, > the question is the following. > > Why is fragmentation at the host good while fragmentation at the > router is bad? IPv4 fragmentation does not have TCP's congestion management mechanism. One lost fragment causes the remaining mess to sit in local buffers for a long period of time before being discarded, and the entire packet has to be resent. TCP, on the other hand, will quickly resend the one missing piece and continue on its way. That's why IPv4 fragmentation isn't as good as TCP's segmentation. Given a choice, I want segmentation, not fragmentation. I didn't say that IPv4 fragmentation at the host is "good" and that at the router it's "bad." I did say that they were equivalent. If it amuses you to do IPv4 fragmentation instead of TCP segmentation, then you can freely do so in your IP output path by having IP lie to TCP about the MTU. This involves no context switches and only minimal overhead. > There is no logical answer to the question. It is possible to build > router/extruders that work at full bandwidth and completely off-load > all the transmit overhead (described above) associated with host > fragmentation. Why forbid such off-loading and why pay attention to > such a rule as an IPv6 router could certainly fragment a packet, and > there would be no way to determine that the packet was not fragmented > at the host? Once again, your original posting had nothing whatsoever to say about the relative merits of fragmenting in a router versus fragmenting in a host. > > (In fact, I strongly suspect that, given the skimpy data and > > nonexistent analysis, all this test *really* proved was that either NT > > doesn't have decent TCP header prediction, or that it doesn't have > > good pcb hashing, or that it has terrible context-switching > > properties. Or maybe it just doesn't have the TCP window scaling > > option.) > > A red-herring. Even if all the costs of context-switching, > PCB look-up or pcb hashing were low, why would one > want to do such things many times when they could > be done once? Because, if they are low, then the benefits of TCP's far more elegent reassembly algorithm can be used. > The test supported an observation that I have seen in the optimization > of massive file and web server performance. Supporting a result is not the same as duplicating it. The article that you posted talked about Gb Ethernet transfers using large packets between peers. This has little to do with web server design or performance. > There is practically > nothing worse for the server than transmitting frames less than the > maximum size that the server can transmit. I have seen some fairly > dramatic increases in performance in merely swapping a 100 Mbps > ethernet interface with an FDDI interface on DECUNIX or DG/UX. This proves only that large packets are better. We're back where we started. It proves nothing about fragmentation. > PMTU > is a disaster for massive file and web server performance while > off-loading the cost of fragmentation is definitely a plus. To prove this, as this article most certainly does NOT do, you'll need to use this set-up: Server machine <--large-MTU--> router <--small-MTU--> peer Over this, run a long-term test with two cases: 1. No PMTU, IPv4 fragmentation 2. PMTU, no IPv4 fragmentation Then determine what happens when the "small-MTU" link -- which happens to correspond with the general Internet in most cases -- experiences congestion. (This can be modeled as random packet discards.) The result, as has been shown many times, is that for trivial cases, where there is absolutely no packet loss and no congestion, these cases are approximately the same (with case 1 being a percent or so faster; your mileage will vary). These are the kinds of tests usually run for those trade rag articles. If, however, any congestion at all is encountered, case 2 wins every time by a country mile. > > If (1) and (2) above cannot be combined for a net gain in performance, > > then the "server" in (1) is lame and should be replaced. > > The exact opposite is true because the stack/context change is run for > each smaller packet. If you require a context change during IP fragmentation, then I'd say your stack needs a serious overhaul. If the stack changes cause noticable degradation, then in-line the code or special-case it. I stand by the earlier comment. If there's any measurable difference, then this server should be replaced. There's no good reason a router should be able to do IPv4 fragmentation any faster than a good host can do it. > > That's exactly the point. The article you posted shows the benefits > > of using large MTUs on media with low error rates. It tells nothing > > about using fragmentation. They never even mentioned it. So how can > > fragmentation itself be counted on as a panacea here? > > Actually, it shows the effect of packet size on server performance. No, it shows the effect of MTU on performance between peers. There's a big difference here. > The point is not the medium. From the standpoint of impinging server > performance, if it is possible to off-load full bandwidth fragmentation (as > it is) it is wrong for the server not to transmit the maximum size > packets that can then be fragmented at an intermediate device. The point, at least for the article you posted, is exactly the effect of the small Gb Ethernet MTU. The article said nothing at all about fragmentation at an intermediate device. That would be a different test. -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8190 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 08:21:33 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA15626 for ipng-dist; Fri, 11 Sep 1998 08:10:17 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA15615 for ; Fri, 11 Sep 1998 08:09:54 -0700 (PDT) From: Volsinians@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 IAA05285 for ; Fri, 11 Sep 1998 08:09:37 -0700 Received: from imo15.mx.aol.com (imo15.mx.aol.com [198.81.17.5]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA01618 for ; Fri, 11 Sep 1998 08:09:37 -0700 (PDT) Received: from Volsinians@aol.com by imo15.mx.aol.com (IMOv16.1) id 7YZIa12640; Fri, 11 Sep 1998 11:08:01 -0400 (EDT) Message-ID: <7682890f.35f93cd1@aol.com> Date: Fri, 11 Sep 1998 11:08:01 EDT To: carlson@ironbridgenetworks.com Cc: ipng@sunroof.eng.sun.com, Bodzia@aol.com, martillo@chem2.harvard.edu Mime-Version: 1.0 Subject: (IPng 6441) Re: Host Fragmentation 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 9/11/98 8:34:27 AM Eastern Daylight Time, carlson@ironbridgenetworks.com writes: > > The analysis of transmit DMA is not complete. In many environments > > either the DMA device polls, which costs transactions to memory or the > > DMA device must be told to start when a new message is inserted into a > > previously empty transmit queue. Either the transmit routine kicks > > the DMA device everytime a new message is inserted or there is some > > (potentially complex logic) to determine whether to kick the DMA > > device. I recommend not using the DMA polling. As for DMA transmit > > start logic, however implemented, the less frequently (i.e. the bigger > > the outgoing messages) the better. For a lot of common busses > > (e.g. PCI) the transactions associated with DMA start are costly. > No devices that I've ever used have a hardware transmit or receive > queue of length one. Perhaps your experience is different. Again, my > previous post gave details on why transmitting packets is much easier > than receiving. Your post contains no such details. I have to doubt whether you have ever programmed common networking devices like the AMD LANCE, AMD ILAC, DC21040, DC21041, DC21140, DC21143 or even the NSC 8390 > > While it is not necessarily true for turnkey packet switches and file > > servers, standard Unix and WindowsNT file servers receive network > > interrupts at a rate that is monotonically increasing with the number > > of packets sent and received. > True. That's why having fewer, bigger packets in general is helpful, > and that's why your original article showed what it did. This is > nothing new. And it proves nothing at all about fragmentation one way > or the other. If fragmentation is done at the Intermediate System, the host may transmit larger frames. > > Interrupts are bad. Instruction caches have to be invalidated. Data > > and instruction flow becomes non-local. System mode may have to > > change. Page tables may have to be changed. Look-aside tables (or > > whatever they are called on the current system) may be invalidated. > > System performance goes down. > It depends. Many systems have optimized upper and lower interrupt > handlers so that this is not so much an issue. (Think of BSD's soft > interrupt scheme for IP input; the same can be done for Ethernet input > handlers.) Is it being claimed that in common virtual memory multimode interrupt scheduled operating systems, upon receiving an interrupt (in this case a tx done interrupt so that IP input is not relevant) data and instruction flow does not become non-local, system mode does not often change, page tables never have to change and virtual address translation tables do not get invalidated? > > But as my partner points out, the real problem of receive and transmit > > performance is running the protocol stack and context switching. To > > get the best performance PMTU procedures should never be used. > PMTU has nothing to do with this. Small MTUs do have something to do > with it. PMTU procedures would force the jumbogram capable adapter to use a small MTU. > > If jumbograms are used on the server, the server runs the > > stack/context change once for each jumbogram whereas in the PMTU case > > the stack/context change will be run for each of the smaller > > packets. > That's not necessarily so. When your TCP window opens and you can > send a number of packets, you can certainly do so with no context > changes whatsoever. If multiple short trips over the IP output path > cause trouble, then perhaps this is what needs to be optimized. Suppose creating a TCP header for a 1500 byte packet takes ~400 instruction executions and ~4000 instruction executions for a 15000 byte packet. Between 10 1500 byte packets and 1 15000 byte packets, there is not much difference. Suppose the reast of the transmission costs about 400 instructions of which 150 instructions relate to creating individual IP headers (I think an underestimate of the cost of out of order execution and cache invalidation), DMA start and transmit done and the other 250 relate to transmitting 1 1500 byte buffer. To transmit 1 1500 byte packets should cost ~4000 + 150 + 2500 instructions or approximately 6650 instructions. To transmit 10 1500 byte packets costs ~8000 instructions. Thus, sending 10 1500 byte packets could cause ~ 17% more instruction execution. The percent is not inconsiderable, and I believe I am underestimating costs associated with cache misses, out of order execution and mode changes. > > At the host that receives fragments, with a reasonable driver and > > reasonable memory management, with a correct fragmentation reassembly > > implementation, there is a performance win in gathering all the > > fragments together for one upstack/context change call versus one > > upstack/context change call for each individual packet the size of one > > of the packet fragments. > If you have a context change problem after reassembly occurs, then > perhaps that's what you should spend some time optimizing. Such a > context change is not necessary. No context change is necessary to get the data into the user application? > > If PMTU procedures should never be used, then in the context of IPv6, > > the question is the following. > > Why is fragmentation at the host good while fragmentation at the > > router is bad? > IPv4 fragmentation does not have TCP's congestion management > mechanism. One lost fragment causes the remaining mess to sit in > local buffers for a long period of time before being discarded, and > the entire packet has to be resent. TCP, on the other hand, will > quickly resend the one missing piece and continue on its way. There is a misconception here about typical tcp retransmit time outs. Hardware based packet switches often have a problem with local buffering, but that problem is not confined to lost fragments. Hardware based packet switching is an incorrect approach, and kludges to fix the unfixable problems associated with hardware based packet switching problems should not be standardized. The repetitive loss of the same fragment was a result of memory starved systems. Not a problem today. In any case, the issue is not whether to fragment. There are applications that work much better when fragmentation is used (even applications that use TCP). The issue is where to fragment as IPv6 hosts are allowed to fragment. If IPv6 hosts are allowed to fragment, it might make more sense to fragment at an intermediate system. The IPv6 restriction that only hosts should fragment is pointless and silly. BTW, I have certainly designed packet switching systems that are not subject to congestion loss problems. If congestion loss of fragments is not occurring, why not fragment? In any case as fragmentation is permitted at the host in IPv6, why not fragment at the Intermediate system? > That's why IPv4 fragmentation isn't as good as TCP's segmentation. > Given a choice, I want segmentation, not fragmentation. They are both techniques that have their own realms of application. In some cases, IP packets containing TCP packets can be fragmented to benefit. > I didn't say that IPv4 fragmentation at the host is "good" and that at > the router it's "bad." I did say that they were equivalent. If it > amuses you to do IPv4 fragmentation instead of TCP segmentation, then > you can freely do so in your IP output path by having IP lie to TCP > about the MTU. This involves no context switches and only minimal > overhead. The only issue is the IPv6 rule against intermediate system fragmentation. There is no reason for it, it cannot even be enforced, and it should be trashed. > > There is no logical answer to the question. It is possible to build > > router/extruders that work at full bandwidth and completely off-load > > all the transmit overhead (described above) associated with host > > fragmentation. Why forbid such off-loading and why pay attention to > > such a rule as an IPv6 router could certainly fragment a packet, and > > there would be no way to determine that the packet was not fragmented > > at the host? > Once again, your original posting had nothing whatsoever to say about > the relative merits of fragmenting in a router versus fragmenting in a > host. Only if one refuses to read and understand what I am saying. > > > (In fact, I strongly suspect that, given the skimpy data and > > > nonexistent analysis, all this test *really* proved was that either NT > > > doesn't have decent TCP header prediction, or that it doesn't have > > > good pcb hashing, or that it has terrible context-switching > > > properties. Or maybe it just doesn't have the TCP window scaling > > > option.) > > A red-herring. Even if all the costs of context-switching, > > PCB look-up or pcb hashing were low, why would one > > want to do such things many times when they could > > be done once? > Because, if they are low, then the benefits of TCP's far more elegent > reassembly algorithm can be used. Nothing stops the simultaneous use of IP fragmentation/reassembly along with TCP. > > The test supported an observation that I have seen in the optimization > > of massive file and web server performance. > Supporting a result is not the same as duplicating it. The article > that you posted talked about Gb Ethernet transfers using large packets > between peers. This has little to do with web server design or > performance. We have some experience in the optimization of web server performance beyond just that article. Improving transmit performance improves web server performance. Sending larger packets improves transmit performance. The ability to send jumbopackets when web clients do not have jumbogram capabilities requires intermediate system fragmentation. > > There is practically > > nothing worse for the server than transmitting frames less than the > > maximum size that the server can transmit. I have seen some fairly > > dramatic increases in performance in merely swapping a 100 Mbps > > ethernet interface with an FDDI interface on DECUNIX or DG/UX. > This proves only that large packets are better. We're back where we > started. It proves nothing about fragmentation. If the server can send jumbograms and the client cannot receive them, the obvious way to optimize web server performance is intermediate system fragmentation. > > PMTU > > is a disaster for massive file and web server performance while > > off-loading the cost of fragmentation is definitely a plus. > To prove this, as this article most certainly does NOT do, you'll need > to use this set-up: > Server machine <--large-MTU--> router <--small-MTU--> peer > Over this, run a long-term test with two cases: > 1. No PMTU, IPv4 fragmentation > 2. PMTU, no IPv4 fragmentation We do the test all the time. PMTU procedures are a disaster. > Then determine what happens when the "small-MTU" link -- which happens > to correspond with the general Internet in most cases -- experiences > congestion. (This can be modeled as random packet discards.) > The result, as has been shown many times, is that for trivial cases, > where there is absolutely no packet loss and no congestion, these > cases are approximately the same (with case 1 being a percent or so > faster; your mileage will vary). These are the kinds of tests usually > run for those trade rag articles. If, however, any congestion at all > is encountered, case 2 wins every time by a country mile. Not true in the case of the high performance servers that we support. > > > If (1) and (2) above cannot be combined for a net gain in performance, > > > then the "server" in (1) is lame and should be replaced. > > The exact opposite is true because the stack/context change is run for > > each smaller packet. > If you require a context change during IP fragmentation, then I'd say > your stack needs a serious overhaul. If the stack changes cause > noticable degradation, then in-line the code or special-case it. I > stand by the earlier comment. If there's any measurable difference, > then this server should be replaced. There's no good reason a router > should be able to do IPv4 fragmentation any faster than a good host > can do it. IP fragmentation requires no context switch. On multimode, virtual memory, interrupt scheduled systems like Unix or WindowsNT, a context switch is considerably more than a stack change. > > > That's exactly the point. The article you posted shows the benefits > > > of using large MTUs on media with low error rates. It tells nothing > > > about using fragmentation. They never even mentioned it. So how can > > > fragmentation itself be counted on as a panacea here? > > Actually, it shows the effect of packet size on server performance. > No, it shows the effect of MTU on performance between peers. There's > a big difference here. It identified achievable throughput on a PCI bus system. Such throughput reflects on possible server performance. > > The point is not the medium. From the standpoint of impinging server > > performance, if it is possible to off-load full bandwidth fragmentation ( > as > > it is) it is wrong for the server not to transmit the maximum size > > packets that can then be fragmented at an intermediate device. > The point, at least for the article you posted, is exactly the effect > of the small Gb Ethernet MTU. The article said nothing at all about > fragmentation at an intermediate device. That would be a different > test. But it did fairly explicityly indicate lower throughput when not using jumbograms. If jumbogram capability is not available on one side, the only way to make any use of jumbograms is to use an intermediate fragmentationdevice. 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 Fri Sep 11 09:46:25 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA15830 for ipng-dist; Fri, 11 Sep 1998 09:31:23 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA15823 for ; Fri, 11 Sep 1998 09:31:05 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA28416 for ; Fri, 11 Sep 1998 09:31:02 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA03446 for ipng@sunroof.eng.sun.com; Fri, 11 Sep 1998 09:29:35 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA15567 for ; Fri, 11 Sep 1998 07:12: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 HAA25060 for ; Fri, 11 Sep 1998 07:12:45 -0700 Received: from databus.databus.com (databus.databus.com [198.186.154.34]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA01783 for ; Fri, 11 Sep 1998 07:12:44 -0700 (PDT) From: Barney Wolff To: ipng@sunroof.eng.sun.com Date: Fri, 11 Sep 1998 10:08 EDT Subject: (IPng 6442) Re: Host Fragmentation Content-Type: text/plain Message-ID: <35f92fc80.28fb@databus.databus.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, I don't understand the terms of the debate. The scenario of a server-class machine with jumbo-ether capability and client(s) without is certainly possible, but, please, how did the client know to send a TCP MSS option much bigger than its own MTU? So the server is stuck sending little segs, regardless. Barney Wolff -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 09:46:53 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA15873 for ipng-dist; Fri, 11 Sep 1998 09:36:33 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA15866 for ; Fri, 11 Sep 1998 09:36:24 -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 JAA29485 for ; Fri, 11 Sep 1998 09:36:19 -0700 Received: from relay4.UU.NET (relay4.UU.NET [192.48.96.14]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA23794 for ; Fri, 11 Sep 1998 09:36:17 -0700 (PDT) Received: from dogbert.alteon.com by relay4.UU.NET with SMTP (peer crosschecked as: alteon.com [208.200.21.146]) id QQfgjy15821; Fri, 11 Sep 1998 12:36:09 -0400 (EDT) Received: from sharks.alteon.com ([205.178.13.72]) by dogbert.alteon.com via smtpd (for relay4.UU.NET [192.48.96.14]) with SMTP; 11 Sep 1998 16:35:32 UT Received: from coastsider.acteon.com by sharks.alteon.com (SMI-8.6/SMI-SVR4) id JAA09636; Fri, 11 Sep 1998 09:35:13 -0700 Received: by coastsider.acteon.com (5.x/SMI-SVR4) id AA12894; Fri, 11 Sep 1998 09:30:05 -0700 Date: Fri, 11 Sep 1998 09:30:05 -0700 From: wayne@alteon.com (Wayne Hathaway) Message-Id: <9809111630.AA12894@coastsider.acteon.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 6443) Re: Host Fragmentation Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm quoting Dave Borman, but the same idea has appeared three or four times now: > 1) Having a device that is capable of rapid fragmentation > doesn't mean that the destination host is capable of > rapid reassembly. That might be true if the world were symmetrical, but it is not. Instead, the world is primarily LARGE SERVERS FEEDING HUNDREDS OF SMALL CLIENTS. The server of course wants to send as fast as possible. If it is on Gigabit Ethernet, then using a large MTU clearly increases its maximum sending rate. (The article that started this thread demonstrates that point nicely, as do many other test results. In spite of numerous attempts to prove that this bumblebee can't fly.) A decent router should be able to fragment at wire speed no matter what the wire, so network fragmentation shouldn't be a bottleneck. And since client connections are typically Ethernet or much less, even the smallest client should have no trouble reassembling fast enough. That is, a server is sending much more data than a SINGLE client is receiving. The bottleneck is indeed sending speed and not receiving speed. This does not address the issue of RELIABILITY, of course, and the need to retransmit an entire TCP segment for a single lost fragment. Clearly fragmentation should be avoided over unreliable paths. Nobody is claiming otherwise. (And by the way, TCP itself could help a lot with avoiding fragmentation, simply by decreasing segment size when it sees retransmissions. That is, don't react by sending fewer segments, react by sending smaller ones.) The point is that it is silly for a protocol of the future to outlaw the use of network fragmentation simply because there are situations in which it might be bad with current router or host stack implementations. Wayne Hathaway Internet: wayne@alteon.com Chief Architect Phone: 408-360-5503 Alteon Networks FAX: 408-360-5501 6351 San Ignacio Avenue San Jose, CA 95119 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 10:08:39 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA15967 for ipng-dist; Fri, 11 Sep 1998 09:53:32 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA15956 for ; Fri, 11 Sep 1998 09:53: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 JAA05676 for ; Fri, 11 Sep 1998 09:53:00 -0700 Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by earth.sun.com (8.9.1/8.9.1) with SMTP id JAA04575 for ; Fri, 11 Sep 1998 09:52:46 -0700 (PDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id MAA23660; Fri, 11 Sep 1998 12:52:42 -0400 Date: Fri, 11 Sep 1998 12:52:42 -0400 Message-Id: <199809111652.MAA23660@ironbridgenetworks.com> From: James Carlson To: Volsinians@aol.com CC: ipng@sunroof.eng.sun.com, Bodzia@aol.com, martillo@chem2.harvard.edu In-reply-to: <7682890f.35f93cd1@aol.com> (Volsinians@aol.com) Subject: (IPng 6444) Re: Host Fragmentation References: <7682890f.35f93cd1@aol.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have to doubt whether you have ever programmed common > networking devices like the That's nice. I'm sure you have my resume and references at hand before you begin a stupid insult. > > It depends. Many systems have optimized upper and lower interrupt > > handlers so that this is not so much an issue. (Think of BSD's soft > > interrupt scheme for IP input; the same can be done for Ethernet input > > handlers.) > > Is it being claimed that in common virtual memory multimode > interrupt scheduled operating systems, upon receiving an > interrupt (in this case a tx done interrupt so that IP input is > not relevant) data and instruction flow does not become non-local, > system mode does not often change, page tables never have > to change and virtual address translation tables do not get > invalidated? Again, it depends. In the system I'm working on at the moment (BSD-derived), I take one interrupt when the number of free TX buffers goes above a water mark, and I then fill a large number of them on the one interrupt. Taking one interrupt per frame is possible, but silly. Of course, that's just the Ethernet handler. The IP stack is separate and responds much better. A trace through it shows that with normal TCP acks, an entire window's worth is dumped into the Ethernet output queue (the software ifnet queue, not the hardware) in one context switch. This supports my contention that IPv4 fragmentation, which is done in a tight loop in netinet/ip_output.c *after* peeling off a single TCP segment for transmission in netinet/tcp_output.c, is approximately as expensive as sending really big frames. > > PMTU has nothing to do with this. Small MTUs do have something to do > > with it. > > PMTU procedures would force the jumbogram capable adapter > to use a small MTU. Too bad the article you cite doesn't support your conclusion. > > If you have a context change problem after reassembly occurs, then > > perhaps that's what you should spend some time optimizing. Such a > > context change is not necessary. > > No context change is necessary to get the data into the > user application? No, I didn't say that. I said that if you have a context change between IPv4 reassembly and TCP input handling -- which would be the only difference in receiving multiple IPv4 fragments versus receiving one big packet -- then that context change is silly. > Hardware based packet switches often have a problem > with local buffering, but that problem is not confined to > lost fragments. Hardware based packet switching is > an incorrect approach, and kludges to fix the unfixable > problems associated with hardware based packet > switching problems should not be standardized. Huh? Who was talking about packet switching? I'm talking about what's necessary to do IPv4 *REASSEMBLY* versus TCP segmentation. > The repetitive loss of the same fragment was > a result of memory starved systems. Not a > problem today. Huh? Port congestion is a fact of life. Even infinite buffering won't save you if you're cramming 2Gbps down a 1Gbps pipe. Losing packets is a fact of life. Failing to recover from that gracefully -- which TCP does do, and IP doesn't -- is a severe flaw. > > That's why IPv4 fragmentation isn't as good as TCP's segmentation. > > Given a choice, I want segmentation, not fragmentation. > > They are both techniques that have their own realms of > application. In some cases, IP packets containing TCP > packets can be fragmented to benefit. IPv4 fragmentation and reassembly are lame enough that it's not worth working on them in comparison to working on the link layers themselves. > > I didn't say that IPv4 fragmentation at the host is "good" and that at > > the router it's "bad." I did say that they were equivalent. If it > > amuses you to do IPv4 fragmentation instead of TCP segmentation, then > > you can freely do so in your IP output path by having IP lie to TCP > > about the MTU. This involves no context switches and only minimal > > overhead. > > The only issue is the IPv6 rule against intermediate system > fragmentation. There is no reason for it, it cannot > even be enforced, and it should be trashed. You haven't bothered proving your point. > Only if one refuses to read and understand what I am saying. Fine. I obviously made a horrible mistake in reading carefully each of your posts. Last reply from me. > > 1. No PMTU, IPv4 fragmentation > > 2. PMTU, no IPv4 fragmentation > > We do the test all the time. PMTU procedures are a disaster. Proof? > Not true in the case of the high performance servers that > we support. Does "high performance" measure only dumping bits on the wire or does it measure application throughput? These are quite different. > IP fragmentation requires no context switch. On multimode, > virtual memory, interrupt scheduled systems like Unix > or WindowsNT, a context switch is considerably more than > a stack change. Nor does TCP segmentation require a context switch. Shall I post lines 78 through 591 of NetBSD sys/netinet/tcp_output.c? If you have it at hand, examine carefully what the "sendalot" flag does. > > The point, at least for the article you posted, is exactly the effect > > of the small Gb Ethernet MTU. The article said nothing at all about > > fragmentation at an intermediate device. That would be a different > > test. > > But it did fairly explicityly indicate lower throughput when not > using jumbograms. If jumbogram capability is not available > on one side, the only way to make any use of jumbograms > is to use an intermediate fragmentationdevice. Did you read your own posting? Here's what it really said: [...] Large Ethernet frames can improve the efficiency of Gigabit Ethernet by reducing the number of frames that must be created and forwarded. Packing more data in a single frame can boost performance on server-to-server applications, transmitting large amounts of data in one stream, such as backups and replication. The tests were conducted using a single-processor Intel 400-MHz Xeon-based server and four 333-MHz Pentium II clients. An Alteon Gigabit Ethernet server switch connected the servers and clients. Earlier tests using standard Ethernet frames have shown performance from 500Mbps to 600Mbps, said Reza Baghai, NT performance lead engineer at Microsoft. Alteon is the only Gigabit Ethernet vendor currently supporting large Ethernet frames. However, Baghai said Microsoft has had discussions with other vendors about using large frame sizes. [...] Did you somehow read fragmentation into that? If so, then where? I see two systems connected back-to-back through a switch supporting jumbograms and Gb Ethernet. There's no new data of interest here, and you've failed to make your point. -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8190 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 10:29:33 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA16072 for ipng-dist; Fri, 11 Sep 1998 10:15:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA16061 for ; Fri, 11 Sep 1998 10:15:10 -0700 (PDT) From: Volsinians@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 KAA13669 for ; Fri, 11 Sep 1998 10:15:07 -0700 Received: from imo17.mx.aol.com (imo17.mx.aol.com [198.81.17.7]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA19329 for ; Fri, 11 Sep 1998 10:15:06 -0700 (PDT) Received: from Volsinians@aol.com by imo17.mx.aol.com (IMOv16.1) id HUNFa20006; Fri, 11 Sep 1998 13:14:45 -0400 (EDT) Message-ID: <243556e2.35f95a85@aol.com> Date: Fri, 11 Sep 1998 13:14:45 EDT To: barney@databus.com Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6445) Re: Host Fragmentation 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 9/11/98 1:01:46 PM Eastern Daylight Time, barney@databus.com writes: > Folks, I don't understand the terms of the debate. The scenario of a > server-class machine with jumbo-ether capability and client(s) without > is certainly possible, but, please, how did the client know to send a > TCP MSS option much bigger than its own MTU? So the server is stuck > sending little segs, regardless. The client can pick any MSS option it wants. MTU size has does not necessarily have bearing on the value. 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 Fri Sep 11 12:04:38 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA16164 for ipng-dist; Fri, 11 Sep 1998 11:52:15 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA16157 for ; Fri, 11 Sep 1998 11:52: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 LAA16470 for ; Fri, 11 Sep 1998 11:51:57 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id LAA24955 for ; Fri, 11 Sep 1998 11:51:53 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id NAA07219; Fri, 11 Sep 1998 13:51:52 -0500 Message-Id: <199809111851.NAA07219@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 6446) Re: Host Fragmentation In-reply-to: Your message of Fri, 11 Sep 1998 10:08:00 EDT. <35f92fc80.28fb@databus.databus.com> Date: Fri, 11 Sep 1998 13:51:52 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Barney Wolff tries to inject reality: > is certainly possible, but, please, how did the client know to send a > TCP MSS option much bigger than its own MTU? So the server is stuck > sending little segs, regardless. Didn't you know? The magic fragmenting box in the middle will intercept the SYN packets and didle the MSS option! (Now I live in fear that someone will implement this joke.) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 14:16:55 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA16378 for ipng-dist; Fri, 11 Sep 1998 14:03:57 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA16371 for ; Fri, 11 Sep 1998 14:03:45 -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 OAA25173 for ; Fri, 11 Sep 1998 14:03:43 -0700 Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA11690 for ; Fri, 11 Sep 1998 14:03:42 -0700 (PDT) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id QAA06958; Fri, 11 Sep 1998 16:03:39 -0500 (CDT) Date: Fri, 11 Sep 1998 16:03:39 -0500 (CDT) From: David Borman Message-Id: <199809112103.QAA06958@frantic.bsdi.com> To: Volsinians@aol.com Subject: (IPng 6447) Re: Host Fragmentation Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Volsinians@aol.com > Date: Fri, 11 Sep 1998 02:19:46 EDT > Subject: (IPng 6438) Re: Host Fragmentation > ... > It is not an issue of a few percent. From the articles I have > read, with jumbogram support NT goes from being one > of the worst performing file or web servers to being > the best performing file or web server. Sorry, I just can't pass this up without comment... Many years ago, when Van Jacobson was asked for his opinion about a scheme of using large HIPPI packets (>64K) to bundle multiple IP packets together to improve throughput, his reply was more or less that if you need to have huge packets to get your throughput, you either have broken hardware or broken software. Hmmm, I wonder which it is for this case? :-) Just because something seems to work doesn't necessarily make it the right thing to do. -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 11 15:33:06 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA16483 for ipng-dist; Fri, 11 Sep 1998 15:17:49 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA16476 for ; Fri, 11 Sep 1998 15:17: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 PAA19716 for ; Fri, 11 Sep 1998 15:17:22 -0700 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA22942 for ; Fri, 11 Sep 1998 15:17:22 -0700 (PDT) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Fri, 11 Sep 1998 15:17:21 -0700 Message-ID: <4FD6422BE942D111908D00805F3158DF07222899@RED-MSG-52> From: Brian Zill To: "'David Borman'" , Volsinians@aol.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6448) Re: Host Fragmentation Date: Fri, 11 Sep 1998 15:17:17 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: David Borman [SMTP:dab@BSDI.COM] > Sent: Friday, September 11, 1998 2:04 PM > Subject: (IPng 6447) Re: Host Fragmentation > > > From: Volsinians@aol.com > > Date: Fri, 11 Sep 1998 02:19:46 EDT > > Subject: (IPng 6438) Re: Host Fragmentation > > ... > > It is not an issue of a few percent. From the articles I have > > read, with jumbogram support NT goes from being one > > of the worst performing file or web servers to being > > the best performing file or web server. > > Sorry, I just can't pass this up without comment... > Well, in that case, neither can I... The jumbogram support is not the only change made recently to NT's TCP/IP stack. The recent performance improvements can be attributed to several factors, and not solely (and possibly not primarily, I don't have the breakdown) the use of jumbo frames. --Brian BTW Dave, are you saying that you could achive the same performance from 1500 MTU packets as 64 KB packets when you were at Cray? :-) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 15:46:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA16499 for ipng-dist; Fri, 11 Sep 1998 15:32:31 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA16490 for ; Fri, 11 Sep 1998 15:32: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 PAA23341 for ; Fri, 11 Sep 1998 15:32:15 -0700 Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA00258 for ; Fri, 11 Sep 1998 15:32:13 -0700 (PDT) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id RAA07023; Fri, 11 Sep 1998 17:32:09 -0500 (CDT) Date: Fri, 11 Sep 1998 17:32:09 -0500 (CDT) From: David Borman Message-Id: <199809112232.RAA07023@frantic.bsdi.com> To: bzill@microsoft.com Subject: (IPng 6449) Re: Host Fragmentation Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Brian Zill > Subject: RE: (IPng 6447) Re: Host Fragmentation > Date: Fri, 11 Sep 1998 15:17:17 -0700 >... > BTW Dave, are you saying that you could achive the same performance from > 1500 MTU packets as 64 KB packets when you were at Cray? :-) Nope. Not even with 32K packets. Cray computers were never good at dealing with lots of interrupts. They couldn't handle tens of thousands of interrupts per second. They could pump the data in and out and process the data, they just couldn't deal with heavy interrupt loads. -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Sep 12 05:32:31 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA16982 for ipng-dist; Sat, 12 Sep 1998 05:17:39 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA16975 for ; Sat, 12 Sep 1998 05:17:30 -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 FAA18915 for ; Sat, 12 Sep 1998 05:17:26 -0700 Received: from solen.ce.chalmers.se (solen.ce.chalmers.se [129.16.20.244]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA12257 for ; Sat, 12 Sep 1998 05:17:27 -0700 (PDT) Received: from cepc30.ce.chalmers.se (otel@cepc30.ce.chalmers.se [129.16.20.144]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id OAA03237; Sat, 12 Sep 1998 14:17:25 +0200 (MET DST) From: Otel Florian-Daniel Received: (from otel@localhost) by cepc30.ce.chalmers.se (8.8.7/8.8.5) id OAA01180; Sat, 12 Sep 1998 14:21:24 GMT Date: Sat, 12 Sep 1998 14:21:24 GMT Message-Id: <199809121421.OAA01180@cepc30.ce.chalmers.se> To: Barney Wolff Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6450) Re: Host Fragmentation In-Reply-To: <35f92fc80.28fb@databus.databus.com> References: <35f92fc80.28fb@databus.databus.com> X-Mailer: VM 6.34 under 20.2 XEmacs Lucid Reply-To: otel@ce.chalmers.se Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Folks, I don't understand the terms of the debate. The scenario of a > server-class machine with jumbo-ether capability and client(s) without > is certainly possible, but, please, how did the client know to send a > TCP MSS option much bigger than its own MTU? So the server is stuck > sending little segs, regardless. No, server just disabled its TCP MSS option and relys on IP Fragmentation... :) > Barney Wolff -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 13 14:09:17 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA17379 for ipng-dist; Sun, 13 Sep 1998 13:55:50 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA17372 for ; Sun, 13 Sep 1998 13:55:41 -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 NAA16801 for ; Sun, 13 Sep 1998 13:55:40 -0700 Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA25377 for ; Sun, 13 Sep 1998 13:55:39 -0700 (PDT) Received: from alden (alvestrand.kvatro.no [193.216.167.143]) by dokka.maxware.no (8.8.5/8.8.5) with SMTP id WAA04070 for ; Sun, 13 Sep 1998 22:55:37 +0200 Message-Id: <3.0.2.32.19980913225547.01712470@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Sun, 13 Sep 1998 22:55:47 +0200 To: ipng@sunroof.eng.sun.com From: Harald Tveit Alvestrand Subject: (IPng 6451) Query: Performance analysis of AAAA vs A6 records? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPNG WG seems to have decided that it wants to introduce a new record type for IPv6 addresses called "A6", which has the property of recording the site-designated suffix of an address rather than a whole address. How to get that record type deployed is now an NGTRANS issue. Questions for this community: - When analyzing performance of the record types, what are the relative number of DNS queries expected for a client looking up an AAAA record and constructing an address from an A6 record chain? - If the answer to the above depends strongly on the use of "additional information" in DNS answer packets, what is the average size of DNS responses expected when an A6 record is queried? - Do the answers to the two above questions change when security implications are considered (cache poisoning, for instance)? The context for which I'm asking these questions is to look at whether it's an appropriate transition/coexistence strategy to ask a DNS server to synthesize AAAA records when needed, removing the need to transition clients, rather than asking clients to switch to looking for A6 records. Apologies if these numbers/issues have been discussed to death earlier - yes, I'm too lazy to spend the night reading archives! Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.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 Mon Sep 14 10:10:20 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA17934 for ipng-dist; Mon, 14 Sep 1998 09:59:28 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA17927 for ; Mon, 14 Sep 1998 09:59:16 -0700 (PDT) From: Volsinians@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 JAA24337 for ; Mon, 14 Sep 1998 09:59:10 -0700 Received: from imo22.mx.aol.com (imo22.mx.aol.com [198.81.17.66]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA23233 for ; Mon, 14 Sep 1998 09:59:05 -0700 (PDT) Received: from Volsinians@aol.com by imo22.mx.aol.com (IMOv16.1) id DMLWa12057; Mon, 14 Sep 1998 12:58:54 -0400 (EDT) Message-ID: Date: Mon, 14 Sep 1998 12:58:54 EDT To: crawdad@fnal.gov Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6453) Re: Host Fragmentation 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 9/10/98 3:55:12 PM Eastern Daylight Time, crawdad@fnal.gov writes: > > Joachim Martillo sez: > > The NT Server works best if it can put jumbo frames on the wire. > > The situation is not unusual... > Yes, bigger packets are good when pushing big data over short trips. > This is old news. > > Unfortunately not every client can receive jumbo frames, > > and it may make sense to interpose between the server > > and its clients a high performance packet switch that > > could fragment the jumbo frames into standard maximum > > frames. > Now that we know (from other sources) that it is indeed TCP > throughput we're talking about, the receive-side performance is > clearly an issue. It is quite likely the case that the best TCP > performance is had with packets that match the receiver's interface > and that the answer to "where to fragment?" is "nowhere." Currently, we do this sort of test like everyone else with a massive server and many clients. The receivers have no problem in receiving their datastreams as fast as the datastream is sent to them. > > the TTI VLAN Router, for which fragmentation is almost costless, > Yes, yes, network boxes which can fragment IP at wire speed are also > very old news. But that doesn't make it a good thing to do. Common systems like the X windows system, which often usess TCP, make use of fragmentation either by the host or by the network. This use of fragmentation has proven beneficial. > > The logic of the IPv6 design with regard to the issue of > > fragmentation is simply impenetrable. > Not if you do your homework. Oops, excuse me: We run the tests all the time. That seems more like doing valid homework than referring to articles that are essentially an aeon old for this business. > > if someone provides a hyperlink I will review the article > Gods forbid you should put any *effort* into establishing your > argument. (Actually, if you hadn't changed your return address yet > again, we wouldn't be *having* this argument.) Referring to an ancient article, which is as far as I can tell unavailable in DEC's archives or at the Harvard Science Center Library, hardly counts as establishing one's argument. Anyway, I will check out McKay and Baker, but my fax (617-298-1745) is on if anyone would be so kind as to fax the article to me. 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 Sep 14 11:10:58 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA17991 for ipng-dist; Mon, 14 Sep 1998 11:01:02 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA17984 for ; Mon, 14 Sep 1998 11:00:54 -0700 (PDT) From: Volsinians@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 LAA20833 for ; Mon, 14 Sep 1998 11:00:45 -0700 Received: from imo12.mx.aol.com (imo12.mx.aol.com [198.81.17.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA09209 for ; Mon, 14 Sep 1998 11:00:34 -0700 (PDT) Received: from Volsinians@aol.com by imo12.mx.aol.com (IMOv16.1) id 1IHEa14123; Mon, 14 Sep 1998 14:00:15 -0400 (EDT) Message-ID: Date: Mon, 14 Sep 1998 14:00:15 EDT To: dab@BSDI.COM Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6454) Re: Host Fragmentation 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 9/10/98 4:15:52 PM Eastern Daylight Time, dab@BSDI.COM writes: > Joachim, > > From: Volsinians@aol.com > > Date: Thu, 10 Sep 1998 14:39:13 EDT > > Subject: (IPng 6429) Re: Host Fragmentation > > ... > > Thus in the current situation to get the highest performance > > network service it makes sense when clients cannot > > receive jumbograms (the common situation), > > 1) for the server to transmit jumbograms, > > 2) to interpose a device capable of rapid fragmentation and > > 3) for the client to receive the fragments and reassemble > > the IP packet from fragments of its MRU size. > This ignores several things: > 1) Having a device that is capable of rapid fragmentation > doesn't mean that the destination host is capable of > rapid reassembly. Not a common problem nowadays as far as I can determine. > 2) The client has to reassemble those fragments before > it can pass up any of the data to the next layer, > introducing latency. As the reconstruction of the original packet occurs as the fragments of the original packet are being received and as the reception is slower than the reconstruction, with careful coding the introduced latency is vanishingly small especially when compared with the latencies introduced by sending smaller non-fragmented packets upstack. > 3) If any of the fragments gets lost, all the fragments > get tossed and the sender has to resend the jumbogram, > and if any of the fragments get lost, all the fragments > get tossed and the sender has to resend... If fragments are getting lost and there is a lot of retransmission, the situation can be detected and upper protocol layers that can undertake to make sure that fragmentation does not take place. > Many years ago when Cray computers first got TCP/IP, it was originally > based on the 4.2BSD code, which didn't deal with MAXSEG and remote > hosts properly. The main network attachement to the Cray was via > Hyperchannel, with a 16K MTU. Two machines installed at different > locations were trying to transfer data across the Arpanet, and they > were sending out 16K TCP packets, which got fragmented down to 1K > chunks. The connection was lossy enough that many times one of the > 16 fragments would get lost, TCP would time out and retransmit another > 16K packet, a fragment would get lost, and so on. You could transfer > data nicely between the Cray and another remote machine that was on > ethernet, due to the smaller MTU, but not between the Crays. A better implementation of TCP could have dealt with the problem. > > ... > > > The only things that this article might suggest to me would be: > > > - Larger MTUs are better than smaller ones if throughput is > > > your goal (certainly not a surprise) > > But then one should wonder how to optimize network performance > > when the receiver MRU is much lower than the transmitter MTU. > That all depends on whose performance you are trying to optimize, > and what part of the network you are trying to optimize. I don't > believe there is one answer that solves all situations. Is not the attempt to impose one solution for everything one of the major problems with IPv6? The situation of a massive file server with a jumbogram capable adapter card and many non-jumbogram capable clients is exactly a situation, that the current specification of IPv6 does not handle well because IPv6 imposes a single solution (host fragmentation) that simply does not apply in all cases. The IPv6 imposition is particularly silly because there is no way for the receiving host to distinguish permitted host fragmentation from forbidden network fragmentation. 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 Sep 14 12:09:09 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA18105 for ipng-dist; Mon, 14 Sep 1998 11:58:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA18096 for ; Mon, 14 Sep 1998 11:58: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 LAA11718 for ; Mon, 14 Sep 1998 11:58:08 -0700 Received: from gecko.nas.nasa.gov (gecko.nas.nasa.gov [129.99.50.17]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA18247 for ; Mon, 14 Sep 1998 11:58:10 -0700 (PDT) Received: from gecko.nas.nasa.gov (kml@localhost) by gecko.nas.nasa.gov (8.8.7/NAS8.8.7) with ESMTP id LAA13707; Mon, 14 Sep 1998 11:58:01 -0700 (PDT) Message-Id: <199809141858.LAA13707@gecko.nas.nasa.gov> To: Volsinians@aol.com cc: ipng@sunroof.eng.sun.com Subject: (IPng 6456) Re: Host Fragmentation In-reply-to: Your message of "Mon, 14 Sep 1998 14:00:15 EDT." Date: Mon, 14 Sep 1998 11:58:01 -0700 From: "Kevin M. Lahey" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message Volsinians@aol.com writes >Is not the attempt to impose one solution for everything one >of the major problems with IPv6? The situation of a massive >file server with a jumbogram capable adapter card and >many non-jumbogram capable clients is exactly a >situation, that the current specification of IPv6 does >not handle well because IPv6 imposes a single >solution (host fragmentation) that simply does not >apply in all cases. With a massive file server, I'd like to be able to *write* quickly, too. Do you propose to have your router reassemble fragmented packets as they go by to present the server with large packets as input? That is no more permissable under IPv4 than it is under IPv6; will that stop you? I think, but I'm not sure, that IPv9 and IPv17 are available if you'd like to define your own standads. :-) Kevin kml@nas.nasa.gov -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 13:23:49 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA18176 for ipng-dist; Mon, 14 Sep 1998 13:11:34 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA18169 for ; Mon, 14 Sep 1998 13:11:26 -0700 (PDT) From: Volsinians@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 NAA04289 for ; Mon, 14 Sep 1998 13:11:22 -0700 Received: from imo15.mx.aol.com (imo15.mx.aol.com [198.81.17.5]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA01602 for ; Mon, 14 Sep 1998 13:11:24 -0700 (PDT) Received: from Volsinians@aol.com by imo15.mx.aol.com (IMOv16.1) id 7HXEa12639; Mon, 14 Sep 1998 16:09:03 -0400 (EDT) Message-ID: <4aa50f1e.35fd77df@aol.com> Date: Mon, 14 Sep 1998 16:09:03 EDT To: carlson@ironbridgenetworks.com Cc: ipng@sunroof.eng.sun.com, Bodzia@aol.com, martillo@chem2.harvard.edu Mime-Version: 1.0 Subject: (IPng 6457) Re: Host Fragmentation 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 9/11/98 1:23:44 PM Eastern Daylight Time, carlson@ironbridgenetworks.com writes: > > I have to doubt whether you have ever programmed common > > networking devices like the > That's nice. I'm sure you have my resume and references at hand > before you begin a stupid insult. Do I detect defensiveness? Noting seeming unfamiliarity with a class of devices is hardly an insult. Noone can be familiar with every device. Carlson need only have pointed out that I was mistaken and that he had indeed programmed one of the devices that I had mentioned. BTW, I do put my resume on line ( Joachim Martillo ) and provide a full WAN-LAN level2/level3 switch router for download at my web site ( Telford Tools, Inc. ). If one is going to take part in discussions that lead to the definition of an international standard protocol, one has an obligation to describe what one has done and show what one can do. > > > It depends. Many systems have optimized upper and lower interrupt > > > handlers so that this is not so much an issue. (Think of BSD's soft > > > interrupt scheme for IP input; the same can be done for Ethernet input > > > handlers.) > > Is it being claimed that in common virtual memory multimode > > interrupt scheduled operating systems, upon receiving an > > interrupt (in this case a tx done interrupt so that IP input is > > not relevant) data and instruction flow does not become non-local, > > system mode does not often change, page tables never have > > to change and virtual address translation tables do not get > > invalidated? > Again, it depends. In the system I'm working on at the moment > (BSD-derived), I take one interrupt when the number of free TX buffers > goes above a water mark, and I then fill a large number of them on the > one interrupt. Taking one interrupt per frame is possible, but silly. May I ask what the underlying hardware interface device is? I think the SPYDER-S and SPYDER-T had built-in free list manipulation, but these devices only used the free buffer pool for receive. From the description, I am not sure what happens in the case of multiple output interfaces, where several interfaces are disconnected and one can still transmit. If the buffers from the disconnected interface are not returned to the free pool so that the water mark is hit, does the system stop transmitting out the working interface. The interface actually sounds rather hideous. I do not remember such a mechanism in BSD, but I had to deal with something like this at Prime when Sachs standardized hardware communications on OS/x86. The watermark interrupt was a software interrupt that added a layer of complexity, indirection and performance hit on top of the hardware interrupts. > Of course, that's just the Ethernet handler. The IP stack is separate > and responds much better. A trace through it shows that with normal > TCP acks, an entire window's worth is dumped into the Ethernet output > queue (the software ifnet queue, not the hardware) in one context > switch. > This supports my contention that IPv4 fragmentation, which is done in > a tight loop in netinet/ip_output.c *after* peeling off a single TCP > segment for transmission in netinet/tcp_output.c, is approximately as > expensive as sending really big frames. Point? In the case under discussion, the fragmentation takes place at an intermediate system off the file/web server. The idea is to run with TCP windows and max segment size far larger than a single ether MTU. > > > PMTU has nothing to do with this. Small MTUs do have something to do > > > with it. > > PMTU procedures would force the jumbogram capable adapter > > to use a small MTU. > Too bad the article you cite doesn't support your conclusion. Carlson must go back and reread the article and the discussion. > > > If you have a context change problem after reassembly occurs, then > > > perhaps that's what you should spend some time optimizing. Such a > > > context change is not necessary. > > No context change is necessary to get the data into the > > user application? > No, I didn't say that. I said that if you have a context change > between IPv4 reassembly and TCP input handling -- which would be the > only difference in receiving multiple IPv4 fragments versus receiving > one big packet -- then that context change is silly. I agree. I think I have only seen such things in streams based TCP/IP stacks, and they are silly. > > Hardware based packet switches often have a problem > > with local buffering, but that problem is not confined to > > lost fragments. Hardware based packet switching is > > an incorrect approach, and kludges to fix the unfixable > > problems associated with hardware based packet > > switching problems should not be standardized. > Huh? Who was talking about packet switching? I'm talking about > what's necessary to do IPv4 *REASSEMBLY* versus TCP segmentation. The issue was not IPv4 REASSEMBLY versus TCP segmentation. The issue was *host* versus *network* fragmentation. Network fragmentation takes place in packet switches. Carlson simply interjected a whole bunch of irrelevant detail. IPv6 permits host fragmentation but forbids network fragmentation. This rule makes no sense and guarantees bad performance in common situations. > > The repetitive loss of the same fragment was > > a result of memory starved systems. Not a > > problem today. > Huh? Port congestion is a fact of life. Even infinite buffering > won't save you if you're cramming 2Gbps down a 1Gbps pipe. Losing > packets is a fact of life. Failing to recover from that gracefully -- > which TCP does do, and IP doesn't -- is a severe flaw. Memory starved intermediate systems are not a problem today. In the networks where a massive server serves a multitude of clients interclient communications represents occasional noise. I am not sure what the point about IP means as few applications run raw IP. If port congestion is due a statistical fluctuation, having a long queue helps. If it is endemic, some traffic reengineering must be performed, to wit, if some large number tcp sessions entering the intermediate system through some large number of input ports are typically trying to send packets through a single output port on some intermediate systems, TCP windowing mechanisms are generally inadequate to correct the problem, for it is quite possible that none of the TCP sessions are making much of a demand on bandwidth. > > > That's why IPv4 fragmentation isn't as good as TCP's segmentation. > > > Given a choice, I want segmentation, not fragmentation. > > They are both techniques that have their own realms of > > application. In some cases, IP packets containing TCP > > packets can be fragmented to benefit. > IPv4 fragmentation and reassembly are lame enough that it's not worth > working on them in comparison to working on the link layers > themselves. Not relevant to the issue of a jumbogram capable server with clients that are not jumbogram capable. > > > I didn't say that IPv4 fragmentation at the host is "good" and that at > > > the router it's "bad." I did say that they were equivalent. If it > > > amuses you to do IPv4 fragmentation instead of TCP segmentation, then > > > you can freely do so in your IP output path by having IP lie to TCP > > > about the MTU. This involves no context switches and only minimal > > > overhead. > > The only issue is the IPv6 rule against intermediate system > > fragmentation. There is no reason for it, it cannot > > even be enforced, and it should be trashed. > You haven't bothered proving your point. The Alteon demonstration proves the point. > > Only if one refuses to read and understand what I am saying. > Fine. I obviously made a horrible mistake in reading carefully each > of your posts. Last reply from me. > > > 1. No PMTU, IPv4 fragmentation > > > 2. PMTU, no IPv4 fragmentation > > We do the test all the time. PMTU procedures are a disaster. > Proof? PMTU procedures in the Alteon demonstration would have lead to ~500-600Mbps performance rather than 940Mbps. I cannot understand how it could be more clear. > > Not true in the case of the high performance servers that > > we support. > Does "high performance" measure only dumping bits on the wire or does > it measure application throughput? These are quite different. We run client applications to their maximum during these tests. The goal is to support as many clients as possible. > > IP fragmentation requires no context switch. On multimode, > > virtual memory, interrupt scheduled systems like Unix > > or WindowsNT, a context switch is considerably more than > > a stack change. > Nor does TCP segmentation require a context switch. Shall I post > lines 78 through 591 of NetBSD sys/netinet/tcp_output.c? If you have > it at hand, examine carefully what the "sendalot" flag does. While not the main point, there will be far more context switches at the receiver if max segment is set so that the server sends out smaller frames. At 10 to 20 times more context switches the difference in client performance probably becomes noticeable. Even if client performance is not an issue, I calculate at least approximately 20% performance hit in using standard ethernet MTU while the Alteon test indicates a 50% performance hit simply from transmitting smaller frames at the server. > > > The point, at least for the article you posted, is exactly the effect > > > of the small Gb Ethernet MTU. The article said nothing at all about > > > fragmentation at an intermediate device. That would be a different > > > test. > > But it did fairly explicityly indicate lower throughput when not > > using jumbograms. If jumbogram capability is not available > > on one side, the only way to make any use of jumbograms > > is to use an intermediate fragmentationdevice. > Did you read your own posting? Here's what it really said: > [...] > Large Ethernet frames can improve the efficiency of Gigabit Ethernet > by reducing the number of frames that must be created and forwarded. > Packing more data in a single frame can boost performance on > server-to-server applications, transmitting large amounts of data in > one stream, such as backups and replication. > The tests were conducted using a single-processor Intel 400-MHz > Xeon-based server and four 333-MHz Pentium II clients. An Alteon > Gigabit Ethernet server switch connected the servers and clients. > Earlier tests using standard Ethernet frames have shown performance > from 500Mbps to 600Mbps, said Reza Baghai, NT performance lead > engineer at Microsoft. > Alteon is the only Gigabit Ethernet vendor currently supporting large > Ethernet frames. However, Baghai said Microsoft has had discussions > with other vendors about using large frame sizes. > [...] > Did you somehow read fragmentation into that? If so, then where? I > see two systems connected back-to-back through a switch supporting > jumbograms and Gb Ethernet. There's no new data of interest here, and > you've failed to make your point. The setup as I understood it from this article and from the other available Alteon literature said that performance went from ~500-600Mbps to 940 Mbps per second when an Alteon jumbogram adaptercard is installed in the server. The server connects to an Alteon fragmentation bridge/extruder. The clients have 100 Mbps Ethercards. Such setups are pretty much standard for testing webserver and fileserver performances. 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 Sep 14 17:16:48 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA18613 for ipng-dist; Mon, 14 Sep 1998 17:06:05 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA18606 for ; Mon, 14 Sep 1998 17:05:54 -0700 (PDT) From: Volsinians@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 RAA21095 for ; Mon, 14 Sep 1998 17:05:49 -0700 Received: from imo28.mx.aol.com (imo28.mx.aol.com [198.81.17.72]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA16044 for ; Mon, 14 Sep 1998 17:05:51 -0700 (PDT) Received: from Volsinians@aol.com by imo28.mx.aol.com (IMOv16.1) id 9DJLa24183; Mon, 14 Sep 1998 20:01:47 +2000 (EDT) Message-ID: Date: Mon, 14 Sep 1998 20:01:47 EDT To: kml@nas.nasa.gov Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6458) Re: Host Fragmentation 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 9/14/98 3:14:39 PM Eastern Daylight Time, kml@nas.nasa.gov writes: > In message Volsinians@aol.com writes > >Is not the attempt to impose one solution for everything one > >of the major problems with IPv6? The situation of a massive > >file server with a jumbogram capable adapter card and > >many non-jumbogram capable clients is exactly a > >situation, that the current specification of IPv6 does > >not handle well because IPv6 imposes a single > >solution (host fragmentation) that simply does not > >apply in all cases. > > With a massive file server, I'd like to be able to *write* quickly, > too. Do you propose to have your router reassemble fragmented packets > as they go by to present the server with large packets as input? > That is no more permissable under IPv4 than it is under IPv6; > will that stop you? I think the main issue of massive server performance is not understood. Network reads and writes across 10/100Mbps media at best are not so fast. The goal is not faster reads or writes, but to support a massive number of clients, which means that the server must be able to deliver as much data per second as possible to the communications subnet. For some reason, the designers of IPv6 are apparently insisting on crippling the common configuration of a massive server with numerous lower-speed clients. I cannot think of a better way to guarantee that IPv6 will quickly fade into oblivion. For IPv6 to avoid this fate, the rather arbitrary and impossible to enforce restriction against network fragmentation need only be written out of the specification. Why is it so difficult to make such a minor change? In any case, with regard to the question asked, if you want to write faster to the file server, I think you have to start with getting a network interface faster than 100Mbps. I am not sure network reassembly is so much forbidden as impossible because there is no way to guarantee that fragments will pass through the same intermediate system except in the case of a leaf network that connects to the larger internet through a single packet switch. 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 Sep 14 19:16:35 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA18714 for ipng-dist; Mon, 14 Sep 1998 19:00:32 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id TAA18707 for ; Mon, 14 Sep 1998 19:00:20 -0700 (PDT) From: Volsinians@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 TAA12634 for ; Mon, 14 Sep 1998 19:00:17 -0700 Received: from imo14.mx.aol.com (imo14.mx.aol.com [198.81.17.4]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA00942 for ; Mon, 14 Sep 1998 19:00:20 -0700 (PDT) Received: from Volsinians@aol.com by imo14.mx.aol.com (IMOv16.1) id 1YTJa09043; Mon, 14 Sep 1998 21:59:59 +2000 (EDT) Message-ID: Date: Mon, 14 Sep 1998 21:59:59 EDT To: dab@BSDI.COM Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6459) Re: Host Fragmentation 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 9/11/98 5:20:29 PM Eastern Daylight Time, dab@BSDI.COM writes: > > From: Volsinians@aol.com > > Date: Fri, 11 Sep 1998 02:19:46 EDT > > Subject: (IPng 6438) Re: Host Fragmentation > > ... > > It is not an issue of a few percent. From the articles I have > > read, with jumbogram support NT goes from being one > > of the worst performing file or web servers to being > > the best performing file or web server. > Sorry, I just can't pass this up without comment... > Many years ago, when Van Jacobson was asked for his opinion about > a scheme of using large HIPPI packets (>64K) to bundle multiple IP > packets together to improve throughput, his reply was more or less > that if you need to have huge packets to get your throughput, you > either have broken hardware or broken software. Hmmm, I wonder > which it is for this case? :-) The formulation of the comment of Van Jacobson is somewhat non-specific, because I am not sure what the scenario is, but I suspect that some sort of point to point situation is meant where multiple IP packets with the same source and destination are meant. I am not sure I would agree with the statement even in the case that I am surmising, for the definition of huge packets is somewhat application-dependent. Nevertheless, I doubt that Van Jacobson was addressing the case where increasing throughput relates to increasing the number of clients served. I suspect that he was relating throughput to the amount of bandwidth attainable on a single TCP/IP virtual circuit. The problems are not the same, and the current specification of IPv6 makes addressing the problem of increasing massive file server throughput difficult. > Just because something seems to work doesn't necessarily make it > the right thing to do. An improper solution in one situation may be a complete proper solution in another situation 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 Sep 14 19:20:31 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA18723 for ipng-dist; Mon, 14 Sep 1998 19:08:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id TAA18716 for ; Mon, 14 Sep 1998 19:08:32 -0700 (PDT) From: Volsinians@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 TAA13969 for ; Mon, 14 Sep 1998 19:08:30 -0700 Received: from imo21.mx.aol.com (imo21.mx.aol.com [198.81.17.65]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA03604 for ; Mon, 14 Sep 1998 19:08:32 -0700 (PDT) Received: from Volsinians@aol.com by imo21.mx.aol.com (IMOv16.1) id LCWOa11275; Mon, 14 Sep 1998 22:08:05 +2000 (EDT) Message-ID: <70867b9e.35fdcc05@aol.com> Date: Mon, 14 Sep 1998 22:08:05 EDT To: bzill@microsoft.com, dab@BSDI.COM Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6460) Re: Host Fragmentation 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 9/11/98 6:39:21 PM Eastern Daylight Time, bzill@microsoft.com writes: > The jumbogram support is not the only change made recently to NT's TCP/IP > stack. The recent performance improvements can be attributed to several > factors, and not solely (and possibly not primarily, I don't have the > breakdown) the use of jumbo frames. Here are the most important data of the announcement. Microsoft officials said they achieved 920Mbps throughput on a server using the AceNIC 180, a Gigabit Ethernet network interface card from Alteon, which also supplied the proprietary jumbo-frame technology. [some text deleted] The tests were conducted using a single-processor Intel 400-MHz Xeon-based server and four 333-MHz Pentium II clients. An Alteon Gigabit Ethernet server switch connected the servers and clients. Earlier tests using standard Ethernet frames have shown performance from 500Mbps to 600Mbps, said Reza Baghai, NT performance lead engineer at Microsoft. There is no mention of changing the TCP/IP stack, and in any case the results parallel what we have seen in a Unix environment that uses jumbogram capable gigabit adapters in the file server. 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 Sep 14 19:27:54 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA18745 for ipng-dist; Mon, 14 Sep 1998 19:19:00 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id TAA18738 for ; Mon, 14 Sep 1998 19:18:46 -0700 (PDT) From: Volsinians@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 TAA15340 for ; Mon, 14 Sep 1998 19:18:44 -0700 Received: from imo25.mx.aol.com (imo25.mx.aol.com [198.81.17.69]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA07005 for ; Mon, 14 Sep 1998 19:18:47 -0700 (PDT) Received: from Volsinians@aol.com by imo25.mx.aol.com (IMOv16.1) id LMHSa18399; Mon, 14 Sep 1998 22:16:52 +2000 (EDT) Message-ID: <9c2b9493.35fdce14@aol.com> Date: Mon, 14 Sep 1998 22:16:52 EDT To: bzill@microsoft.com, crawdad@fnal.gov Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6461) Re: Host Fragmentation 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 9/10/98 1:36:37 PM Eastern Daylight Time, bzill@microsoft.com writes: > Yes, it was IP (TCP in fact) that was used in generating the numbers > mentioned in the Infoworld article. > However, I agree with Matt that this contributes nothing to the debate over > where to do fragmentation. Only if the article is not read carefully. The article fairly clearly implies that at least 50% greater throughput is obtainable if fragmentation is done at the intermediate system. > It corroborates the results previously done by > the Cray folks (Dave Borman?) over HiPPI which showed for all other things > equal that large MTUs are good, but that probably doesn't surprise anybody. Was the Cray being used as a massive file server or web server for a multitude of clients? If not, drawing conclusions with regard to where best to perform fragmentation in the massive file server environment is not justified. > The only IPv6 issue that this might touch on, is the recent Path MTU vs. no > Path MTU debate. And there I think it shows that the decision reached in > the working group (doing Path MTU is good in case larger MTUs become > commonplace) was the right one. PMTU procedures in the situation described in the article would force at best 600 Mbps of throughput at the file rather than the > 900 Mbps of throughput that was attainable by using jumbograms and intermediate system fragmentation. 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 Sep 15 03:47:06 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id DAA19021 for ipng-dist; Tue, 15 Sep 1998 03:36:39 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id DAA19014 for ; Tue, 15 Sep 1998 03:36: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 DAA02380 for ; Tue, 15 Sep 1998 03:36:29 -0700 Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA27970 for ; Tue, 15 Sep 1998 03:36:29 -0700 (PDT) Received: from jimmy.trumpet.com.au (jimmy.trumpet.com.au [203.5.119.2]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id UAA20522 for ; Tue, 15 Sep 1998 20:36:28 +1000 (EST) (envelope-from pete@trumpet.com.au) To: ipng@sunroof.eng.sun.com From: pete@trumpet.com.au (Peter R. Tattam) Subject: (IPng 6462) Questions about PPP over Ipv6. Date: Tue, 15 Sep 1998 20:35:58 +1100 Message-ID: <3d0d9a9$1f4@jimmy.trumpet.com.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Some of you may know that I've just released a beta for Trumpet Winsock 4.1 last week. I'd like to work on PPP but I can't figure out what the spec requires for header compression. I see an internet draft for generic header compression but I'm not sure if that's supposed to be the standard that everyone's operating to. Can someone point me in the right direction? Also, one other question... the token for PPP is 32 bits. It seems a little small, and since it differs from the token size of 48 bits for ethernet, it makes stateless address config somewhat inconsistent with what might be advertised on a LAN. Can one assume that the other end of the PPP link will be advertising routes with the correct size prefix for autoconfig? What would be the defined method of allocating a PPP prefix from a site's prefix. One obviously has to choose addresses that won't clash with existing ethernet addresses. It seems to me that stateless address config only works adequately if the universe of known interfaces all share the same address size, or that if there are mixed address size, that a smaller addresses must be concatenated with an address prefix to pad it out to the largest address size with the prefix being chosen uniquely. This begs the question, is there a standard prefix for PPP which prevents the PPP address from clashing with the known universe of Ethernet addresses. (It would be rather expensive on ethernet addresses as it would require 256 ethernet manufacturer allocations.) I see in some of the internet drafts that addresses used for stateless config are padded out to 64 bits before being appended to the site prefix. Is this designed to deal with the problem (I presume so)? If so, when is the practice likely to come into play and is there a transition mechanism for the current practice of *only* accepting prefixes that make the total add up to 128 bits? Pardon my ignorance if these are standard newbie questions. Peter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 15 04:20:44 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA19089 for ipng-dist; Tue, 15 Sep 1998 04:16:48 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA19082 for ; Tue, 15 Sep 1998 04:16: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 EAA04725 for ; Tue, 15 Sep 1998 04:16:36 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by earth.sun.com (8.9.1/8.9.1) with SMTP id EAA07411 for ; Tue, 15 Sep 1998 04:16:35 -0700 (PDT) Received: (qmail 21111 invoked by uid 502); 15 Sep 1998 11:15:07 -0000 Message-ID: <19980915111507.21110.qmail@mail.ocs.com.au> Received: (qmail 21100 invoked from network); 15 Sep 1998 11:15:03 -0000 Received: from router-6.ocs.com.au (HELO ocs4.ocs-net) (203.34.97.6) by mail.ocs.com.au with SMTP; 15 Sep 1998 11:15:03 -0000 From: Keith Owens To: pete@trumpet.com.au (Peter R. Tattam) cc: ipng@sunroof.eng.sun.com Subject: (IPng 6463) Re: Questions about PPP over Ipv6. In-reply-to: Your message of "Tue, 15 Sep 1998 20:35:58 +1100." <3d0d9a9$1f4@jimmy.trumpet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Sep 1998 21:16:09 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 15 Sep 1998 20:35:58 +1100, pete@trumpet.com.au (Peter R. Tattam) wrote: >Also, one other question... the token for PPP is 32 bits. It seems a little >small, and since it differs from the token size of 48 bits for ethernet, it >makes stateless address config somewhat inconsistent with what might be >advertised on a LAN. Can one assume that the other end of the PPP link will >be advertising routes with the correct size prefix for autoconfig? What >would be the defined method of allocating a PPP prefix from a site's prefix. >One obviously has to choose addresses that won't clash with existing ethernet >addresses. RFC 2373, end of section 2.4 says "The format prefixes 001 through 111, except for Multicast Addresses (1111 1111), are all required to have to have 64-bit interface identifiers in EUI-64 format". Section 2.5.1 describes EUI-64, including the fact that where a global token is not available (covers serial links amongst others) that the "u" bit should be inverted. So "inet6 addr: 3ffe:900:6::6/64 Scope:Global" is quite valid for a tunnel or serial link. Just take your /64 prefix and append ::n where n is a small number to the end to create serial link end points, it will never conflict with ethernet. Keeping n unique within your site is your problem :). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 15 05:38:59 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA19230 for ipng-dist; Tue, 15 Sep 1998 05:29:16 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA19223 for ; Tue, 15 Sep 1998 05:29: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 FAA09512 for ; Tue, 15 Sep 1998 05:29:01 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA28138 for ; Tue, 15 Sep 1998 05:29:02 -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 IAA17716; Tue, 15 Sep 1998 08:28:28 -0400 (EDT) Message-Id: <199809151228.IAA17716@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 6464) Protocol Action: Transmission of IPv6 Packets over Token Ring Networks to Proposed Standard Date: Tue, 15 Sep 1998 08:28:28 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Transmission of IPv6 Packets over Token Ring Networks' as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary This document specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. It also specifies the method for forming IPv6 link-local addresses on Token Ring networks and the content of the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Redirect, Neighbor Solicitation and Neighbor Advertisement messages when these messages are transmitted on a Token Ring network. Working Group Summary The Working Group last call produced no issues with this document. Protocol Quality This document has been reviewed by Jeffrey Burgan and Thomas Narten of the IESG. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 15 06:06:03 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA19281 for ipng-dist; Tue, 15 Sep 1998 05:51:14 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA19270 for ; Tue, 15 Sep 1998 05:51: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 FAA11232 for ; Tue, 15 Sep 1998 05:51:00 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA05466 for ; Tue, 15 Sep 1998 05:51:02 -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 IAA18387; Tue, 15 Sep 1998 08:50:28 -0400 (EDT) Message-Id: <199809151250.IAA18387@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 6465) Protocol Action: IP Version 6 over PPP to Proposed Standard Date: Tue, 15 Sep 1998 08:50:27 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft IP Version 6 over PPP as a Proposed Standard. This document is a replacement for RFC2023. With this action, the IESG requests that RFC2023 be reclassified as Historic. This document is the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary This document defines the method for the transmission of IP Version 6 packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the use of IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links, and a method for negotiating the use of IPv6-specific compression protocols. Working Group Summary There was consensus in the WG for this document, and comments made during the Last Call by members of the PPP Working Group were incorporated. Protocol Quality This protocol has been reviewed for the IESG by Jeffrey Burgan and Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 15 07:26:44 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA19537 for ipng-dist; Tue, 15 Sep 1998 07:19:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA19530 for ; Tue, 15 Sep 1998 07:18: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 HAA24771 for ; Tue, 15 Sep 1998 07:18:52 -0700 Received: from neonet_server1.nexabit.com (neonetserver1.nexabit.com [209.6.34.254]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA14715 for ; Tue, 15 Sep 1998 07:18:52 -0700 (PDT) Received: by neonet_server1.nexabit.com with Internet Mail Service (5.0.1457.3) id ; Tue, 15 Sep 1998 10:18:50 -0400 Message-ID: <1180113EC576D011AADE0060975B88B32A115A@neonet_server1.nexabit.com> From: Dimitry Haskin To: pete@trumpet.com.au, ipng@sunroof.eng.sun.com Subject: (IPng 6466) RE: Questions about PPP over Ipv6. Date: Tue, 15 Sep 1998 10:18:48 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, Please use ftp://ftp.isi.edu/internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-06.txt as the reference for your work. This draft is about to be published as a Proposed Standard and replaces RFC-2023. The draft addresses the issues outlined in your message. Header compression is specified in ftp://ftp.isi.edu/internet-drafts/draft-engan-ip-compress-02.txt which is also approved to be published as a PS. BTW, the list of all latest IPv6 specifications can be conveniently found at http://playground.sun.com/ipng/specs/specifications.html. Dimitry On Tuesday, September 15, 1998 5:36 AM, pete@trumpet.com.au [SMTP:pete@trumpet.com.au] wrote: > Some of you may know that I've just released a beta for Trumpet Winsock 4.1 > last week. > > I'd like to work on PPP but I can't figure out what the spec requires for > header compression. I see an internet draft for generic header compression > but I'm not sure if that's supposed to be the standard that everyone's > operating to. > > Can someone point me in the right direction? > > Also, one other question... the token for PPP is 32 bits. It seems a little > small, and since it differs from the token size of 48 bits for ethernet, it > makes stateless address config somewhat inconsistent with what might be > advertised on a LAN. Can one assume that the other end of the PPP link will > be advertising routes with the correct size prefix for autoconfig? What > would be the defined method of allocating a PPP prefix from a site's prefix. > > One obviously has to choose addresses that won't clash with existing ethernet > > addresses. > > It seems to me that stateless address config only works adequately if the > universe of known interfaces all share the same address size, or that if there > > are mixed address size, that a smaller addresses must be concatenated with an > > address prefix to pad it out to the largest address size with the prefix being > > chosen uniquely. This begs the question, is there a standard prefix for PPP > which prevents the PPP address from clashing with the known universe of > Ethernet addresses. (It would be rather expensive on ethernet addresses as it > > would require 256 ethernet manufacturer allocations.) > > I see in some of the internet drafts that addresses used for stateless config > > are padded out to 64 bits before being appended to the site prefix. Is this > designed to deal with the problem (I presume so)? If so, when is the practice > > likely to come into play and is there a transition mechanism for the current > practice of *only* accepting prefixes that make the total add up to 128 bits? > > Pardon my ignorance if these are standard newbie questions. > > Peter > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- ------------------------------------------------------------------------ ------------------------------------- Dimitry Haskin Nexabit Networks, Inc. http://www.nexabit.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 15 08:04:45 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA19876 for ipng-dist; Tue, 15 Sep 1998 07:53:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA19869 for ; Tue, 15 Sep 1998 07:53:44 -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 HAA00945 for ; Tue, 15 Sep 1998 07:53:42 -0700 Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA04179 for ; Tue, 15 Sep 1998 07:53:41 -0700 (PDT) Received: from lana-2.trumpet.com.au (lana-2.trumpet.com.au [203.5.119.82]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id AAA03419 for ; Wed, 16 Sep 1998 00:53:39 +1000 (EST) (envelope-from pete@trumpet.com.au) To: ipng@sunroof.eng.sun.com From: pete@trumpet.com.au (Peter R. Tattam) Subject: (IPng 6467) Re: Questions about PPP over Ipv6. Date: Wed, 16 Sep 1998 00:58:48 +1100 Message-ID: <3c0153t$1mf@lana-2.trumpet.com.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Some kind people have pointed me to more recent RFC's which address this issue. Can I get a definite answer on whether all interface ID's or tokens will always be 64 bits, and that one should only accept router advertisements /64 when forming statelessly configured addresses? Now to see how much work is involved in the compression protocol :) Also, has anyone done a rough rule of thumb as to what constitutes the minimalist implementation requirement for an Ipv6 Host? Would Trumpet Winsock pass if it does Fragmentation, Unreachable port and Hops exceeded, UDP/TCP, Raw sockets, Basic ND, Stateless Address Config. Everything else is silently ignored. The IPSec will have to be an optional extra as export regulations cause me problems here in Aus too, so I may only be able to export on a restricted basis. I've got a few aces up my sleeve on that one. Please let me know if there is anything glaring that I should implement. I'll have a fresh beta out tomorrow for those who have been trying out the current version. I've had around 200 downloads since last Thurs which is a good sign so far. Those who want to fetch the current beta, go to ftp://ftp.trumpet.com/winsock/beta-4.1/twsk41b1.exe and ftp://ftp.trumpet.com.au/winsock/beta-4.1/twsk41b1.exe Peter In article <1180113EC576D011AADE0060975B88B32A115A@neonet_server1.nexabit.com> Dimitry Haskin writes:>From: Dimitry Haskin >Peter, >Please use >ftp://ftp.isi.edu/internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-06.txt >as the reference for your work. >This draft is about to be published as a Proposed Standard and replaces >RFC-2023. The draft addresses the issues outlined in your message. >Header compression is specified in >ftp://ftp.isi.edu/internet-drafts/draft-engan-ip-compress-02.txt which >is also approved >to be published as a PS. >BTW, the list of all latest IPv6 specifications can be conveniently >found at http://playground.sun.com/ipng/specs/specifications.html. >Dimitry >On Tuesday, September 15, 1998 5:36 AM, pete@trumpet.com.au >[SMTP:pete@trumpet.com.au] wrote: >> Some of you may know that I've just released a beta for Trumpet >Winsock 4.1 >> last week. >> >> I'd like to work on PPP but I can't figure out what the spec requires >for >> header compression. I see an internet draft for generic header >compression >> but I'm not sure if that's supposed to be the standard that everyone's >> operating to. >> >> Can someone point me in the right direction? >> >> Also, one other question... the token for PPP is 32 bits. It seems a >little >> small, and since it differs from the token size of 48 bits for >ethernet, it >> makes stateless address config somewhat inconsistent with what might >be >> advertised on a LAN. Can one assume that the other end of the PPP >link will >> be advertising routes with the correct size prefix for autoconfig? >What >> would be the defined method of allocating a PPP prefix from a site's >prefix. >> >> One obviously has to choose addresses that won't clash with existing >ethernet >> >> addresses. >> >> It seems to me that stateless address config only works adequately if >the >> universe of known interfaces all share the same address size, or that >if there >> >> are mixed address size, that a smaller addresses must be concatenated >with an >> >> address prefix to pad it out to the largest address size with the >prefix being >> >> chosen uniquely. This begs the question, is there a standard prefix >for PPP >> which prevents the PPP address from clashing with the known universe >of >> Ethernet addresses. (It would be rather expensive on ethernet >addresses as it >> >> would require 256 ethernet manufacturer allocations.) >> >> I see in some of the internet drafts that addresses used for stateless >config >> >> are padded out to 64 bits before being appended to the site prefix. >Is this >> designed to deal with the problem (I presume so)? If so, when is the >practice >> >> likely to come into play and is there a transition mechanism for the >current >> practice of *only* accepting prefixes that make the total add up to >128 bits? >> >> Pardon my ignorance if these are standard newbie questions. >> >> Peter >> >> -------------------------------------------------------------------- >> IETF IPng Working Group Mailing List >> IPng Home Page: http://playground.sun.com/ipng >> FTP archive: ftp://playground.sun.com/pub/ipng >> Direct all administrative requests to majordomo@sunroof.eng.sun.com >> -------------------------------------------------------------------- >------------------------------------------------------------------------ >------------------------------------- >Dimitry Haskin >Nexabit Networks, Inc. http://www.nexabit.com >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 15 08:41:32 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA19988 for ipng-dist; Tue, 15 Sep 1998 08:30:49 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA19981 for ; Tue, 15 Sep 1998 08:30: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 IAA10621 for ; Tue, 15 Sep 1998 08:30:21 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id IAA27230 for ; Tue, 15 Sep 1998 08:30:21 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id KAA24291; Tue, 15 Sep 1998 10:30:15 -0500 Message-Id: <199809151530.KAA24291@gungnir.fnal.gov> To: Harald Tveit Alvestrand Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 6468) Re: Query: Performance analysis of AAAA vs A6 records? In-reply-to: Your message of Sun, 13 Sep 1998 22:55:47 +0200. <3.0.2.32.19980913225547.01712470@dokka.maxware.no> Date: Tue, 15 Sep 1998 10:30:15 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > How to get [A6] deployed is now an NGTRANS issue. I hope it settles onto one mailing list or another! :-/ > Questions for this community: I just submitted draft-ietf-ipngwg-dns-lookups-02.txt so I'll have a go at your questions. For background, draft-ietf-ipngwg-dns-lookups-01.txt should suffice, if you globally replace AAAA by A6. (There are more changes, but that's a first-order approximation.) I'm going to make up some additional terminology for the purpose of this discussion. o A no-prefix A6 record will be one which contains a complete IPv6 address and has prefix length = 0. o A chain of A6 records for a name "N" is a sequence which starts with one owned by N has subsequent records owned by the prefix name contained in the previous record. o A complete chain of A6 records is a chain which ends with records having prefix length = 0. > - When analyzing performance of the record types, what are the relative > number of DNS queries expected for a client looking up an AAAA record > and constructing an address from an A6 record chain? We can talk about worst case or typical case. The trouble is, the A6 system hasn't been built so any talk about typical case involves some handwaving about the deplayment. There are also several dimensions along which the case can be bad or good. One possibly-typical case: A stub resolver looks for the IPv6 address of www.example.com, sending its query to a recursive server which initially has nothing more useful than the root hints. With AAAA only, the recursive server does this work: Q1 to root server, which happens to be a COM server too. Gets back NS and glue for example.com. Q2 to a server for example.com, gets back desired AAAA records. With A6 only, the recursive server does this work: Q1 to root server, as above, gets back NS and glue for example.com. What is the glue? For each server nsN.example.com, the minimum glue is a chain of A6 records from nsN.example.com up to and including one whose prefix name is not in example.com. There's a new opportunity for shooting oneself in the foot here by having a later A6 in the chain point back into example.com. Similar opportunities for foot wounds in the DNS already exist, so we can accept this new one, or declare that glue consists of complete chains of A6 records. For reasons discussed below, I'll assume that glue is complete chains. So ... Q2 to a server for example.com. If that server has processed any queries before this one, it will have complete chains of A6 records to return and the necessary information can now be returned to the resolver. > - If the answer to the above depends strongly on the use of "additional > information" in DNS answer packets, what is the average size of DNS > responses expected when an A6 record is queried? It does depend on additional information, and the amount of such information depends on the number of levels of address delegation hierarchy there are. So here comes the handwaving. Let's suppose the site connects to a retail ISP-A, which connects to a wholesale ISP-C, which gets its space from a TLA-administering organization. That's four layers, counting the site's own. And let's further suppose that the site elects to break out subnets as a layer in the A6 structure and "indirects" all the subnets to make it as easy as possible to switch providers. (See the draft, previous or current, for details.) Then it takes all the following to form an IPv6 address 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 for ns1.example.com: $ORIGIN example.com. ns1 A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 SUBNET-1.IP6 A6 48 0:0:0:1:: IP6 IP6 A6 48 0::0 EXAMPLE-COM.IP6.ISP-A.NET. EXAMPLE-COM.IP6.ISP-A.NET. A6 40 0:0:0011:: A-NET.IP6.C.NET. A-NET.IP6.C.NET. A6 28 0:1:CA00:: C-NET.ALPHA-TLA.ORG. C-NET.ALPHA-TLA.ORG. A6 0 2345:00C0:: Totaling up the sizes and assuming standard compression only, the AAAA format uses Owner + fixed + RDATA = total 2 10 16 28 bytes for ns1's glue record. Additional singly-homed nameservers require another 28 bytes each. Specification of the above glue records in the A6 format uses Owner + fixed + RDATA = total 2 10 35 47 15 10 28 53 2 10 38 50 38 10 29 77 15 10 35 60 21 10 17 48 --- 335 Local compression (draft-ietf-dnsind-local-compression-02.txt) cuts the RDATA fields by 11+15+0+3+0+0 = 28 bytes, leaving 307 bytes. But this size should not be multiplied by the number of nameservers. An additional nameserver ns2.example.com, in a different subnet of the same prefix, needs two additional A6 records as glue, occupying (2+10+35)+(11+10+28) = 96 bytes with standard compression only, or (2+10+24)+(11+10+13) = 70 bytes with local compression. So it looks like this example, supposing just the two nameservers are returned by the top-level server, with 12 bytes of DNS header, 21 bytes of question, 0 bytes of answer, 2x(2+10+6) of authority, and 335+96 bytes of additional data (total = 500 bytes) will seriously push the envelope of the 512 byte limit for today's UDP DNS replies, but it should easily fit within the 1280 byte minimum IPv6 MTU using one of the proposals for larger DNS replies. > - Do the answers to the two above questions change when security > implications are considered (cache poisoning, for instance)? I don't see how. > The context for which I'm asking these questions is to look at whether > it's an appropriate transition/coexistence strategy to ask a DNS server > to synthesize AAAA records when needed, removing the need to transition > clients, rather than asking clients to switch to looking for A6 records. What I wrote in the draft you haven't seen yet was A server providing recursive service MAY be configurable to synthesize AAAA records from A6 records in response to clients' AAAA queries. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 15 08:57:52 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA20052 for ipng-dist; Tue, 15 Sep 1998 08:46:48 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA20045 for ; Tue, 15 Sep 1998 08:46: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 IAA15499 for ; Tue, 15 Sep 1998 08:46:35 -0700 Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA08019 for ; Tue, 15 Sep 1998 08:46:34 -0700 (PDT) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id KAA12344; Tue, 15 Sep 1998 10:46:32 -0500 (CDT) Date: Tue, 15 Sep 1998 10:46:32 -0500 (CDT) From: David Borman Message-Id: <199809151546.KAA12344@frantic.bsdi.com> To: Volsinians@aol.com Subject: (IPng 6469) Re: Host Fragmentation Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Volsinians@aol.com > Date: Mon, 14 Sep 1998 22:08:05 EDT > Subject: Re: (IPng 6448) Re: Host Fragmentation > ... > Here are the most important data of the announcement. > > Microsoft officials said they achieved 920Mbps throughput on a server > using the AceNIC 180, a Gigabit Ethernet network interface card from > Alteon, which also supplied the proprietary jumbo-frame technology. Ok, does anyone know how big were these jumbo-frames were? 4K? > ... > The tests were conducted using a single-processor Intel 400-MHz > Xeon-based server and four 333-MHz Pentium II clients. An Alteon > Gigabit Ethernet server switch connected the servers and clients. This says to me that the jumbo-frames were going from the server to the clients without fragmentation. That's great. Yes, you can get better performance with bigger packets. I don't think anyone argues with that, and this test supports it. I've shown the same thing many times over the years when I worked at Cray Research. Now, as for the "IPv6 won't let me fragment" complaint, I'll offer an alternative view (that I don't necessarily agree with...). Since the high-speed fragmenting router sits close to the server, draw a circle around both of them and call that your "host". Then, rather than doing IP level fragmentation, do TCP level splitting of the packet. It's easy to take one large TCP packet and split it down into multiple TCP packets. The hard part is that you'd have to recalculate the TCP checksum over each piece. I'm not really interested in discussing this alternate solution, because I don't especially like it myself; it's too easy to argue about what is wrong with it. I'm just presenting it as a different way of looking at the issue. It is actually better than the IP level fragmentation arguement, because 1) lost segments don't invalidate the whole original packet and 2) the client doesn't have the added latency of waiting for all the IP fragments to show up before passing anything up the stack to TCP. -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 15 10:10:22 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA20256 for ipng-dist; Tue, 15 Sep 1998 09:58:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA20249 for ; Tue, 15 Sep 1998 09:58: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 JAA09446 for ; Tue, 15 Sep 1998 09:58:07 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id JAA25717 for ; Tue, 15 Sep 1998 09:58:05 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id LAA24751; Tue, 15 Sep 1998 11:57:47 -0500 Message-Id: <199809151657.LAA24751@gungnir.fnal.gov> To: pete@trumpet.com.au (Peter R. Tattam) Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 6470) Re: Questions about PPP over Ipv6. In-reply-to: Your message of Tue, 15 Sep 1998 20:35:58 +1100. <3d0d9a9$1f4@jimmy.trumpet.com.au> Date: Tue, 15 Sep 1998 11:57:47 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Also, one other question... the token for PPP is 32 bits. It seems a little > small, and since it differs from the token size of 48 bits for ethernet, it Doh! I was afraid this would happen. The new documents for IPv6-over-ethernet and -fddi have been sitting in the RFC editor's queue so long that some implementors don't know they're there. (In fact, the drafts have technically expired, but perhaps the i-d editor has them on life support since the IESG approved them.) The interface identifier is now generally 64 bits long. For 802 media, it's derived from the MAC address using the IEEE-specified procedure of inserting FFFE (hex) in the middle. > chosen uniquely. This begs the question, is there a standard prefix for PPP > which prevents the PPP address from clashing with the known universe of > Ethernet addresses. See draft-ietf-ipngwg-ipv6-over-ppp-06.txt, recently apporvied by the IESG to supersede 2023. ______________________________________________________________________________ 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 Tue Sep 15 10:34:24 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA20340 for ipng-dist; Tue, 15 Sep 1998 10:22:55 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA20333 for ; Tue, 15 Sep 1998 10:22:38 -0700 (PDT) From: Volsinians@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 KAA18676 for ; Tue, 15 Sep 1998 10:22:35 -0700 Received: from imo18.mx.aol.com (imo18.mx.aol.com [198.81.17.8]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA11898 for ; Tue, 15 Sep 1998 10:22:32 -0700 (PDT) Received: from Volsinians@aol.com by imo18.mx.aol.com (IMOv16.1) id 1JSYa04367; Tue, 15 Sep 1998 13:21:45 -0400 (EDT) Message-ID: <2371264.35fea229@aol.com> Date: Tue, 15 Sep 1998 13:21:45 EDT To: dab@BSDI.COM Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6471) Re: Host Fragmentation 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 9/15/98 11:47:03 AM Eastern Daylight Time, dab@BSDI.COM writes: > > From: Volsinians@aol.com > > Date: Mon, 14 Sep 1998 22:08:05 EDT > > Subject: Re: (IPng 6448) Re: Host Fragmentation > > ... > > Here are the most important data of the announcement. > > Microsoft officials said they achieved 920Mbps throughput on a server > > using the AceNIC 180, a Gigabit Ethernet network interface card from > > Alteon, which also supplied the proprietary jumbo-frame technology. > Ok, does anyone know how big were these jumbo-frames were? 4K? > > ... > > The tests were conducted using a single-processor Intel 400-MHz > > Xeon-based server and four 333-MHz Pentium II clients. An Alteon > > Gigabit Ethernet server switch connected the servers and clients. > This says to me that the jumbo-frames were going from the server to the > clients without fragmentation. That's great. Not true. The following paragraph has been left out. The tests were conducted using a single-processor Intel 400-MHz Xeon-based server and four 333-MHz Pentium II clients. An Alteon Gigabit Ethernet server switch connected the servers and clients. The Alteon Gigabit Ethernet server switch is a fragmenting gigabit/10/100Mbps switch or extruder, but it could just as well have been a fragmenting gigabit 10/100Mbps router. The point is that server performance goes up if the server does not do the fragmentation but instead the fragmentation is off-loaded to an intermediate packet switch. > Yes, you can get better performance with bigger packets. I don't think > anyone argues with that, and this test supports it. I've shown the same > thing many times over the years when I worked at Cray Research. The only way to use jumbo packets in this situation is to split them up at the intermediate system. > Now, as for the "IPv6 won't let me fragment" complaint, I'll offer an > alternative view (that I don't necessarily agree with...). Since the > high-speed fragmenting router sits close to the server, draw a circle > around both of them and call that your "host". Then, rather than doing > IP level fragmentation, do TCP level splitting of the packet. It's easy > to take one large TCP packet and split it down into multiple TCP packets. > The hard part is that you'd have to recalculate the TCP checksum over > each piece. It is certainly an interesting thought. The procedure would also have to be applied to UDP and whatever other protocols run on top of IP, for which TCP style segmentation might not make sense (I could certainly envisage for some applications sending video frames in giant UDP packets, that were never acknowledged and that could not be reasonably segmented). I think the main drawbacks would be 1) the greater level of processing power a) which might be required at the intermediate system to process a given amount of traffic and b) which could translate into greater cost or decrease the amount of packets that could be processed per second or 2) inapplicability to the customer application. TCP segmentation might be an interesting feature to add to an intermediate system, but it has some basic limitations. And the possibility that intermediate system TCP segmentation might provide a possibly more expensive alternative to intermediate system fragmentation hardly provides a justification for a standards body arbitrarily to forbid network fragmentation of IP packets when that body permits host fragmentation of the IP packet 1) which the receiving station could not possibly distinguish from forbidden network fragmentation and 2) which suffers from precisely the same problems from which network fragmentation suffers. > I'm not really interested in discussing this alternate solution, because > I don't especially like it myself; it's too easy to argue about what is > wrong with it. I'm just presenting it as a different way of looking at > the issue. It is actually better than the IP level fragmentation > arguement, because 1) lost segments don't invalidate the whole original > packet and 2) the client doesn't have the added latency of waiting for > all the IP fragments to show up before passing anything up the stack to > TCP. 1) is a reasonable point. 2) is only a concern in a lossy environment which is bad for TCP based applications because even if TCP provides selective acknowledgement and out of order segment processing, most TCP applications seem to require sequential byte streams and could not do much with the processed data until the missing segments turn up. 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 Sep 15 11:55:14 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA20520 for ipng-dist; Tue, 15 Sep 1998 11:46:00 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA20513 for ; Tue, 15 Sep 1998 11:45: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 LAA17583 for ; Tue, 15 Sep 1998 11:45:30 -0700 Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by earth.sun.com (8.9.1/8.9.1) with SMTP id LAA08175 for ; Tue, 15 Sep 1998 11:45:30 -0700 (PDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id OAA05140; Tue, 15 Sep 1998 14:45:28 -0400 To: Volsinians@aol.com cc: ipng@sunroof.eng.sun.com Subject: (IPng 6472) Re: Host Fragmentation References: <2371264.35fea229@aol.com> From: James Carlson Date: 15 Sep 1998 14:45:28 -0400 In-Reply-To: Volsinians@aol.com's message of 15 Sep 1998 13:39:59 -0400 Message-ID: <86yarlb4fr.fsf@helios.nis.ironbridgenetworks.com> Lines: 32 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Volsinians@aol.com writes: > Not true. The following paragraph has been left out. > > The tests were conducted using a single-processor Intel 400-MHz > Xeon-based server and four 333-MHz Pentium II clients. An Alteon > Gigabit Ethernet server switch connected the servers and clients. > > The Alteon Gigabit Ethernet server switch is a fragmenting > gigabit/10/100Mbps switch or extruder, but it could > just as well have been a fragmenting gigabit 10/100Mbps > router. The point is that server performance goes > up if the server does not do the fragmentation but > instead the fragmentation is off-loaded to an intermediate > packet switch. Read the damned datasheet, please. The Alteon Gb Ethernet switch supports jumbograms on BOTH the Gb Ethernet ports AND the 100Mb ports. Without question, that's what this test was using. That's why they mentioned the types of cards in the clients. http://www.alteon.com/pdf/ace110.pdf?124,174 That I'm even replying shows how much the tie I'm wearing today has severely constricted the blood flow above the neck. *Plonk* Must remember to add this thread to the kill file. -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8190 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 15 12:18:35 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA20567 for ipng-dist; Tue, 15 Sep 1998 12:03:24 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA20560 for ; Tue, 15 Sep 1998 12:03:13 -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 MAA22685 for ; Tue, 15 Sep 1998 12:03:08 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id MAA19555 for ; Tue, 15 Sep 1998 12:03:09 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id OAA25224; Tue, 15 Sep 1998 14:03:02 -0500 Message-Id: <199809151903.OAA25224@gungnir.fnal.gov> To: pete@trumpet.com.au (Peter R. Tattam) Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 6473) Re: Questions about PPP over Ipv6. In-reply-to: Your message of Wed, 16 Sep 1998 00:58:48 +1100. <3c0153t$1mf@lana-2.trumpet.com.au> Date: Tue, 15 Sep 1998 14:03:02 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Can I get a definite answer on whether all interface ID's or tokens will > always be 64 bits, and that one should only accept router advertisements /64 > when forming statelessly configured addresses? For each medium "foo" there is/will be a "v6-over-foo" document which specifies the interface identifier. To date I think they are all 64 bits now, except for v6-over-v4 which is phrased as "the 32-bit IPv4 address ... padded ...to a total of 64 bits." > Would Trumpet Winsock pass if it does Fragmentation, Unreachable port > and Hops exceeded, UDP/TCP, Raw sockets, Basic ND, Stateless Address Config. > Everything else is silently ignored. says A full implementation of IPv6 includes implementation of the following extension headers: Hop-by-Hop Options Routing (Type 0) Fragment Destination Options Authentication Encapsulating Security Payload The first four are specified in this document; the last two are specified in [RFC-1826] and [RFC-1827], respectively. > The IPSec will have to be an optional extra as export regulations > cause me problems here in Aus too Maybe someone will come up with a succinct phrase for "this implementation would be a complete one if it weren't for certain local laws." ______________________________________________________________________________ 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 Tue Sep 15 23:00:12 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id WAA21252 for ipng-dist; Tue, 15 Sep 1998 22:57:14 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id WAA21245 for ; Tue, 15 Sep 1998 22:57:02 -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 WAA17603 for ; Tue, 15 Sep 1998 22:57:00 -0700 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id WAA20235 for ; Tue, 15 Sep 1998 22:57:02 -0700 (PDT) Received: by mail4.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Tue, 15 Sep 1998 22:57:00 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81292@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: (IPng 6474) nit-picky error conditions Date: Tue, 15 Sep 1998 22:57:00 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I want to check my understanding of how some exceptional conditions should be handled by receivers. Perhaps there is some implementation leeway in these situations, in which case I'm interested in hearing what other implementations do. In the ICMP spec section 3.4, I read "If an IPv6 node processing a packet finds a problem with a field in the IPv6 header or extension headers such that it cannot complete processing the packet, it MUST discard the packet and SHOULD send an ICMPv6 Parameter Problem message to the packet's source, indicating the type and location of the problem." So my general rule should be to send an icmp error unless some spec specifically says not to, right? For some cases, like bad version number in the header, or link-layer framing says the packet is not big enough to contain a full IPv6 header, it would seem prudent to drop the packet without an attempt to send an ICMP error? If I receive a packet with a hop limit of zero, should I drop the packet silently or send an ICMP error hop-limit exceeded? The IPv6 spec section 3 says "The packet is discarded if Hop Limit is decremented to zero" which doesn't really address the question of receiving with the hop limit already zero. The ICMPv6 spec section 3.3 says "If a router receives a packet with a Hop Limit of zero, or a router decrements a packet's Hop Limit to zero, it MUST discard the packet and send an ICMPv6 Time Exceeded message with Code 0 to the source fo the packet." So this doesn't say what a host should do. By implication one might assume that a host should not check the hop limit at all, but that doesn't seem right. If I find the payload length (either in the header or from a jumbo payload length option) is bigger than the link-layer framing's length would indicate, I should send an parameter problem code 0 pointing at the payload length? If I'm a host and I receive a packet which is not sent to one of my addresses, should I silently ignore it or send an ICMP error of some type? The general rule says to send an error, but that seems wrong in this situation. If I find that there's not room left in the packet for an extension header (payload length is too small/extension header is too big), then I should send parameter problem code 0 pointing at the payload length? A clue here is the jumbo payload length option spec, which has an example like this "according to the IPv6 specification", although I can't find a discussion of the situation in the IPv6 specification. By analogy, if I find that there's not room left in a hop-by-hop/destination option for an option (header is too small/option is too big), then I should send parameter problem code 0 pointing at the extension header length byte? If I find an option in the wrong kind of extension header (for example, if I find a router-alert option in a destination options header), should I a) pretend I do not recognize the option and use the high bits of the option type to govern my behavior, or b) send parameter problem code 0 pointing at the option type byte? If I find an option twice, for example two jumbo payload length options, should I use the later value? Or is it an error? The jumbo payload length spec doesn't mention this case. But the router alert spec does, saying it's an error ("MUST only be one option of this type, regardless of value, per Hop-by-Hop header"), but doesn't say how receivers should handle the error. Code 0 pointing at the option type byte of the second option? If I receive an option that I recognize, but its size is wrong, I should send parameter problem code 0 pointing at the option length byte? If I receive an option that I recognize and its alignment is wrong, should I process the option anyway? Am I allowed to send an ICMP error? Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 16 00:37:09 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id AAA21350 for ipng-dist; Wed, 16 Sep 1998 00:33:44 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id AAA21343 for ; Wed, 16 Sep 1998 00:33: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 AAA27478 for ; Wed, 16 Sep 1998 00:33:34 -0700 Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id AAA20504 for ; Wed, 16 Sep 1998 00:33:34 -0700 (PDT) Received: from alden ([10.128.1.82]) by dokka.maxware.no (8.8.5/8.8.5) with SMTP id JAA10815; Wed, 16 Sep 1998 09:33:27 +0200 Message-Id: <3.0.2.32.19980916084217.0253ce70@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 16 Sep 1998 08:42:17 +0200 To: "Matt Crawford" From: Harald Tveit Alvestrand Subject: (IPng 6475) Re: Query: Performance analysis of AAAA vs A6 records? Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199809151530.KAA24291@gungnir.fnal.gov> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:30 15.09.98 -0500, Matt Crawford wrote: .... >> - Do the answers to the two above questions change when security >> implications are considered (cache poisoning, for instance)? > >I don't see how. > If badguy.com knows that goodguy.com has 123.ip6.isp-a.net in his A6-record chain, AND that client resolvers reuse "additional" information from unrelated queries, badguy.com could try to install a fake A6 record for 123.ip6.isp-a.net into a client resolver, effectively stealing traffic by modifying the AAAA records. If the answer is "DNSSEC", we then have much more data that needs to go across as "additional", alternatively more queries to fetch those data, and the UDP-across-IPv4 DNS is in trouble. I believe the internic.net redirect hack was solved by not placing so much faith in additional info, but that might negatively impact the ability of the DNS servers to cache, so might influence your scenarios where you assume that the example.com DNS server has complete caches of A6 chains to hand out; I don't know enough about DNS to be sure. >> The context for which I'm asking these questions is to look at whether >> it's an appropriate transition/coexistence strategy to ask a DNS server >> to synthesize AAAA records when needed, removing the need to transition >> clients, rather than asking clients to switch to looking for A6 records. > >What I wrote in the draft you haven't seen yet was > > A server providing recursive service MAY be configurable to > synthesize AAAA records from A6 records in response to clients' AAAA > queries. > But if clients are to be written to depend on this, it has to be a MUST. Over to NGTrans....what's our desired end state? Thanks again! Harald -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.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 Wed Sep 16 04:42:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA21443 for ipng-dist; Wed, 16 Sep 1998 04:36:30 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA21436 for ; Wed, 16 Sep 1998 04:36:22 -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 EAA18014 for ; Wed, 16 Sep 1998 04:36:20 -0700 Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA08495 for ; Wed, 16 Sep 1998 04:36:19 -0700 (PDT) Received: from lana-1.trumpet.com.au (lana-1.trumpet.com.au [203.5.119.81]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id VAA10994 for ; Wed, 16 Sep 1998 21:36:17 +1000 (EST) (envelope-from pete@trumpet.com.au) To: ipng@sunroof.eng.sun.com From: pete@trumpet.com.au (Peter R. Tattam) Subject: (IPng 6476) More questions about PPP over Ipv6. Issue of backward compatibility. Date: Wed, 16 Sep 1998 21:34:22 +1100 Message-ID: <3c2ohch$1mq@lana-1.trumpet.com.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've got PPP coded up now and I have discovered a couple of issues that need addressing. Since I've been trying to make my stack as user friendly as possible, my PPP interface is designed to handle both IPv4 and IPv6. This would seem to be perfectly reasonable. However, while negotiation takes place, after LCP and authentication is done, a decision has to be made when starting up IPCP and IPV6CP. There are three possible outcomes. 1) start IPCP only. (regular IP4 stack) 2) start IPV6CP only. (Ipv6 stack only) 3) start both. I have opted for both. According to the PPP spec, if the other end doesn't know about IPv6, PROTREJ packets should be sent which should close the IPv6CP, which in turn should pass up the layers. Is this a credible thing to expect? I would have thought so. Anyway... I decided to test this with one of our Cisco AS5200's used for dialup. Not sure which one I got, but two are running IOS 11.3(4) and one is running IOS 11.3(2). My results were a little unexpected though. When I sent the IPV6CP packet through, it seems that the as5200 is interpreting it as an IPCP packet and naked the INTERFACE_ID option, and then the connection dropped (not sure which end dropped it). Also the received NAK came back as an IPCP packet and not as an IPV6CP packet. I'm fairly sure of my results, but could stand corrected. Has anyone else seen this kind of behaviour before? Is this a real bug in the Cisco IOS or have I misunderstood something. With this kind of incompatibility, it could be a *major* headache for a product like ours to autoconfigure itself. The only workaround I can see is for the user to explicitly select if they want to use an Ipv4 or Ipv6 PPP connection, and that will have problems in itself considering the huge body of inexperienced people on the Internet. Puzzled Peter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 16 05:10:53 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA21473 for ipng-dist; Wed, 16 Sep 1998 05:07:36 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA21466 for ; Wed, 16 Sep 1998 05:07:27 -0700 (PDT) From: Volsinians@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 FAA20785 for ; Wed, 16 Sep 1998 05:07:25 -0700 Received: from imo20.mx.aol.com (imo20.mx.aol.com [198.81.17.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA19074 for ; Wed, 16 Sep 1998 05:07:26 -0700 (PDT) Received: from Volsinians@aol.com by imo20.mx.aol.com (IMOv16.1) id 7FLHa08189; Wed, 16 Sep 1998 08:06:49 -0400 (EDT) Message-ID: Date: Wed, 16 Sep 1998 08:06:49 EDT To: carlson@ironbridgenetworks.com Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6477) Re: Host Fragmentation 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 9/15/98 3:07:45 PM Eastern Daylight Time, carlson@ironbridgenetworks.com writes: > Volsinians@aol.com writes: > > Not true. The following paragraph has been left out. > > The tests were conducted using a single-processor Intel 400-MHz > > Xeon-based server and four 333-MHz Pentium II clients. An Alteon > > Gigabit Ethernet server switch connected the servers and clients. > > The Alteon Gigabit Ethernet server switch is a fragmenting > > gigabit/10/100Mbps switch or extruder, but it could > > just as well have been a fragmenting gigabit 10/100Mbps > > router. The point is that server performance goes > > up if the server does not do the fragmentation but > > instead the fragmentation is off-loaded to an intermediate > > packet switch. > Read the damned datasheet, please. The Alteon Gb Ethernet switch > supports jumbograms on BOTH the Gb Ethernet ports AND the 100Mb ports. > Without question, that's what this test was using. That's why they > mentioned the types of cards in the clients. > http://www.alteon.com/pdf/ace110.pdf?124,174 So? The device apparently uses the same ASIC on every port, and I suppose if the Alteon Gigabit adapter is used in 100Mbps fallback mode on a 10/100 Mbps port, it makes sense to transceive jumbograms on the 100Mbps medium. But such is not the situation here. The article only mentions the use of a single Gbps jumbogram capable adapter card only in the server. Microsoft officials said they achieved 920Mbps throughput on a server using the AceNIC 180, a Gigabit Ethernet network interface card from Alteon, which also supplied the proprietary jumbo-frame technology. I just checked the 82558/82557 and 21140 manuals. The common 10/100Mbps adapters do not support jumbogram. While I do not have a 21143 manual here, it is unlikely that this part supports jumbograms. I have to assume that the tests were run as we run similar tests and as described in Alteon white papers: the clients were using some common 100 Mbps adapter cards, which do not support jumbograms. Otherwise one would think that that the article would have stated something like the following. Microsoft officials said they achieved 920Mbps throughput on a server using the AceNIC 180, a Gigabit Ethernet network interface card from Alteon, which also supplied the proprietary jumbo-frame technology when that server communicated with four clients all of which used the same AceNIC 180 adapter in jumbo-frame mode. In point of fact all throughout the Alteon white papers and documentation the standard described configuration is *) a server on one of the gigabit ports, *) perhaps another server on the other gigabit port and *)10/100 Mbps clients (using standard 10/100 Mbps non-jumbogram supporting adapters -- Alteon does not sell a jumbogram capable 10/100 Mbps adapter card for clients) attached to the 10/100 Mbps ports. The performance test that Alteon sees using WindowsNT servers is about the performance that we see with Alteon cards in Compaq Alpha Servers that run Unix. Clients with 32bit busses and 100 Mbps ethernet adapter cards support a throughput of approximately 240Mbps. We find that 64 bit buss clients with 64 bit adapter cards can support approximately 450 Mbps. When a 64 bit server is used with jumbogram technology where the Alteon switch performs the dreaded network fragmentation, the server can support a throughput over 900 Mbps, essentially doubling the number of clients that can be supported. Thus the use of jumbograms at the server with network fragmentation doubles the number of clients that the server can support. The designers of IPv6 have for no obvious reason chosen to ban configurations that can provide tremendous performance wins. The much touted PMTU procedures would completely thwart the benefits that the Alteon technology provides. > That I'm even replying shows how much the tie I'm wearing today has > severely constricted the blood flow above the neck. And has apparently affected Carlson's ability to read as well. I have to admit that Alteon is perhaps being a little bit obscure with regard to their exact procedures with all this discussion in the white papers of VLANs, intranets and P802.1q. But in the face of the irrationality of the anti-network fragmentation point of view that we see in this forum, I am hardly surprised. > *Plonk* Must remember to add this thread to the kill file. Understandable given the apparent reading disability. BTW, I obtained a copy of Mogul's fragmentation paper. Briefly skimming, practically every point refers to technological problems that existed 10 years ago and that are essentially irrelevant today. If this sort of analysis provides the foundation of IPv6, IPv6 should be described as "The Protocol of Tomorrow, Designed to Address the Problems of Yesteryear." I will try to provide a critique of the paper later today or tomorrow. 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 Sep 16 06:45:33 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA21539 for ipng-dist; Wed, 16 Sep 1998 06:41:31 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA21532 for ; Wed, 16 Sep 1998 06:41: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 GAA02591 for ; Wed, 16 Sep 1998 06:41:18 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id GAA01218 for ; Wed, 16 Sep 1998 06:41:19 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id IAA29134; Wed, 16 Sep 1998 08:41:16 -0500 Message-Id: <199809161341.IAA29134@gungnir.fnal.gov> To: Richard Draves Cc: "'IPng List'" From: "Matt Crawford" Subject: (IPng 6478) Re: nit-picky error conditions In-reply-to: Your message of Tue, 15 Sep 1998 22:57:00 PDT. <4D0A23B3F74DD111ACCD00805F31D8100AF81292@RED-MSG-50> Date: Wed, 16 Sep 1998 08:41:16 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > By implication one might assume that a host should not check the > hop limit at all, but that doesn't seem right. Except for ND packets, why should the host ever check the hop limit? The network did the work to get a packet to the host, why waste 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 Sep 16 07:58:26 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA21617 for ipng-dist; Wed, 16 Sep 1998 07:55:06 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA21610 for ; Wed, 16 Sep 1998 07:54:55 -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 HAA15608 for ; Wed, 16 Sep 1998 07:54:53 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA17301 for ; Wed, 16 Sep 1998 07:54:53 -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 KAA21780; Wed, 16 Sep 1998 10:54:48 -0400 (EDT) Message-Id: <199809161454.KAA21780@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6481) I-D ACTION:draft-ietf-ipngwg-dns-lookups-02.txt Date: Wed, 16 Sep 1998 10:54:48 -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 : DNS Extensions to Support IP Version 6 Author(s) : M. Crawford, C. Huitema, S. Thomson Filename : draft-ietf-ipngwg-dns-lookups-02.txt Pages : 15 Date : 15-Sep-98 This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address in a manner which expedites network renumbering, and updated definitions of existing query types that return Internet addresses as part of additional section processing. For lookups keyed on IPv6 addresses (often called reverse lookups), this document defines a new domain to hold the top-level delegation information and a zone structure which allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events. 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-dns-lookups-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-lookups-02.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-dns-lookups-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980915102108.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-dns-lookups-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-dns-lookups-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980915102108.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 16 07:58:49 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA21608 for ipng-dist; Wed, 16 Sep 1998 07:53:49 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA21601 for ; Wed, 16 Sep 1998 07:53:38 -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 HAA15379 for ; Wed, 16 Sep 1998 07:53:37 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA16595 for ; Wed, 16 Sep 1998 07:53:36 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA29406; Wed, 16 Sep 1998 09:53:31 -0500 Message-Id: <199809161453.JAA29406@gungnir.fnal.gov> To: Harald Tveit Alvestrand Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 6480) Re: Query: Performance analysis of AAAA vs A6 records? In-reply-to: Your message of Wed, 16 Sep 1998 08:42:17 +0200. <3.0.2.32.19980916084217.0253ce70@dokka.maxware.no> Date: Wed, 16 Sep 1998 09:53:31 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> - Do the answers to the two above questions change when security > >> implications are considered (cache poisoning, for instance)? > > > >I don't see how. > > ..., badguy.com could try to install a fake A6 record for ... Yes, that seems to me to be an update to a problem that already exists, but I don't see how it affects "the answers to the two above questions," which were "how many queries?" and "how big are the answers?" > ... 123.ip6.isp-a.net into a client resolver, I think you said "client resolver" where you should have said "intermediate server", but that doesn't make the issue go away. It does, however, admit the solution of a hard-working DNSSEC-aware intermediate server using TSIG with its clients. > I believe the internic.net redirect hack was solved by not placing so > much faith in additional info, but that might negatively impact the > ability of the DNS servers to cache, so might influence your scenarios > where you assume that the example.com DNS server has complete caches > of A6 chains to hand out; I don't know enough about DNS to be sure. Is there a real DNS expert paying attention? If not, I'll try answering that if example.com's DNS server has those additional A6 records, it should have gotten them by specifically asking for them, not as additional data. But if somebody's spoofing non-secure DNS at all, then I don't think you can say that answers are trustworthy while additional info is not. > But if clients are to be written to depend on this, it has to be a MUST. While if clients are written to work either way, the site administrator gets to choose. > Over to NGTrans....what's our desired end state? Does this topic need its own ad-hoc mailing list, with ipng, ngtrans and dns people recruited to work on it? Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 16 08:45:01 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA21699 for ipng-dist; Wed, 16 Sep 1998 08:40:04 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA21692 for ; Wed, 16 Sep 1998 08:39:55 -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 IAA27026 for ; Wed, 16 Sep 1998 08:39:54 -0700 Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA20701 for ; Wed, 16 Sep 1998 08:39:52 -0700 (PDT) Received: from jimmy.trumpet.com.au (jimmy.trumpet.com.au [203.5.119.2]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id BAA22493; Thu, 17 Sep 1998 01:39:47 +1000 (EST) (envelope-from pete@trumpet.com.au) To: ipng@sunroof.eng.sun.com, 6bone@isi.edu From: pete@trumpet.com.au (Peter R. Tattam) Subject: (IPng 6482) Trumpet Winsock 4.1 IPv6 (Beta 2) available. Date: Thu, 17 Sep 1998 01:39:21 +1100 Message-ID: <3cop9et$1f8@jimmy.trumpet.com.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is the next installment. Added in this release - Stateless Address Autoconfig. - Default Router discovery and auto address prefixing. - Basic IPv6 over PPP. (no compression yet) Fixed in this release - Parsing and display of IPv4 compatible addresses. Location: ftp://ftp.trumpet.com/winsock/beta-4.1/twsk41b2.exe USA or ftp://ftp.trumpet.com.au/winsock/beta-4.1/twsk41b2.exe AUS Enjoy!!! Peter -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. Phone: +61-3-6245-0220 Fax: +61-3-6245-0210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 16 10:04:39 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA21849 for ipng-dist; Wed, 16 Sep 1998 09:57:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA21838 for ; Wed, 16 Sep 1998 09:57: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 JAA25308 for ; Wed, 16 Sep 1998 09:57:29 -0700 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA17976 for ; Wed, 16 Sep 1998 09:57:24 -0700 (PDT) Received: by INET-IMC-01 with Internet Mail Service (5.5.2232.9) id ; Wed, 16 Sep 1998 09:57:22 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81297@RED-MSG-50> From: Richard Draves To: "'Matt Crawford'" Cc: "'IPng List'" Subject: (IPng 6483) RE: nit-picky error conditions Date: Wed, 16 Sep 1998 09:57:13 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > By implication one might assume that a host should not check the > > hop limit at all, but that doesn't seem right. > > Except for ND packets, why should the host ever check the hop limit? > The network did the work to get a packet to the host, why waste it? This is a good argument. Someone else mentioned the v4 host/router requirements specs, and they are pretty clear about this situation in v4: you should only check the TTL if you are forwarding a packet. This means that the text in the ICMPv6 spec "If a router receives a packet with a Hop Limit of zero, ..., it MUST discard the packet and send an ICMPv6 Time Exceeded" should be revised. The router should only be checking the Hop Limit and sending ICMP errors if it is forwarding, not when it is receiving packets sent to its own addresses. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 16 10:06:14 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA21877 for ipng-dist; Wed, 16 Sep 1998 10:02:32 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id KAA21870 for ; Wed, 16 Sep 1998 10:02:23 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA07038 for ; Wed, 16 Sep 1998 10:02:22 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id KAA12306 for ipng@sunroof.eng.sun.com; Wed, 16 Sep 1998 10:01:07 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA21584 for ; Wed, 16 Sep 1998 07:42:29 -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 HAA13243 for ; Wed, 16 Sep 1998 07:42:28 -0700 Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA09979 for ; Wed, 16 Sep 1998 07:42:26 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id AAA20726 for ; Thu, 17 Sep 1998 00:42:25 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Thu, 17 Sep 1998 00:42:25 +1000 (EST) From: Peter Tattam To: ipng@sunroof.eng.sun.com Subject: (IPng 6484) Re: More questions about PPP over Ipv6. Issue of backward compatibility. In-Reply-To: <3c2ohch$1mq@lana-1.trumpet.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here's a trace of the problem. PPP[C021] SND CONFREQ ID=01 LEN=24 MRU(05DC) ACCM(00000000) MAGIC(004CAF76) PFC ACFC PPP[C021] state = reqsent received protocol = C021 PPP[C021] RCV CONFREQ ID=91 LEN=24 ACCM(000A0000) AP(C023) MAGIC(593EFA14) PFC ACFC PPP[C021] SND CONFACK ID=91 LEN=24 ACCM(000A0000) AP(C023) MAGIC(593EFA14) PFC ACFC PPP[C021] state = acksent PPP[C021] SND CONFREQ ID=02 LEN=24 MRU(05DC) ACCM(00000000) MAGIC(004CBB35) PFC ACFC received protocol = C021 PPP[C021] RCV CONFACK ID=02 LEN=24 MRU(05DC) ACCM(00000000) MAGIC(004CBB35) PFC ACFC PPP[C021] state = opened .... authentication snipped... PAP Login Accepted: PPP[C023] state = opened PPP[8021] SND CONFREQ ID=01 LEN=16 IP_COMPRESSION(002D0F01) IPADDR(00000000) PPP[8021] state = reqsent PPP[8057] SND CONFREQ ID=01 LEN=14 INTERFACE_ID(0000000046443739) PPP[8057] state = reqsent received protocol = 8021 PPP[8021] RCV CONFREQ ID=E9 LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80601) Gateway = 192.168.6.1 PPP[8021] SND CONFACK ID=E9 LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80601) PPP[8021] state = acksent received protocol = 8021 PPP[8021] RCV CONFREQ ID=EA LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80601) Gateway = 192.168.6.1 PPP[8021] SND CONFACK ID=EA LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80601) received protocol = C023 PPP[C023] RCV AUTHACK ID=02 LEN=5 data 00 PAP Login Accepted: PPP[C023] state = opened PPP[8021] Internal error: up state = acksent PPP[8057] Internal error: up state = reqsent received protocol = 8021 PPP[8021] RCV CONFREQ ID=EB LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80601) Gateway = 192.168.6.1 PPP[8021] SND CONFACK ID=EB LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80601) received protocol = C023 PPP[C023] RCV AUTHACK ID=03 LEN=5 data 00 PAP Login Accepted: PPP[C023] state = opened PPP[8021] Internal error: up state = acksent PPP[8057] Internal error: up state = reqsent received protocol = 8021 PPP[8021] RCV CONFREQ ID=EC LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80601) Gateway = 192.168.6.1 PPP[8021] SND CONFACK ID=EC LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80601) received protocol = C023 PPP[C023] RCV AUTHACK ID=04 LEN=5 data 00 PAP Login Accepted: PPP[C023] state = opened PPP[8021] Internal error: up state = acksent PPP[8057] Internal error: up state = reqsent received protocol = 8021 PPP[8021] RCV CONFREQ ID=ED LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80601) Gateway = 192.168.6.1 PPP[8021] SND CONFACK ID=ED LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80601) received protocol = 8021 PPP[8021] RCV CONFREQ ID=EE LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80601) Gateway = 192.168.6.1 PPP[8021] SND CONFACK ID=EE LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80601) received protocol = C023 PPP[C023] RCV AUTHACK ID=05 LEN=5 data 00 PAP Login Accepted: PPP[C023] state = opened PPP[8021] Internal error: up state = acksent PPP[8057] Internal error: up state = reqsent received protocol = 8021 PPP[8021] RCV CONFREQ ID=EF LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80601) Gateway = 192.168.6.1 PPP[8021] SND CONFACK ID=EF LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80601) received protocol = C023 PPP[C023] RCV AUTHACK ID=06 LEN=5 data 00 PAP Login Accepted: PPP[C023] state = opened PPP[8021] Internal error: up state = acksent PPP[8057] Internal error: up state = reqsent received protocol = 8021 PPP[8021] RCV CONFNAK ID=01 LEN=10 IPADDR(CB11B829) My IP address = 203.17.184.41 PPP[8021] SND CONFREQ ID=02 LEN=16 IP_COMPRESSION(002D0F01) IPADDR(CB11B829) received protocol = 8021 PPP[8021] RCV CONFNAK ID=01 LEN=14 IPNUMS(CB11B829C0A80601) received protocol = 8021 PPP[8021] RCV CONFREQ ID=F0 LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80601) Gateway = 192.168.6.1 PPP[8021] SND CONFACK ID=F0 LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80601) received protocol = 8021 PPP[8021] RCV CONFACK ID=02 LEN=16 IP_COMPRESSION(002D0F01) IPADDR(CB11B829) PPP[8021] state = opened set address 203.17.184.41 255.255.255.255 192.168.6.1 PPP[8057] SND CONFREQ ID=02 LEN=14 INTERFACE_ID(0000000046443739) received protocol = 8021 PPP[8021] RCV CONFREQ ID=F1 LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80601) Gateway = 192.168.6.1 PPP[8021] SND CONFREQ ID=03 LEN=16 IP_COMPRESSION(002D0F01) IPADDR(CB11B829) PPP[8021] SND CONFACK ID=F1 LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80601) PPP[8021] state = acksent PPP[8021] state = starting received protocol = 8021 PPP[8021] RCV CONFNAK ID=02 LEN=14 IPNUMS(CB11B829C0A80601) PPP[8057] state = starting PPP[C023] state = starting PPP[C021] state = starting On Wed, 16 Sep 1998, Peter R. Tattam wrote: > I've got PPP coded up now and I have discovered a couple of issues that need > addressing. > > Since I've been trying to make my stack as user friendly as possible, my PPP > interface is designed to handle both IPv4 and IPv6. This would seem to be > perfectly reasonable. > > However, while negotiation takes place, after LCP and authentication is done, > a decision has to be made when starting up IPCP and IPV6CP. > > There are three possible outcomes. > > 1) start IPCP only. (regular IP4 stack) > 2) start IPV6CP only. (Ipv6 stack only) > 3) start both. > > I have opted for both. According to the PPP spec, if the other end doesn't > know about IPv6, PROTREJ packets should be sent which should close the IPv6CP, > which in turn should pass up the layers. > > Is this a credible thing to expect? I would have thought so. > > Anyway... I decided to test this with one of our Cisco AS5200's used for > dialup. Not sure which one I got, but two are running IOS 11.3(4) and one is > running IOS 11.3(2). > > My results were a little unexpected though. > > When I sent the IPV6CP packet through, it seems that the as5200 is > interpreting it as an IPCP packet and naked the INTERFACE_ID option, and then > the connection dropped (not sure which end dropped it). Also the received NAK > came back as an IPCP packet and not as an IPV6CP packet. > > I'm fairly sure of my results, but could stand corrected. Has anyone else > seen this kind of behaviour before? Is this a real bug in the Cisco IOS or > have I misunderstood something. > > With this kind of incompatibility, it could be a *major* headache for a > product like ours to autoconfigure itself. The only workaround I can see is > for the user to explicitly select if they want to use an Ipv4 or Ipv6 PPP > connection, and that will have problems in itself considering the huge body of > inexperienced people on the Internet. > > Puzzled > > Peter > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 16 16:42:22 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA22299 for ipng-dist; Wed, 16 Sep 1998 16:35:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA22292 for ; Wed, 16 Sep 1998 16:34:48 -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 QAA16768 for ; Wed, 16 Sep 1998 16:34:45 -0700 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA08880 for ; Wed, 16 Sep 1998 16:34:46 -0700 (PDT) Received: by INET-IMC-01 with Internet Mail Service (5.5.2232.9) id ; Wed, 16 Sep 1998 16:34:45 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF812A7@RED-MSG-50> From: Richard Draves To: "'Volsinians@aol.com'" , carlson@ironbridgenetworks.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6485) Re: Host Fragmentation Date: Wed, 16 Sep 1998 16:34:42 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I hate to inject reality into this entertaining discussion, but I asked someone who was involved with this test, and in fact the jumbo-frames were used end-to-end between the client and the server. The switch was not doing any fragmentation. > -----Original Message----- > From: Volsinians@aol.com [mailto:Volsinians@aol.com] > Sent: Wednesday, September 16, 1998 5:07 AM > To: carlson@ironbridgenetworks.com > Cc: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 6477) Re: Host Fragmentation > > > In a message dated 9/15/98 3:07:45 PM Eastern Daylight Time, > carlson@ironbridgenetworks.com writes: > > > Volsinians@aol.com writes: > > > Not true. The following paragraph has been left out. > > > > The tests were conducted using a single-processor Intel 400-MHz > > > Xeon-based server and four 333-MHz Pentium II clients. > An Alteon > > > Gigabit Ethernet server switch connected the servers > and clients. > > > > The Alteon Gigabit Ethernet server switch is a fragmenting > > > gigabit/10/100Mbps switch or extruder, but it could > > > just as well have been a fragmenting gigabit 10/100Mbps > > > router. The point is that server performance goes > > > up if the server does not do the fragmentation but > > > instead the fragmentation is off-loaded to an intermediate > > > packet switch. > > > Read the damned datasheet, please. The Alteon Gb Ethernet switch > > supports jumbograms on BOTH the Gb Ethernet ports AND the > 100Mb ports. > > Without question, that's what this test was using. That's why they > > mentioned the types of cards in the clients. > > http://www.alteon.com/pdf/ace110.pdf?124,174 > > So? The device apparently uses the same ASIC on every port, and I > suppose if the Alteon Gigabit adapter is used in 100Mbps fallback mode > on a 10/100 Mbps port, it makes sense to transceive jumbograms on the > 100Mbps medium. But such is not the situation here. > > The article only mentions the use of a single Gbps jumbogram capable > adapter card only in the server. > > Microsoft officials said they achieved 920Mbps throughput > on a server > using the AceNIC 180, a Gigabit Ethernet network interface card from > Alteon, which also supplied the proprietary jumbo-frame technology. > > I just checked the 82558/82557 and 21140 manuals. The common > 10/100Mbps adapters do not support jumbogram. While I do not have a > 21143 manual here, it is unlikely that this part supports jumbograms. > I have to assume that the tests were run as we run similar tests and > as described in Alteon white papers: the clients were using some > common 100 Mbps adapter cards, which do not support > jumbograms. Otherwise one would think that that the article would have > stated something like the following. > > Microsoft officials said they achieved 920Mbps throughput > on a server > using the AceNIC 180, a Gigabit Ethernet network interface card from > Alteon, which also supplied the proprietary jumbo-frame technology > when that server communicated with four clients all of which used > the same AceNIC 180 adapter in jumbo-frame mode. > > In point of fact all throughout the Alteon white papers and > documentation the standard described configuration is > > *) a server on one of the gigabit ports, > > *) perhaps another server on the other gigabit port and > > *)10/100 Mbps clients (using standard 10/100 Mbps non-jumbogram > supporting adapters -- Alteon does not sell a jumbogram capable 10/100 > Mbps adapter card for clients) attached to the 10/100 Mbps ports. > > The performance test that Alteon sees using WindowsNT servers is about > the performance that we see with Alteon cards in Compaq Alpha Servers > that run Unix. Clients with 32bit busses and 100 Mbps ethernet > adapter cards support a throughput of approximately 240Mbps. We find > that 64 bit buss clients with 64 bit adapter cards can support > approximately 450 Mbps. When a 64 bit server is used with jumbogram > technology where the Alteon switch performs the dreaded network > fragmentation, the server can support a throughput over 900 Mbps, > essentially doubling the number of clients that can be supported. > > Thus the use of jumbograms at the server with network fragmentation > doubles the number of clients that the server can support. The > designers of IPv6 have for no obvious reason chosen to ban > configurations that can provide tremendous performance wins. The much > touted PMTU procedures would completely thwart the benefits that the > Alteon technology provides. > > > That I'm even replying shows how much the tie I'm wearing today has > > severely constricted the blood flow above the neck. > > And has apparently affected Carlson's ability to read as well. > > I have to admit that Alteon is perhaps being a little bit obscure with > regard to their exact procedures with all this discussion in the white > papers of VLANs, intranets and P802.1q. But in the face of the > irrationality of the anti-network fragmentation point of view that we > see in this forum, I am hardly surprised. > > > *Plonk* Must remember to add this thread to the kill file. > > Understandable given the apparent reading disability. > > BTW, I obtained a copy of Mogul's fragmentation paper. Briefly > skimming, practically every point refers to technological problems > that existed 10 years ago and that are essentially irrelevant today. > If this sort of analysis provides the foundation of IPv6, IPv6 should > be described as "The Protocol of Tomorrow, Designed to Address the > Problems of Yesteryear." I will try to provide a critique of the > paper later today or tomorrow. > > 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 Wed Sep 16 17:49:46 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA22356 for ipng-dist; Wed, 16 Sep 1998 17:36:28 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA22349 for ; Wed, 16 Sep 1998 17:36:19 -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 RAA05538 for ; Wed, 16 Sep 1998 17:36:17 -0700 Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA13332 for ; Wed, 16 Sep 1998 17:36:18 -0700 (PDT) Received: from dogbert.alteon.com by relay1.UU.NET with SMTP (peer crosschecked as: alteon.com [208.200.21.146]) id QQfhdq24169; Wed, 16 Sep 1998 20:36:12 -0400 (EDT) Received: from sharks.alteon.com ([205.178.13.72]) by dogbert.alteon.com via smtpd (for relay1.UU.NET [192.48.96.5]) with SMTP; 17 Sep 1998 00:35:41 UT Received: from coastsider.acteon.com by sharks.alteon.com (SMI-8.6/SMI-SVR4) id RAA27086; Wed, 16 Sep 1998 17:35:24 -0700 Received: by coastsider.acteon.com (5.x/SMI-SVR4) id AA17955; Wed, 16 Sep 1998 17:30:12 -0700 Date: Wed, 16 Sep 1998 17:30:12 -0700 From: wayne@alteon.com (Wayne Hathaway) Message-Id: <9809170030.AA17955@coastsider.acteon.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 6486) Re: Host Fragmentation Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard Draves writes: > I hate to inject reality into this entertaining discussion, but > I asked someone who was involved with this test, and in fact > the jumbo-frames were used end-to-end between the client and > the server. The switch was not doing any fragmentation. This is indeed true. But for the point being argued in this discussion, is it relevant? Nobody disputes that network devices should be able to fragment at full speed, nor do they dispute that given a large number of clients, each should be able to reassemble fast enough. So apart from the fragment loss question, the server could have been pumping its data into a giant bit bucket: the performance improvement came SOLELY from using jumbo frames on the server. And about fragment loss, nobody can expect to get top performance over a lossy net, and a decent TCP implementation could adapt to lossage with an end result that is guaranteed to be no worse than what IPv6 limits you to, and may well be substantially better. Again I repeat: Is it reasonable for a protocol of the future to outlaw the use of network fragmentation simply because there are situations in which it might be bad with current router or host stack implementations? Wayne Hathaway Internet: wayne@alteon.com Chief Architect Phone: 408-360-5503 Alteon Networks FAX: 408-360-5501 6351 San Ignacio Avenue San Jose, CA 95119 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 01:15:15 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id BAA22568 for ipng-dist; Thu, 17 Sep 1998 01:11:11 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id BAA22561 for ; Thu, 17 Sep 1998 01:10: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 BAA26815 for ; Thu, 17 Sep 1998 01:10:58 -0700 Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA08574 for ; Thu, 17 Sep 1998 01:10:56 -0700 (PDT) Received: from alden ([10.128.1.82]) by dokka.maxware.no (8.8.5/8.8.5) with SMTP id KAA30079; Thu, 17 Sep 1998 10:10:36 +0200 Message-Id: <3.0.2.32.19980917100846.00ca1100@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Thu, 17 Sep 1998 10:08:46 +0200 To: wayne@alteon.com (Wayne Hathaway), ipng@sunroof.eng.sun.com From: Harald Tveit Alvestrand Subject: (IPng 6487) Re: Host Fragmentation In-Reply-To: <9809170030.AA17955@coastsider.acteon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 17:30 16.09.98 -0700, Wayne Hathaway wrote: >And about fragment loss, nobody can expect to get top performance >over a lossy net PLEEEEEEEEEEEEEASE: Back to basics: 1) All IP networks have TCP traffic. 2) TCP's rate adjustment is based on losing packets. See RFC 2001. 3) Therefore, ALL networks with TCP traffic on them lose packets. Repeat until understood: ALL IP NETWORKS LOSE PACKETS. How many packets they lose depends on the traffic load and the number of TCP connections, and the presence of non-adaptive traffic. But the ONLY IP network that doesn't lose packets is one where the packet senders are not able to utilize the bandwidth. I know that, you know that, we all know that. The question is NOT whether or not we'll lose parts of fragmented IP packets. It is HOW MANY. Harald T. Alvestrand -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.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 Thu Sep 17 02:28:12 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id CAA22628 for ipng-dist; Thu, 17 Sep 1998 02:25:19 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id CAA22621 for ; Thu, 17 Sep 1998 02:25: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 CAA05457 for ; Thu, 17 Sep 1998 02:25:10 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id CAA07940 for ; Thu, 17 Sep 1998 02:25:08 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id JA25455; Thu, 17 Sep 1998 19:24:55 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Richard Draves Cc: IPng List Subject: (IPng 6488) Re: nit-picky error conditions In-Reply-To: Your message of "Wed, 16 Sep 1998 09:57:13 MST." <4D0A23B3F74DD111ACCD00805F31D8100AF81297@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Sep 1998 19:24:54 +1000 Message-Id: <6493.906024294@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 16 Sep 1998 09:57:13 -0700 From: Richard Draves Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81297@RED-MSG-50> This means that the text in the ICMPv6 spec "If a router receives a packet with a Hop Limit of zero, ..., it MUST discard the packet and send an ICMPv6 Time Exceeded" should be revised. We might want some revision, but I doubt it is in that sentence. The router should only be checking the Hop Limit and sending ICMP errors if it is forwarding, not when it is receiving packets sent to its own addresses. This is the problem - it needs to be made clear that a "router" isn't a metal box kept somewhere in a cupboard, and a "host" isn't a plastic box sitting on a desk, rather a "router" is a thing which accepts packets not addressed to itself, and forwards them, and a "host" is a thing which accepts packets destined to a local address, strips the IP level headers, and passes the rest up the stack. That is, a thing receiving packets sent to its own addresses is not a router (whatever piece of hardware it might be living in, or what it might do to other packets it receives) it is a host. If that isn't already clear in the definitions, that is what needs to be fixed. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 17 04:53:05 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA22775 for ipng-dist; Thu, 17 Sep 1998 04:50:10 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA22768 for ; Thu, 17 Sep 1998 04:49: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 EAA22066 for ; Thu, 17 Sep 1998 04:49:58 -0700 Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by earth.sun.com (8.9.1/8.9.1) with SMTP id EAA05033 for ; Thu, 17 Sep 1998 04:49:59 -0700 (PDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id HAA10596; Thu, 17 Sep 1998 07:49:58 -0400 To: ipng@sunroof.eng.sun.com Path: not-for-mail From: James Carlson Newsgroups: lists.ietf.ipng Subject: (IPng 6489) Re: Host Fragmentation Date: 17 Sep 1998 07:49:58 -0400 Organization: IronBridge Networks Lines: 22 Message-ID: <86r9xb557d.fsf@helios.nis.ironbridgenetworks.com> References: <9809170030.AA17955@coastsider.acteon.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.2 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk wayne@alteon.com (Wayne Hathaway) writes: > Again I repeat: Is it reasonable for a protocol of the future to > outlaw the use of network fragmentation simply because there are > situations in which it might be bad with current router or host > stack implementations? For what it's worth, I actually agree that it's a bad idea to completely outlaw network layer fragmentation in all cases. It should certainly be avoided, optimized around, and generally spat upon, but not criminalized. However, framing the argument (pun not intended) in terms of server performance in some fundamentally flawed test isn't useful. Talk to me about multipath problems in heterogeneous networks, and I'm with you. Talk about WindozeNT running a web server, and the argument hits /dev/null along with the other messages in this thread. -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8190 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 09:10:41 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA23121 for ipng-dist; Thu, 17 Sep 1998 09:05:14 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA23114; Thu, 17 Sep 1998 09:04: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 JAA17038; Thu, 17 Sep 1998 09:04:27 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA18153; Thu, 17 Sep 1998 09:04:26 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id MAA20586; Thu, 17 Sep 1998 12:04:21 -0400 (EDT) Received: from bywasted.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA17630; Thu, 17 Sep 1998 12:04:17 -0400 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id MAA0000031787; Thu, 17 Sep 1998 12:04:17 -0400 (EDT) From: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group Message-Id: <199809171604.MAA0000031787@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: ngtrans@sunroof.eng.sun.com Cc: 6bone@isi.edu, bound@zk3.dec.com, iesg@ietf.org, iab@isi.edu, ipng@sunroof.eng.sun.com Subject: (IPng 6490) IPv6 is happening the code cannot keep breaking Date: Thu, 17 Sep 1998 12:04:17 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk WARNING!!! WARNING!!! Danger Danger Will Robbinson be careful now when you fiddle with that computer we got to get back to planet earth or we will be lost in space forever!!!! This note is to probe a discussion in ngtrans or elsewhere regarding some statement from this WG as to the state of IPv6 implementations and the pain of changing essential ingredients without regard to the existing implementations and near term users of IPv6. Let me firtst say that I would think all vendors have seen what I have seen as a vendor in the market. 1. IPv6 is showing up on customers requests for proposals when procuruing networking software as to the vendors intent to support IPv6. 2. Early Adopter customers (not just university and research labs) are asking how and when they can begin deployment of IPv6 test beds in isolated departments or LANs. 3. Network Architects at customers will ask first how do we transition to IPv6 and interoperate with IPv4. 4. ISVs are asking how can they support IPv6 but ship IPv4 binaries too. What do we need to do to our (ISV) middleware APIs? 5. How do I get an IPv6 address? 6. Do you have a guide on how what steps I take to deploy IPv6? In simple terms and the basics? These and other questions point to a market need and a market requirement, which is the result of our work on IPv6 for the past 4 years, and the core specs reaching Draft Standard at this time. In addition to some vendors adding IPv6 to their marketing and differentiating factors for networking software within their product directions. It is time we in the IETF accept the fact that we MUST stop changing basic parts of IPv6 that BREAK existing code, WITHOUT consideration for a transition state and binary compatibility. This does not mean IPv6 is done or that we don't have a lot of work to do, but rather in vendor terms treat enhancements to IPv6 as a "shipping product" not a research effort where code can be tossed aside or worse yet the entire architecture. We just saw this with the new DNS A6 record type and I believe we will fix that in NGTRANS. We also saw it by changing the socket structure for the Basic IPv6 API which will break binary compatibility for all vendors who have shipped IPv6 stacks to ISVs, OEMs, and System Integrators building embedded systems. I highly recommend at this time that "running code" for IPv6 be given a high priority in WGs working on IPv6 parts and services, and if a result will break IPv6 implementations, then an ensuing transition strategy should be part of any draft that has that end result. For example the next iteration of the IPv6 Basic API will be completed shortly and most vendors I have talked to will not break IPv6 binaries again because of this API. Neither will the The Open Group Network Group as they standardize that API as an update to Info RFC 2133. It is time to keep this in the back of our minds as we continue to work on IPv6. I think we need some statement from NGTRANS to the IETF regarding this issue as it affects the operability to get IPv6 deployed. Ideally it would be good to get such a "call" from the IAB eventually but I think first NGTRANS agreeing on this would be a first step. /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 Sep 17 09:30:37 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA23181 for ipng-dist; Thu, 17 Sep 1998 09:27:18 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA23174 for ; Thu, 17 Sep 1998 09:27:14 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA27271 for ; Thu, 17 Sep 1998 09:27:14 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA14536 for ipng@sunroof.eng.sun.com; Thu, 17 Sep 1998 09:25:57 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id CAA22604 for ; Thu, 17 Sep 1998 02:06: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 CAA04051 for ; Thu, 17 Sep 1998 02:06:56 -0700 Received: from hotmail.com (f64.hotmail.com [207.82.251.198]) by earth.sun.com (8.9.1/8.9.1) with SMTP id CAA02496 for ; Thu, 17 Sep 1998 02:06:56 -0700 (PDT) Received: (qmail 11796 invoked by uid 0); 17 Sep 1998 09:06:56 -0000 Message-ID: <19980917090656.11795.qmail@hotmail.com> Received: from 194.45.231.41 by www.hotmail.com with HTTP; Thu, 17 Sep 1998 02:06:55 PDT X-Originating-IP: [194.45.231.41] From: "Simon Elbaz" To: ipng@sunroof.eng.sun.com Content-Type: text/plain Date: Thu, 17 Sep 1998 02:06:55 PDT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Is there someone who could tell me where can I find a stable package implementing IPv6 for a Linux OS and the according net-tools ? Thanks, Simon. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 17 09:51:10 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA23210 for ipng-dist; Thu, 17 Sep 1998 09:44:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA23200 for ; Thu, 17 Sep 1998 09:44: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 JAA03071 for ; Thu, 17 Sep 1998 09:44:13 -0700 Received: from alcove.wittsend.com (alcove.wittsend.com [130.205.0.20]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA19582 for ; Thu, 17 Sep 1998 09:44:12 -0700 (PDT) Received: (from mhw@localhost) by alcove.wittsend.com (8.8.8/8.8.7) id MAA01715; Thu, 17 Sep 1998 12:43:57 -0400 From: "Michael H. Warfield" Message-Id: <199809171643.MAA01715@alcove.wittsend.com> Subject: (IPng 6491) Re: your mail In-Reply-To: <19980917090656.11795.qmail@hotmail.com> from Simon Elbaz at "Sep 17, 1998 2: 6:55 am" To: simelbaz@hotmail.com (Simon Elbaz) Date: Thu, 17 Sep 1998 12:43:57 -0400 (EDT) Cc: ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL43 (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 Simon Elbaz enscribed thusly: > Hello, > Is there someone who could tell me where can I find a stable package > implementing IPv6 for a Linux OS and the according net-tools ? > Thanks, > Simon. 1) You need the latest development kernel, currently at 2.1.122 2) Check out the IPv6 Howto: http://www.bieringer.de/linux/IPv6/IPv6-HOWTO/IPv6-HOWTO.html I've brought up several systems with IPv6 following this. There are a few "glitches" with regard to sendmail (Real Time Black Hole list is busted) and some problems with ssh that are solvable, just annoying. Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 17 11:41:57 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA23376 for ipng-dist; Thu, 17 Sep 1998 11:35:51 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA23369 for ; Thu, 17 Sep 1998 11:35:43 -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 LAA12615 for ; Thu, 17 Sep 1998 11:35:40 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA15026 for ; Thu, 17 Sep 1998 11:35:40 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id LAA19745; Thu, 17 Sep 1998 11:35:35 -0700 (PDT) Message-Id: <3.0.5.32.19980917113344.00aa7870@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 17 Sep 1998 11:33:44 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6492) IPv6 and ICMPv6 Code Point Assignments Cc: hinden@iprg.nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I posted the current and tentative IPv6 and ICMPv6 assignments for review at: ftp://playground.sun.com/pub/ipng/assignments/ The tentative code points are marked by "***". I hope to receive IANA approval shortly, but thought it useful to make them available to the w.g. in the mean time. Please let me know if you seen any errors and/or omissions. 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 Fri Sep 18 04:58:32 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA24140 for ipng-dist; Fri, 18 Sep 1998 04:55:33 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA24133 for ; Fri, 18 Sep 1998 04:55: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 EAA26924 for ; Fri, 18 Sep 1998 04:55:23 -0700 Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA19502 for ; Fri, 18 Sep 1998 04:55:23 -0700 (PDT) Received: from lana-1.trumpet.com.au (lana-1.trumpet.com.au [203.5.119.81]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id VAA16437 for ; Fri, 18 Sep 1998 21:55:20 +1000 (EST) (envelope-from pete@trumpet.com.au) Received: from lana-1.trumpet.com.au (lana-1.trumpet.com.au [203.5.119.81]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id VAA15948 for ; Fri, 18 Sep 1998 21:48:39 +1000 (EST) (envelope-from pete@trumpet.com.au) To: Peter Tattam From: pete@trumpet.com.au (Peter R. Tattam) Subject: (IPng 6494) Re: More questions about PPP over Ipv6. Issue of backward compatibility. Date: Fri, 18 Sep 1998 21:46:37 +1100 Message-ID: <3cmrgir$1ms@lana-1.trumpet.com.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Another trace... This time a bit more concise and also with the raw comms data just to show that things are as I say. I also tried it with the header compression option and it was rejected (response came back as IPCP) Also at least one beta tester has noticed the same on their service (they were just trying to use IPv4 service). I know a sample size of two is quite low, but I would guess that the probability of dialling in to a Cisco terminal server would be fairly high if taken on a global basis. Since I'd like to retain the concept of automatic configuration of either IPv4 or IPv6 services, it would be rather nice if all you folks out there can come up with some answers as to how this problem can be worked around. I need a way to probe the PPP peer to find out if IPv6 functionality is available. I've come up with a couple of ideas to workaround the problem... 1) change the PPP option numbers for IPv6CP so that they don't overlap with the IPCP option numbers. This is a bit messy because it would not be backward compatible with existing IPv6 implementations. It is also a kludge, and I don't like the idea much. 2) add a special LCP option to probe for IPv6 functionality. This should allow for backward compatibility as the unrecognized option would simply be rejected. Sort of a kludge, but might be a worthwhile extension to LCP anyway to find out which protocols the PPP server supports. If the option is rejected, one can fallback to a plain IPv4 connection since the peer knows nothing about the option. Peter See my annotations below.. PPP[C021] SND CONFREQ ID=01 LEN=24 MRU(05DC) ACCM(00000000) MAGIC(01746C80) PFC ACFC SND:0000 7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 38 7D 21 SND:0010 7D 24 7D 25 DC 7D 22 7D 26 7D 20 7D 20 7D 20 7D SND:0020 20 7D 25 7D 26 7D 21 74 6C 80 7D 27 7D 22 7D 28 SND:0030 7D 22 8B CC 7E PPP[C021] state = reqsent RCV:0000 7E FF 7D 23 C0 21 7D 21 F4 7D 20 7D 38 7D 22 7D RCV:0010 26 7D 20 7D 2A 7D 20 7D 20 7D 23 7D 24 C0 23 7D RCV:0020 25 7D 26 93 7D 30 7D 21 7D 5D 7D 27 7D 22 7D 28 RCV:0030 7D 22 92 33 7E PPP[C021] RCV CONFREQ ID=F4 LEN=24 ACCM(000A0000) AP(C023) MAGIC(9310017D) PFC ACFC PPP[C021] SND CONFACK ID=F4 LEN=24 ACCM(000A0000) AP(C023) MAGIC(9310017D) PFC ACFC SND:0000 7E FF 7D 23 C0 21 7D 22 F4 7D 20 7D 38 7D 22 7D SND:0010 26 7D 20 7D 2A 7D 20 7D 20 7D 23 7D 24 C0 23 7D SND:0020 25 7D 26 93 7D 30 7D 21 7D 5D 7D 27 7D 22 7D 28 SND:0030 7D 22 5E DE 7E PPP[C021] state = acksent PPP[C021] SND CONFREQ ID=02 LEN=24 MRU(05DC) ACCM(00000000) MAGIC(01747869) PFC ACFC SND:0000 7E FF 7D 23 C0 21 7D 21 7D 22 7D 20 7D 38 7D 21 SND:0010 7D 24 7D 25 DC 7D 22 7D 26 7D 20 7D 20 7D 20 7D SND:0020 20 7D 25 7D 26 7D 21 74 78 69 7D 27 7D 22 7D 28 SND:0030 7D 22 5F 76 7E RCV:0000 7E FF 7D 23 C0 21 7D 22 7D 22 7D 20 7D 38 7D 21 RCV:0010 7D 24 7D 25 DC 7D 22 7D 26 7D 20 7D 20 7D 20 7D RCV:0020 20 7D 25 7D 26 7D 21 74 78 69 7D 27 7D 22 7D 28 RCV:0030 7D 22 93 9B 7E PPP[C021] RCV CONFACK ID=02 LEN=24 MRU(05DC) ACCM(00000000) MAGIC(01747869) PFC ACFC PPP[C021] state = opened .... snip authentication... PPP[C023] state = reqsent RCV:0000 7E FF 7D 23 C0 23 7D 22 7D 21 7D 20 7D 25 7D 20 RCV:0010 8B 3B 7E PPP[C023] RCV AUTHACK ID=01 LEN=5 data 00 PAP Login Accepted: PPP[C023] state = opened PPP[8021] SND CONFREQ ID=01 LEN=16 IP_COMPRESSION(002D0F01) IPADDR(00000000) SND:0000 7E FF 7D 23 80 21 7D 21 7D 21 7D 20 7D 30 7D 22 SND:0010 7D 26 7D 20 2D 7D 2F 7D 21 7D 23 7D 26 7D 20 7D SND:0020 20 7D 20 7D 20 2D 99 7E PPP[8021] state = reqsent < send my IPv6 configure request> PPP[8057] SND CONFREQ ID=01 LEN=14 INTERFACE_ID(0000000046443739) SND:0000 7E FF 7D 23 80 57 7D 21 7D 21 7D 20 7D 2E 7D 21 SND:0010 7D 2A 7D 20 7D 20 7D 20 7D 20 46 44 37 39 CF 3A SND:0020 7E PPP[8057] state = reqsent RCV:0000 7E FF 03 80 21 01 FA 00 10 02 06 00 2D 0F 00 03 RCV:0010 06 C0 A8 06 05 BF 35 7E PPP[8021] RCV CONFREQ ID=FA LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80605) Gateway = 192.168.6.5 PPP[8021] SND CONFACK ID=FA LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80605) SND:0000 7E FF 7D 23 80 21 7D 22 FA 7D 20 7D 30 7D 22 7D SND:0010 26 7D 20 2D 7D 2F 7D 20 7D 23 7D 26 C0 A8 7D 26 SND:0020 7D 25 9E AF 7E PPP[8021] state = acksent RCV:0000 7E FF 03 80 21 03 01 00 0A 03 06 CB 11 B8 74 D5 RCV:0010 95 7E PPP[8021] RCV CONFNAK ID=01 LEN=10 IPADDR(CB11B874) My IP address = 203.17.184.116 PPP[8021] SND CONFREQ ID=02 LEN=16 IP_COMPRESSION(002D0F01) IPADDR(CB11B874) SND:0000 7E FF 7D 23 80 21 7D 21 7D 22 7D 20 7D 30 7D 22 SND:0010 7D 26 7D 20 2D 7D 2F 7D 21 7D 23 7D 26 CB 7D 31 SND:0020 B8 74 DB A4 7E < the offending packet occurs here --> RCV:0000 7E FF 03 80 21 03 01 00 0E 01 0A CB 11 B8 74 C0 RCV:0010 A8 06 05 B0 6D 7E PPP[8021] RCV CONFNAK ID=01 LEN=14 IPNUMS(CB11B874C0A80605) RCV:0000 7E FF 03 80 21 02 02 00 10 02 06 00 2D 0F 01 03 RCV:0010 06 CB 11 B8 74 FA 3E 7E PPP[8021] RCV CONFACK ID=02 LEN=16 IP_COMPRESSION(002D0F01) IPADDR(CB11B874) PPP[8021] state = opened set address 203.17.184.116 255.255.255.255 192.168.6.5 < send another IPv6 configure request> PPP[8057] SND CONFREQ ID=02 LEN=14 INTERFACE_ID(0000000046443739) SND:0000 7E FF 7D 23 80 57 7D 21 7D 22 7D 20 7D 2E 7D 21 SND:0010 7D 2A 7D 20 7D 20 7D 20 7D 20 46 44 37 39 38 34 SND:0020 7E RCV:0000 7E FF 03 80 21 01 FB 00 10 02 06 00 2D 0F 00 03 RCV:0010 06 C0 A8 06 05 95 7D 5D 7E PPP[8021] RCV CONFREQ ID=FB LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80605) Gateway = 192.168.6.5 PPP[8021] SND CONFREQ ID=03 LEN=16 IP_COMPRESSION(002D0F01) IPADDR(CB11B874) SND:0000 7E FF 7D 23 80 21 7D 21 7D 23 7D 20 7D 30 7D 22 SND:0010 7D 26 7D 20 2D 7D 2F 7D 21 7D 23 7D 26 CB 7D 31 SND:0020 B8 74 F1 EC 7E PPP[8021] SND CONFACK ID=FB LEN=16 IP_COMPRESSION(002D0F00) IPADDR(C0A80605) SND:0000 7E FF 7D 23 80 21 7D 22 FB 7D 20 7D 30 7D 22 7D SND:0010 26 7D 20 2D 7D 2F 7D 20 7D 23 7D 26 C0 A8 7D 26 SND:0020 7D 25 B4 E7 7E PPP[8021] state = acksent PPP[8021] state = starting RCV:0000 7E FF 03 80 21 03 02 00 0E 01 0A CB 11 B8 74 C0 RCV:0010 A8 06 05 47 63 7E PPP[8021] RCV CONFNAK ID=02 LEN=14 IPNUMS(CB11B874C0A80605) PPP[8057] state = starting PPP[C023] state = starting PPP[C021] state = starting -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 18 09:03:07 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA24511 for ipng-dist; Fri, 18 Sep 1998 08:56:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA24504 for ; Fri, 18 Sep 1998 08:56:19 -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 IAA04822 for ; Fri, 18 Sep 1998 08:56:17 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA15000 for ; Fri, 18 Sep 1998 08:56:17 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id IAA03041; Fri, 18 Sep 1998 08:56:15 -0700 (PDT) Message-Id: <3.0.5.32.19980918085423.0358adb0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 18 Sep 1998 08:54:23 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6495) W.G. Last Call on "DNS Extensions to Support IP Version" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as a Proposed Standard: Title : DNS Extensions to Support IP Version 6 Author(s) : M. Crawford, C. Huitema, S. Thomson Filename : draft-ietf-ipngwg-dns-lookups-02.txt Pages : 15 Date : 15-Sep-98 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on October 2, 1998. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 18 09:31:43 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA24592 for ipng-dist; Fri, 18 Sep 1998 09:25:40 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA24585 for ; Fri, 18 Sep 1998 09:25:28 -0700 (PDT) From: bmanning@ISI.EDU 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 JAA12278 for ; Fri, 18 Sep 1998 09:25:26 -0700 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA03135 for ; Fri, 18 Sep 1998 09:25:27 -0700 (PDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id JAA15964; Fri, 18 Sep 1998 09:25:26 -0700 (PDT) Posted-Date: Fri, 18 Sep 1998 09:20:28 -0700 (PDT) Message-Id: <199809181620.AA07407@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Fri, 18 Sep 1998 09:20:28 -0700 Subject: (IPng 6496) Re: W.G. Last Call on "DNS Extensions to Support IP Version" To: hinden@iprg.nokia.com (Bob Hinden) Date: Fri, 18 Sep 1998 09:20:28 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3.0.5.32.19980918085423.0358adb0@mailhost.iprg.nokia.com> from "Bob Hinden" at Sep 18, 98 08:54:23 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > This is a IPng working group last call for comments on advancing the > following document as a Proposed Standard: > > Title : DNS Extensions to Support IP Version 6 > Author(s) : M. Crawford, C. Huitema, S. Thomson > Filename : draft-ietf-ipngwg-dns-lookups-02.txt > Pages : 15 > Date : 15-Sep-98 > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end two > week from today on October 2, 1998. > > Bob Hinden / Steve Deering While I understand the desire to make forward progress, this particular item is still being discussed on the ngtrans and namedroppers lists as people still are trying to understand the magnitude of change in existing practice that this draft proposes. IMHO, this last call could be seen as railroading a unique, radically different, proposal into the standards track before there is reasonable understanding of how it is expected to interoperate, not only with the existing DNS for IPv4 but with the existing IPv6 practice. As a question to the chairs; do you understand the impact of this draft on IPv6? Is this draft ready for a two week last call? Its only been in the drafts directories for 2 whole days. --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 18 10:26:48 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA24757 for ipng-dist; Fri, 18 Sep 1998 10:16:06 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA24750 for ; Fri, 18 Sep 1998 10:15: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 KAA26935 for ; Fri, 18 Sep 1998 10:15:54 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA08116 for ; Fri, 18 Sep 1998 10:15:52 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id RAA27288; Fri, 18 Sep 1998 17:15:44 GMT Message-Id: <199809181715.RAA27288@inner.net> To: bmanning@ISI.EDU cc: hinden@iprg.nokia.com (Bob Hinden), ipng@sunroof.eng.sun.com Subject: (IPng 6497) Re: W.G. Last Call on "DNS Extensions to Support IP Version" In-reply-to: Your message of "Fri, 18 Sep 1998 09:20:28 PDT." <199809181620.AA07407@zed.isi.edu> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Fri, 18 Sep 1998 13:13:58 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199809181620.AA07407@zed.isi.edu>, you write: >IMHO, this last call could >be seen as railroading a unique, radically different, proposal into >the standards track before there is reasonable understanding of how >it is expected to interoperate, not only with the existing DNS for >IPv4 but with the existing IPv6 practice. I agree with Bill. Moving this draft forward is *very* premature. -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 Fri Sep 18 12:37:40 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA25337 for ipng-dist; Fri, 18 Sep 1998 12:27:59 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA25330 for ; Fri, 18 Sep 1998 12:27: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 MAA11917 for ; Fri, 18 Sep 1998 12:27:41 -0700 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA01588 for ; Fri, 18 Sep 1998 12:27:41 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA27894; Fri, 18 Sep 1998 15:27:35 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA26992; Fri, 18 Sep 1998 15:27:36 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id PAA22796; Fri, 18 Sep 1998 15:27:35 -0400 (EDT) Message-Id: <199809181927.PAA22796@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: (IPng 6498) Re: W.G. Last Call on "DNS Extensions to Support IP Version" In-reply-to: Your message of "Fri, 18 Sep 1998 08:54:23 PDT." <3.0.5.32.19980918085423.0358adb0@mailhost.iprg.nokia.com> Date: Fri, 18 Sep 1998 15:27:34 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This is a IPng working group last call for comments on advancing the > following document as a Proposed Standard: FYI, A quick look at this document indicates it has some normative dependencies on other drafts, including: [BITLBL] M. Crawford, "Binary Labels in the Domain Name System", currently draft-ietf-dnsind-binary-labels-01.txt. [DNAME] M. Crawford, "Non-Terminal DNS Name Redirection", currently draft-ietf-dnsind-dname-00.txt. [EDNS1] P. Vixie, "Extensions to DNS (EDNS1)", currently draft- ietf-dnsind-edns1-00.txt. [LOCOMP] P. Koch, "A New Scheme for the Compression of Domain Names", currently draft-ietf-dnsind-local-compression- 01.txt. As a practical matter, the document can't/won't advance until the corresponding documents are also ready to move forward. RFC 2026 prohibits the publishing of Standards Track documents that have references to drafts, when those drafts are needed in order to properly implement a protocol being documented. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 18 13:00:52 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA25436 for ipng-dist; Fri, 18 Sep 1998 12:54:41 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA25425 for ; Fri, 18 Sep 1998 12:54: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 MAA17149 for ; Fri, 18 Sep 1998 12:54:08 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id MAA15282 for ; Fri, 18 Sep 1998 12:54:10 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id OAA07156; Fri, 18 Sep 1998 14:54:02 -0500 Message-Id: <199809181954.OAA07156@gungnir.fnal.gov> To: bmanning@ISI.EDU Cc: hinden@iprg.nokia.com (Bob Hinden), ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 6499) Re: W.G. Last Call on "DNS Extensions to Support IP Version" In-reply-to: Your message of Fri, 18 Sep 1998 09:20:28 PDT. <199809181620.AA07407@zed.isi.edu> Date: Fri, 18 Sep 1998 14:54:02 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > IMHO, this last call could be seen as railroading a unique, > radically different, proposal into the standards track ... > > ... Is this draft ready for a two week last call? Its > only been in the drafts directories for 2 whole days. Everything to do with the "radical uniqueness" was present in draft-ietf-ipngwg-aaaa-03.txt -- February 6, 1998 or draft-ietf-ipngwg-dns-lookups-00.txt -- March 13, 1998. The current draft which you say we are trying to "railroad" is an update of draft-ietf-ipngwg-dns-lookups-01.txt -- August 7, 1998 which in turn was just a merge of the two drafts above. If you didn't find anything to object to in February or March, what happened in the six to seven months since then? Could it be that a WG last call was the only way to get the thing READ by the armchair pundits??? If you have some particular TECHNICAL point to make, Bill, I'm eager to see it, because you're not thought to be entirely clueless about DNS. But if you just want to whine that you haven't had time to read the draft, you have six months of inaction and silence to account for. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 18 13:14:27 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA25471 for ipng-dist; Fri, 18 Sep 1998 13:04:28 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA25464 for ; Fri, 18 Sep 1998 13:04: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 NAA19473 for ; Fri, 18 Sep 1998 13:03:59 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id NAA21080 for ; Fri, 18 Sep 1998 13:04:01 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id PAA07211; Fri, 18 Sep 1998 15:03:57 -0500 Message-Id: <199809182003.PAA07211@gungnir.fnal.gov> To: Thomas Narten Cc: Bob Hinden , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 6500) Re: W.G. Last Call on "DNS Extensions to Support IP Version" In-reply-to: Your message of Fri, 18 Sep 1998 15:27:34 EDT. <199809181927.PAA22796@cichlid.raleigh.ibm.com> Date: Fri, 18 Sep 1998 15:03:56 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > FYI, A quick look at this document indicates it has some normative > dependencies on other drafts, including: > ... > As a practical matter, the document can't/won't advance until the > corresponding documents are also ready to move forward. Thank you Mr. AD. The first two are a week AHEAD of this document, i.e., WG last call began a week ago. I'm not sure where the third one sits, but I believe it's +- two weeks of the same stage as the draft under discussion, and I would argue that the fourth reference might not be "normative". Do I seem grumpy? At the LA meeting the working group asked that this work should be moved forward quickly. I don't want to hear the snails and tortoises complaining about the dust. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 18 13:23:54 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA25499 for ipng-dist; Fri, 18 Sep 1998 13:15:34 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA25492 for ; Fri, 18 Sep 1998 13:15:23 -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 NAA21894 for ; Fri, 18 Sep 1998 13:15:19 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA26978 for ; Fri, 18 Sep 1998 13:15:21 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id NAA15484; Fri, 18 Sep 1998 13:14:50 -0700 (PDT) Message-Id: <3.0.5.32.19980918131258.00918100@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 18 Sep 1998 13:12:58 -0700 To: bmanning@ISI.EDU From: Bob Hinden Subject: (IPng 6501) Re: W.G. Last Call on "DNS Extensions to Support IP Version" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199809181620.AA07407@zed.isi.edu> References: <3.0.5.32.19980918085423.0358adb0@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, >As a question to the chairs; do you understand the impact of this >draft on IPv6? Is this draft ready for a two week last call? Its >only been in the drafts directories for 2 whole days. As documented in the minutes from the Chicago IETF, this draft was discussed and there was a consensus that it was ready for a w.g. last call. This document and/or it's predecessors have been discussed in at least the last two IETF meetings. I am sure you know this, but for others on the list it is important to know there can be two outcomes from a w.g. last call. 1) Move it forward to the IESG requesting the IESG published at as proposed standard, resulting in an IETF last call, IETF consideration, etc. 2) Deciding it is not ready for advancement due to technical issues raised. Doing a w.g. last call does not automatically mean it will be advanced. A w.g. last call to is find out if it is ready to be advanced. So as it was stated in the last call: Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. 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 Fri Sep 18 13:39:06 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA25530 for ipng-dist; Fri, 18 Sep 1998 13:30:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA25523 for ; Fri, 18 Sep 1998 13:30:16 -0700 (PDT) From: bmanning@ISI.EDU 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 NAA25802 for ; Fri, 18 Sep 1998 13:30:14 -0700 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA05075 for ; Fri, 18 Sep 1998 13:30:14 -0700 (PDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id NAA28712; Fri, 18 Sep 1998 13:30:13 -0700 (PDT) Posted-Date: Fri, 18 Sep 1998 13:25:15 -0700 (PDT) Message-Id: <199809182025.AA10552@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Fri, 18 Sep 1998 13:25:15 -0700 Subject: (IPng 6502) Re: W.G. Last Call on "DNS Extensions to Support IP Version" To: crawdad@fnal.gov (Matt Crawford) Date: Fri, 18 Sep 1998 13:25:15 -0700 (PDT) Cc: bmanning@ISI.EDU, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com In-Reply-To: <199809181954.OAA07156@gungnir.fnal.gov> from "Matt Crawford" at Sep 18, 98 02:54:02 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, I was rather partial to the DBIT proposal. This looks roughly similar. (sorry, had to actually build a network in the last six months so I was not paying too much attention) What seems odd is that this particular draft showed up as an activity of the IPv6 wg and not DNSIND wg. If I was only in the DNSIND wg I'd not know that this significant change in the behaviour of servers/resolvers was to be expected so soon. I'll have comments on this, and the other drafts that are pending in the next few days. (Off the cuff question for those whom have actually thought about this in the context of these linked drafts; What is the impact of this proposal on the DNS-SEC work, particularly for signing synth'ed RR's?) --bill (armchair zone admin and part time DNS code hacker) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 18 15:25:24 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA25854 for ipng-dist; Fri, 18 Sep 1998 15:20:17 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA25847; Fri, 18 Sep 1998 15:20:08 -0700 (PDT) From: Volsinians@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 PAA29162; Fri, 18 Sep 1998 15:20:04 -0700 Received: from imo21.mx.aol.com (imo21.mx.aol.com [198.81.17.65]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA03851; Fri, 18 Sep 1998 15:20:01 -0700 (PDT) Received: from Volsinians@aol.com by imo21.mx.aol.com (IMOv16.10) id JJQLa17823; Fri, 18 Sep 1998 18:16:11 -0400 (EDT) Message-ID: <819c995a.3602dbab@aol.com> Date: Fri, 18 Sep 1998 18:16:11 EDT To: bound@wasted.zk3.dec.com, ngtrans@sunroof.eng.sun.com Cc: 6bone@isi.edu, bound@zk3.dec.com, iesg@ietf.org, iab@isi.edu, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6503) Re: IPv6 is happening the code cannot keep breaking Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 224 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 9/17/98 12:14:33 PM Eastern Daylight Time, bound@wasted.zk3.dec.com writes: > WARNING!!! WARNING!!! Danger Danger Will Robinson be careful now when > you fiddle with that computer we got to get back to planet earth or we > will be lost in space forever!!!! > This note is to probe a discussion in ngtrans or elsewhere regarding some > statement from this WG as to the state of IPv6 implementations and the pain > of changing essential ingredients without regard to the existing > implementations and near term users of IPv6. > Let me first say that I would think all vendors have seen what I have > seen as a vendor in the market. > 1. IPv6 is showing up on customers requests for proposals when > procuruing networking software as to the vendors intent to > support IPv6. > 2. Early Adopter customers (not just university and research labs) > are asking how and when they can begin deployment of IPv6 test > beds in isolated departments or LANs. > 3. Network Architects at customers will ask first how do we transition > to IPv6 and interoperate with IPv4. > 4. ISVs are asking how can they support IPv6 but ship IPv4 binaries > too. What do we need to do to our (ISV) middleware APIs? > 5. How do I get an IPv6 address? > 6. Do you have a guide on how what steps I take to deploy IPv6? > In simple terms and the basics? > These and other questions point to a market need and a market > requirement, which is the result of our work on IPv6 for the past 4 > years, and the core specs reaching Draft Standard at this time. In > addition to some vendors adding IPv6 to their marketing and > differentiating factors for networking software within their product > directions. None of these points really point to a market need. We have seen customers ask more or less the same questions with regard to OSI, MAP, token bus, ISDN, etc. ad infinitum. If those that tout a technology promise it is the best thing since sliced bread, customers will start to ask about it whether or not there is a market for the product. In fact, if there is a genuine market for IPv6 products, vendors would start to sell products without the blessing of standards committees. BTW, I was not aware that Compaq currently offered any IPv6 products. Thus, I am surprised that Compaq could have early adopter customers. 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 Sat Sep 19 13:10:55 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA26652 for ipng-dist; Sat, 19 Sep 1998 13:04:06 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA26645 for ; Sat, 19 Sep 1998 13:03: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 NAA02191 for ; Sat, 19 Sep 1998 13:03:54 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id NAA22948 for ; Sat, 19 Sep 1998 13:03:53 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id UA27674; Sun, 20 Sep 1998 06:03:29 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: bmanning@ISI.EDU Cc: crawdad@fnal.gov (Matt Crawford), hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: (IPng 6505) Re: W.G. Last Call on "DNS Extensions to Support IP Version" In-Reply-To: Your message of "Fri, 18 Sep 1998 13:25:15 MST." <199809182025.AA10552@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Sep 1998 06:03:28 +1000 Message-Id: <24931.906235408@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 18 Sep 1998 13:25:15 -0700 (PDT) From: bmanning@ISI.EDU Message-ID: <199809182025.AA10552@zed.isi.edu> Bill, this is a bizarre combination of points to make. First, in the earlier message ... bmanning@ISI.EDU said in <199809181620.AA07407@zed.isi.edu> on Sep 18, 1998: | While I understand the desire to make forward progress, this | particular item is still being discussed on the ngtrans and | namedroppers lists And then, in this message ... If I was only in the DNSIND wg I'd not know that this significant change in the behaviour of servers/resolvers was to be expected so soon. Namedroppers is the list for the DNSIND WG, so I don't see how the item can be being discussed on the namedroppers list, and not be known to the DNSIND working group! While I don't think dnsind has seen anything about the latest version of the draft, that is, there is no current discussion on namedroppers about it, previous versions have been discussed, and I don't think anyone in dnsind has any great problems with the draft as it now appears (as distinct from the much earlier version which had servers required to synthesise AAAA records from the parts). (Off the cuff question for those whom have actually thought about this in the context of these linked drafts; What is the impact of this proposal on the DNS-SEC work, particularly for signing synth'ed RR's?) Off the cuff answer - as I read the draft, the intent is for the synth'ing to be done at about the time the zone is signed, or before (ie: when the actual data for the server is constructed out of the edited file), not when a query is received. This allows the AAAA records generated to be signed. Personally, I'm not sure I'd bother with all that mechanism (which has some nasty TTL dependancies to worry about), but would just hand install both AAAA and A6 records for as long as AAAA records are required anywhere (which as soon as this draft is approved, should not take long). But for a short term transition method, I doubt the potential problems matter. kre ps: DBIT was almost incomprehensible. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Sep 19 15:51:42 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA26741 for ipng-dist; Sat, 19 Sep 1998 15:46:56 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id PAA26734 for ; Sat, 19 Sep 1998 15:46:47 -0700 (PDT) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA04826; Sat, 19 Sep 1998 15:46:46 -0700 (PDT) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.9.1+Sun/8.9.1) id PAA07893; Sat, 19 Sep 1998 15:44:48 -0700 (PDT) Date: Sat, 19 Sep 1998 15:44:48 -0700 (PDT) From: Mukesh Kacker Message-Id: <199809192244.PAA07893@lucknow.eng.sun.com> To: bound@zk3.dec.com Subject: (IPng 6506) Re: Basic API Status 8/31/98 Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, here is a response to one of the acitons from your IPng 6390 email. > > Here is what I am waiting for: > > 1. Mukesh and Craig - Proposed compromised solution on sockaddr_in6 > array/structure/storage solution with text. > The text and "code" gets a bit more complex but so are the demands on this new data structure. (Taking care of alignment issues in APIs is unusual). I hope it is comprehensible. ====================================================================== Make the following changes to Section 3.10 (Portability Additions) The lines prefixed with ">" are quotes from the current draft text where changes are suggested. > > > One simple additions to the sockets API can help application writers. | > REPLACE above text with following: " One simple addition to the sockets API can help application writers is the "stuct sockaddr_storage". This data structure can simplify writing code portable across multiple address families and platforms. This data structure is designed with the following goals. - It has a large enough implementation specific maximum size to store the desired set of protocol specific socket address data structures Specifically, it is at least large enough to accommodate sockaddr_in and sockaddr_in6 and possibly other protocol specific socket addresses too. - It is aligned at an appropriate boundary so protocol specific socket address data structure pointers can be cast to it and access their fields without alignment problems. (e.g. pointers to sockaddr_in6 and/or sockaddr_in can be cast to it and access fields without alignment problems). - It has the initial field(s) isomorphic to the fields of the "struct sockaddr" data structure on that implementation which can be used as a discriminants for deriving the protocol in use. These initial field(s) would on most implementations either be a single field of type "sa_family_t" (isomorphic to sa_family field, 16 bits) or two fields of type uint8_t and sa_family_t respectively, (isomorphic to sa_len and sa_family_t, 8 bits each). An example implementation design of such a data structure would be as follows. " > struct sockaddr_storage { > char _ss_maxsize[128]; /* Implementation Specific */ > /* > * Plus implementation specific fields to ensure sufficient > * alignment. > * > */ > }; > REPLACE above text with following. /* * Desired design of maximum size and alignment */ #define _SS_MAXSIZE 128 /* Implementation specific max size */ #define _SS_ALIGNSIZE (sizeof (int64_t)) /* Implementation specific desired alignment */ /* * Definitions used for sockaddr_storage structure paddings design. */ #define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t)) #define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+ \ _SS_PAD1SIZE + _SS_ALIGNSIZE)) struct sockaddr_storage { sa_family_t ss_family; /* address family */ /* Following fields are implementation specific */ char _ss_pad1[_SS_PAD1SIZE]; /* 6 byte pad, this is to make implementation /* specific pad upto alignment field that */ /* follows explicit in the data structure */ int64_t _ss_align; /* field to force desired structure */ /* storage alignment */ char _ss_pad2[_SS_PAD2SIZE]; /* 112 byte pad to achieve desired size, */ /* _SS_MAXSIZE value minus size of ss_family */ /* _ss_pad1, _ss_align fields is 112 */ }; On implementations where sockaddr data structure includes a "sa_len", field this data structure would look like /* * Definitions used for sockaddr_storage structure paddings design. */ #define _SS_PAD1SIZE (_SS_ALIGNSIZE - \ (sizeof (uint8_t) + sizeof (sa_family_t)) #define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+ \ _SS_PAD1SIZE + _SS_ALIGNSIZE)) struct sockaddr_storage { uint8_t ss_len /* address length */ sa_family_t ss_family; /* address family */ /* Following fields are implementation specific */ char _ss_pad1[_SS_PAD1SIZE]; /* 6 byte pad, this is to make implementation /* specific pad upto alignment field that */ /* follows explicit in the data structure */ int64_t _ss_align; /* field to force desired structure */ /* storage alignment */ char _ss_pad2[_SS_PAD2SIZE]; /* 112 byte pad to achieve desired size, */ /* _SS_MAXSIZE value minus size of ss_len, */ /* ss_family,_ss_pad1, _ss_align fields is 112 */ }; The above example implementation illustrates a data structure which will align on a 64 bit boundary. An implementation specific field "_ss_align" along "_ss_pad1" is used to force a 64-bit alignment which covers proper alignment good enough for needs of sockaddr_in6 (IPv6), sockaddr_in (IPv4) address data structures. The size of padding fields _ss_pad1 depends on the chosen alignment boundary. The size of padding field _ss_pad2 depends on the value of overall size chosen for the total size of the structure. This size and alignment are represented in the above example by implementation specific (not required) constants _SS_MAXSIZE (chosen value 128) and _SS_ALIGNMENT (with chosen value 8). Constants _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value 112) are also for illustration and not required. The implementation specific definitions and structure field names above start with an underscore to denote implementation private namespace. Portable code is not expected to access or reference those fields or constants. > This structure solves the problem that you don't know how big the | > retrieve buffer for a socket address structure needs to be until you | > have received that structure (e.g., getpeername()). The sockaddr_storage structure solves the problem of declaring storage for automatic variables which is large enough and aligned enough for storing socket address data structure of any family. For example, code with a file descriptor and without the context of the address family can pass a pointer to a variable of this type where a pointer to a socket address structure is expected in calls such as getpeername() and determine the address family by accessing the received content after the call. The sockaddr_storage structure may also be useful and applied to certain other interfaces where a generic socket address large enough and aligned for use with multiple address families may be needed. A discussion of those interfaces is outside the scope of this document. > Also, much | > existing code assumes that any socket address structure can fit in a | > generic sockaddr structure. While this has been true for IPv4 socket | > address structures, it has always been false for Unix domain socket | > address structures (but in practice this has not been a problem) and | > it is also false for IPv6 socket address structures (which can be a | > problem). | > > So now an application can to the following: | > > struct sockaddr_storage ss; > .... > struct sockaddr_in6 *sin6; > > sin6 = (struct sockaddr_in6 *) &ss; > > > Each implementation can add whatever fields it needs to get appropriate | > aligment. | > In the above text, - CORRECT a minor typo by modifying "...can to following:" to "...can do following" - DELETE the last sentence (as that stuff is stated elsewhere/differently now). That is, delete the following: "Each implementation ....appropriate alignment" ====================================================================== -Mukesh Kacker Sun Microsystems Inc. mukesh.kacker@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 Sep 21 06:55:13 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA27572 for ipng-dist; Mon, 21 Sep 1998 06:47:03 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA27565 for ; Mon, 21 Sep 1998 06:46:48 -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 GAA26813 for ; Mon, 21 Sep 1998 06:46:40 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA25559 for ; Mon, 21 Sep 1998 06:46:37 -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 JAA16592; Mon, 21 Sep 1998 09:46:33 -0400 (EDT) Message-Id: <199809211346.JAA16592@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6508) I-D ACTION:draft-ietf-ipngwg-router-renum-05.txt Date: Mon, 21 Sep 1998 09:46:33 -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 : Router Renumbering for IPv6 Author(s) : M. Crawford Filename : draft-ietf-ipngwg-router-renum-05.txt Pages : 22 Date : 17-Sep-98 IPv6 Neighbor Discovery and Address Autoconfiguration conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes. This document defines a mechanism called Router Renumbering ('RR') which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site. 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-router-renum-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-05.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-router-renum-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980917172849.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-router-renum-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-router-renum-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980917172849.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 Sep 21 19:50:23 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA28601 for ipng-dist; Mon, 21 Sep 1998 19:45:29 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id TAA28594 for ; Mon, 21 Sep 1998 19:45: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 TAA19251 for ; Mon, 21 Sep 1998 19:45:20 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA21586 for ; Mon, 21 Sep 1998 19:45:21 -0700 (PDT) Received: from spruce.iprg.nokia.com (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id TAA25706; Mon, 21 Sep 1998 19:45:20 -0700 (PDT) Message-Id: <3.0.5.32.19980921194333.037f3460@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 21 Sep 1998 19:43:33 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6509) W.G. Last Call on "Router Renumbering for IPv6" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as a Proposed Standard: Title : Router Renumbering for IPv6 Author(s) : M. Crawford Filename : draft-ietf-ipngwg-router-renum-05.txt Pages : 22 Date : 17-Sep-98 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on October 5, 1998. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 23 10:12:23 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA00323 for ipng-dist; Wed, 23 Sep 1998 10:00:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA00316 for ; Wed, 23 Sep 1998 10:00: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 JAA24312 for ; Wed, 23 Sep 1998 09:59:38 -0700 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA27221 for ; Wed, 23 Sep 1998 09:59:35 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA37874 for ; Wed, 23 Sep 1998 12:59:28 -0400 Received: from clemson.raleigh.ibm.com (clemson.raleigh.ibm.com [9.37.176.99]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA22370 for ; Wed, 23 Sep 1998 12:59:30 -0400 Received: by clemson.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA03512; Wed, 23 Sep 1998 13:00:36 -0400 From: haberman@raleigh.ibm.com (Brian K. Haberman) Message-Id: <9809231700.AA03512@clemson.raleigh.ibm.com> Subject: (IPng 6510) Routing of Scoped Addresses To: ipng@sunroof.eng.sun.com Date: Wed, 23 Sep 1998 13:00:35 -0400 (EDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, The following draft addresses the routing issues of supporting scoped addresses. It will be sent to the editor soon. Please direct any technical discussion to the list and editorial comments to me. Brian Haberman INTERNET DRAFT Brian Haberman September 1998 IBM Routing of Scoped Addresses in the Internet Protocol Version 6 (IPv6) Status of This Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), ftp.isi.edu (US West Coast). Abstract This document outlines a mechanism for generating routing tables that include scoped IPv6 addresses. It defines a set of rules for routers to implement in order to forward scoped unicast and multicast addresses regardless of the routing protocol. It should be noted that these rules will apply to all scoped addresses. Haberman Expires March 1999 [Page i] Internet Draft Routing of Scoped Addresses September 1998 Contents 1. Introduction 1 2. Assumptions and Definitions 1 3. Single Site Routing 1 4. Site Boundary Unicast Routing 2 4.1. Routing Protocols . . . . . . . . . . . . . . . . . . . . 2 4.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 4 5. Scoped Multicast Routing 5 5.1. Routing Protocols . . . . . . . . . . . . . . . . . . . . 5 5.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 5 6. Protocol Impact 6 Haberman Expires March 1999 [Page ii] Internet Draft Routing of Scoped Addresses September 1998 1. Introduction This document defines a set of rules for the generation of forwarding tables that contain scoped addresses. This document describes the handling of scoped addresses for both single site and site boundary routers. Ideally, these concepts should be included in followup drafts of IPv6 routing protocols. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 2. Assumptions and Definitions This document makes several assumptions concerning sites : - Site boundaries cut through nodes - Site boundaries are identical for unicast and multicast traffic - A single interface can only be in one site - Each interface participating in a site has a site identifier - In the absence of explicit configuration, all site identifiers on a node default to the same value A single site router is defined as a router configured with the same site identifier on all interfaces. A site boundary router is defined as a router that has at least 2 distinct site identifiers configured. This could include a router connected to 2 distinct sites or a router connected to 1 site and a separate global network (Figure 1). 3. Single Site Routing In a single site router, a routing protocol can advertise and route all addresses and prefixes on all interfaces. This configuration does not require any special handling for site local addresses. The reception and transmission of site local addresses is handled in the same manner as globally scoped addresses. This applies to both unicast and multicast routing protocols. Haberman Expires March 1999 [Page 1] Internet Draft Routing of Scoped Addresses September 1998 * * * * * Site ID = X * * * * * +-*---|--------|---*-+ | * i/f 1 i/f 2 * | | **************** | | | | | | Router | ***************** ******************* | * * | Site ID = Y - i/f 3 * * i/f 4 - Site ID = Default | * * | ***************** ******************* +--------------------+ Figure 1: Multi-Sited Router 4. Site Boundary Unicast Routing With respect to site boundaries, routers must consider which interfaces a packet can be transmitted on as well as control the propagation of routing information specific to the site. This includes controlling which prefixes can be advertised on an interface. 4.1. Routing Protocols When a routing protocol determines that it is a site boundary router, it must perform additional work in order to protect inter site integrity and still maintain intra site connectivity. In order to maintain connectivity, the routing protocol must be able to create forwarding information for the global prefixes as well as for all of the site prefixes for each of its attached sites. The most straight forward way of doing this is to create up to (n + 1) routing tables; one for the global prefixes, if any, and one for each of the (n) sites. Haberman Expires March 1999 [Page 2] Internet Draft Routing of Scoped Addresses September 1998 To protect inter site integrity, routers must be selective in the forwarding information that is shared with neighboring routers. Routing protocols routinely transmit their routing information to neighboring routers. When a router is transmitting this routing information, it must not include any information about sites other than the site defined on the interface used to reach a neighbor. * * * * * Site ID = X * * * * * +-*---|--------|---*-+ | * i/f 1 i/f 2 * | | **************** | | | | | | Router | ***************** ******************* | * * | Site ID = Y - i/f 3 * * i/f 4 - Site ID = Default | * * | ***************** ******************* +--------------------+ i/f 1 : global prefix = 3FFE:20::/64 site prefix = FEC0:0:0:N/64 i/f 2 : no global prefix site prefix = FEC0:0:0:K/64 i/f 3 : global prefix = 3FFE:40::/64 site prefix = FEC0:0:0:M/64 i/f 4 : global prefix = 3FFE:80::/64 no site prefix Figure 2: Routing Information Exchange As an example, the router in Figure 2 must advertise routing information on four interfaces. The information advertised is as follows : Haberman Expires March 1999 [Page 3] Internet Draft Routing of Scoped Addresses September 1998 - Interface 1 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 3FFE:80::/64) * Site prefix FEC0:0:0:N/64 * Site prefix FEC0:0:0:K/64 - Interface 2 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 3FFE:80::/64) * Site prefix FEC0:0:0:N/64 * Site prefix FEC0:0:0:K/64 - Interface 3 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 3FFE:80::/64) * Site prefix FEC0:0:0:M/64 - Interface 4 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 3FFE:80::/64) By imposing advertisement rules, site integrity is maintained by keeping all site routing information contained within the site. 4.2. Packet Forwarding In addition to the extra cost of generating additional forwarding information for each site, site boundary routers must also do some additional checking when forwarding packets that contain site local addresses. If a packet being forwarded contains a site local destination address, regardless of the scope of the source address, the router must perform the following : - Lookup incoming interface's site identifier Haberman Expires March 1999 [Page 4] Internet Draft Routing of Scoped Addresses September 1998 - Perform route lookup for destination address in arrival interfaces site scoped routing table If a packet being forwarded contains a site local source address and a globally scoped destination address, the following must be performed : - Lookup outgoing interface's site identifier - Compare inbound and outbound interfaces' site identifiers If the site identifiers match, the packet can be forwarded. If they do not match, an ICMPv6 destination unreachable message must be sent to the sender with a new code value, code = 5 (Scope Mismatch). This ICMPv6 message will indicate that the destination address is not reachable with the specified source address. 5. Scoped Multicast Routing With IPv6 multicast, there are multiple scopes supported. Multicast routers must be able to control the propagation of scoped packets based on administratively configured boundaries. 5.1. Routing Protocols Multicast routing protocols will have to follow the same rules as the unicast protocols. They will be required to maintain information about global prefixes as well as information about all scope boundaries that pass through the router. Multicast protocols that rely on underlying unicast protocols (i.e. PIM) will not suffer as much of a performance impact since the unicast protocol will handle the forwarding table generation. They must be able to handle the additional scope boundaries used in multicast addresses. Multicast protocols that generate and maintain their own routing tables will have to perform the additional route calculations for scope. All multicast protocols will be forced to handle 14 additional scoping identifiers above the site identifiers supported in IPv6 unicast addresses. 5.2. Packet Forwarding The forwarding rules for multicast can be described by the following combinations : Haberman Expires March 1999 [Page 5] Internet Draft Routing of Scoped Addresses September 1998 - Global multicast destination address / Global unicast source address - Global multicast destination address / Site local unicast source address - Scoped multicast destination address / Global unicast source address - Scoped multicast destination address / Site local unicast source address The first combination requires no special processing over what is currently in place for global IPv6 multicast. Combinations 2,3, and 4 should result in the router performing the same identifiers check as outlined for site local unicast addresses. Since IPv6 supports fifteen unique multicast scopes, it is assumed that scopes 0x1 through 0x4 are strictly less than the unicast site scope, scope 0x5 (site) is equal to the unicast site scope, scopes 0x6 through 0xd are strictly greater than the unicast site scope and strictly less than the unicast global scope, and scope 0xe is equal to the unicast global scope. 6. Protocol Impact The performance impact on routing protocols is obvious. Routers implementing scoped address support will be forced to perform an additional check in the main forwarding path to determine if the source address is scoped. This will add overhead to the processing of every packet flowing through the router. In addition, there will be some storage overhead for the scope identifiers. If scoped addresses are going to be realized, this performance impact may be acceptable. References [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP14, March 1997. Security Considerations This document specifies a set of guidelines that allow routers to prevent site Haberman Expires March 1999 [Page 6] Internet Draft Routing of Scoped Addresses September 1998 specific information from leaking out of each site. If site boundary routers allow site routing information to be forwarded outside of the site, the integrity of the site could be compromised. Acknowledgements I would like to thank Thomas Narten, Steve Deering, and Erik Nordmark for their comments and reviews of this document. Author's Address Brian Haberman IBM Corporation 800 Park Office Drive Research Triangle Park, NC 27709 USA +1-919-254-2673 haberman@raleigh.ibm.com Haberman Expires March 1999 [Page 7] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 23 16:48:31 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA00796 for ipng-dist; Wed, 23 Sep 1998 16:39:54 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA00789 for ; Wed, 23 Sep 1998 16:39:42 -0700 (PDT) From: Volsinians@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 QAA03675 for ; Wed, 23 Sep 1998 16:39:39 -0700 Received: from imo12.mx.aol.com (imo12.mx.aol.com [198.81.17.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA19793 for ; Wed, 23 Sep 1998 16:39:39 -0700 (PDT) Received: from Volsinians@aol.com by imo12.mx.aol.com (IMOv16.10) id NBTEa19215; Wed, 23 Sep 1998 19:38:38 -0400 (EDT) Message-ID: Date: Wed, 23 Sep 1998 19:38:38 EDT To: Volsinians@aol.com, ipng@sunroof.eng.sun.com Cc: martillo@chem2.harvard.edu Mime-Version: 1.0 Subject: (IPng 6511) Re: Host Fragmentation 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 I have added the following analysis to my website. (I have also added the first chapter of my textbook as well. Some of the information may be of interest, and I always appreciate comments.) The C.R.I.T.I.C. Analyzes an IPv6 Design Choice One of the most curious aspects of IPv6 is the prohibition on network fragmentation even as the IPv6 permits host fragmentation, which the receiver could not possibly distinguish from network fragmentation. The point of such a prohibition is extremely hard to understand. For massive web and file servers major performance wins can be achieved with network fragmentation. We have seen the number of clients served go from 10-12,000 clients per second to 16,000 clients per second merely by configuring the server to use jumbograms on a gigabit medium while an intermediate system performed network fragmention. Wayne Hathaway, Chief Architect of Alteon Networks, described the issue quite well in a recent e-mail on the IPv6 mailing list. Nobody disputes that network devices should be able to fragment at full speed, nor do they dispute that given a large number of clients, each should be able to reassemble fast enough. So apart from the fragment loss question, the server could have been pumping its data into a giant bit bucket: the performance improvement came SOLELY from using jumbo frames on the server. And about fragment loss, nobody can expect to get top performance over a lossy net, and a decent TCP implementation could adapt to lossage with an end result that is guaranteed to be no worse than what IPv6 limits you to, and may well be substantially better. Again I repeat: Is it reasonable for a protocol of the future to outlaw the use of network fragmentation simply because there are situations in which it might be bad with current router or host stack implementations? During a recent discussion on the IPv6 mailing list, several opponents of permitting network fragmentation justified their position by reference to Fragmentation Considered Harmful, which I have made available with some comments to relate the 1987 analysis in the document with the realities of today's 1998 Internet. The document is practically useless as an input into the design of the protocol of the future. None of the analysis actually indicates any real flaws with fragmentation as a procedure when it is used properly. Almost all the problems identified in this paper are problems associated with 1987 software and hardware including without limitation: * buggy 1987 implementations of the Berkeley network layer, * some questionably implemented pronet-10 or pronet-80 adapter cards of the 1985-7 time frame and * memory starved routers of the same time frame. The paper should never have been used as an input to the design of IPv6. 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 Thu Sep 24 02:45:44 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id CAA01065 for ipng-dist; Thu, 24 Sep 1998 02:42:36 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id CAA01058 for ; Thu, 24 Sep 1998 02:42: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 CAA07344 for ; Thu, 24 Sep 1998 02:42:12 -0700 Received: from wentzl.cdg.chalmers.se (wentzl.cdg.chalmers.se [129.16.12.9]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA12322 for ; Thu, 24 Sep 1998 02:42:12 -0700 (PDT) Received: from wilfer1.cdg.chalmers.se (BFszkLUwBdUZ6lDURZ5C+mq6+gMK1XeS@wilfer1.cdg.chalmers.se [129.16.12.11]) by wentzl.cdg.chalmers.se (8.8.8/8.8.8) with ESMTP id LAA07626; Thu, 24 Sep 1998 11:42:08 +0200 (MET DST) From: Gunnar Lindberg Received: (from lindberg@localhost) by wilfer1.cdg.chalmers.se (8.8.8/8.8.8) id LAA06249; Thu, 24 Sep 1998 11:42:06 +0200 (MET DST) Date: Thu, 24 Sep 1998 11:42:06 +0200 (MET DST) Message-Id: <199809240942.LAA06249@wilfer1.cdg.chalmers.se> To: Volsinians@aol.com, ipng@sunroof.eng.sun.com Subject: (IPng 6512) Re: Host Fragmentation Cc: martillo@chem2.harvard.edu X-Mailer: UCB Mail 5.3.10 1998-06-04 (MIME) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From: Volsinians@aol.com >Date: Wed, 23 Sep 1998 19:38:38 EDT >Message-ID: >To: Volsinians@aol.com, ipng@sunroof.Eng.Sun.COM >Cc: martillo@chem2.harvard.edu >Subject: (IPng 6511) Re: Host Fragmentation > ... >The document is practically useless as an input into the design of the >protocol of the future. None of the analysis actually indicates any >real flaws with fragmentation as a procedure when it is used >properly. Almost all the problems identified in this paper are >problems associated with 1987 software and hardware including without >limitation: There is at least one case where fragmentation can cause severe problems (page 4 in "Fragmentation Considered Harmful"). If you fragment and one of the fragments gets dropped: a) The entire IP-packet is lost. Maybe no big deal, that's life on the Internet. b) The other fragments may still have been transmitted, using up bandwidth and other (network) resources. Now, that *is* bad. That's reality. If that requires another paradigm is beyond me. Gunnar Lindberg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 24 04:56:47 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA01162 for ipng-dist; Thu, 24 Sep 1998 04:53:24 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA01154 for ; Thu, 24 Sep 1998 04:53: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 EAA15359 for ; Thu, 24 Sep 1998 04:53:10 -0700 Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by earth.sun.com (8.9.1/8.9.1) with SMTP id EAA19218 for ; Thu, 24 Sep 1998 04:53:11 -0700 (PDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id HAA29951; Thu, 24 Sep 1998 07:53:10 -0400 To: ipng@sunroof.eng.sun.com Path: not-for-mail From: James Carlson Newsgroups: lists.ietf.ipng Subject: (IPng 6513) Re: Host Fragmentation Date: 24 Sep 1998 07:53:10 -0400 Organization: IronBridge Networks Lines: 25 Message-ID: <86u31xn2vt.fsf@helios.nis.ironbridgenetworks.com> References: <199809240942.LAA06249@wilfer1.cdg.chalmers.se> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.2 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk lindberg@cdg.chalmers.se (Gunnar Lindberg) writes: > b) The other fragments may still have been transmitted, > using up bandwidth and other (network) resources. > Now, that *is* bad. Quite true. To avoid that, we'd need some kind of horrible ATM-like PPD/EPD trick, which implies per-flow state. This congestion problem with IP fragmentation also gets noticeably worse as the drop rate goes up. You very quickly into a situation where the only things that are sent are worthless shards of broken packets because IP, unlike TCP, is not congestion-sensitive. And all of those fragments with offset==0 cause stale reassembly buffers to time out in the affected hosts ... (Wonderful congestion-avoidance tricks like RED would seem to make the problem worse still, since they cause statistical rather than bursty packet loss, which is exactly the situation in which IP fragments fail to reassemble at high rates.) -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8190 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 24 05:39:15 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA01235 for ipng-dist; Thu, 24 Sep 1998 05:29:38 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA01228 for ; Thu, 24 Sep 1998 05:29:30 -0700 (PDT) From: Volsinians@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 FAA18455 for ; Thu, 24 Sep 1998 05:29:27 -0700 Received: from imo18.mx.aol.com (imo18.mx.aol.com [198.81.17.8]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA02047 for ; Thu, 24 Sep 1998 05:29:29 -0700 (PDT) Received: from Volsinians@aol.com by imo18.mx.aol.com (IMOv16.10) id TDXCa29193; Thu, 24 Sep 1998 08:28:49 -0400 (EDT) Message-ID: Date: Thu, 24 Sep 1998 08:28:49 EDT To: lindberg@cdg.chalmers.se, ipng@sunroof.eng.sun.com Cc: martillo@chem2.harvard.edu Mime-Version: 1.0 Subject: (IPng 6514) Re: Host Fragmentation 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-09-24 06:02:45 EDT, lindberg@cdg.chalmers.se writes: > There is at least one case where fragmentation can cause severe > problems (page 4 in "Fragmentation Considered Harmful"). If you > fragment and one of the fragments gets dropped: > a) The entire IP-packet is lost. > Maybe no big deal, that's life on the Internet. > b) The other fragments may still have been transmitted, > using up bandwidth and other (network) resources. > Now, that *is* bad. > That's reality. If that requires another paradigm is beyond me. What reality? If a fragment gets dropped every other packet, there is a problem. If a fragment gets dropped once every 10,000,000 packets, this dropping is more in the range of the bit error rates. All the models that Kent and Mogul provide in that paper are worthless because they are assuming some sort of deterministic fragmentation caused by pronet 10/80 adapters (how often do we see these around today?), buggy 4.2 BSD implementations of the network layer that are approximately 15 years old (time to upgrade the system) and old pre-1987 memory starved routers (I think it is time to replace them). If someones provide some real data on today's network and reasoning that does not depend on the assumption of old-fashioned, poorly designed or misdesigned hardware and very old very buggy software, there would be some reason to pay attention to his analysis. Paying attention to the Mogul paper to design the protocol of the future is ludicrous. If fragmentation loss begins to be a problem, there are ways to try to adapt in software. Maybe the transmit congestion control mechanisms can be modified to detect fragment loss. But not even attempting to deal with the problem because programmers in 1985-7 were not up to the job is simply inappropriate. In any case, IPv6 permits host fragmentation. I can certainly think of scenarios where host fragmentation causes problems that are solved by network fragmentation (not to mention my web server that gets 30% more performance with network fragmentation than with segmentation or host fragmentation). Why permit host fragmentation and forbid network fragmentation? Suppose near the transmitter there is an underpowered (non-wirespeed router that can't keep up with data being received) when the packets are small on a large MTU medium. Guess what? Small segments or fragments from the host (permitted by the IPv6 specification) could worsen the problems at the router, while sending large packets with downstream network fragmentation beyond the underpowered router might make the problem livable. So you argue that the congestion control mechanisms would solve the problem be detecting congestion. Suppose that the congestion is being caused by 18,000 upstream source hosts that are already only sending one segment at a time because they have detected the congestion or because the connections are all in the initial phases of the congestion adaption algorithm. Maybe 2,000 hosts have nothing to send. Maybe 2,000 packets got lost and each of the 2,000 hosts that sent the dropped packets throttle their transmit rates. Suppose while those 2,000 are throttled, the other 2,000 hosts start sending packets. Another, 2000 hosts loose packets while the 2,000 hosts that were throttled start transmitting again, and this times the packets from these hosts get to the destination and get acknowledged quickly so that they up their rate of segment transmission. Lots of thrashing can occur for a long time. Suppose that packets 10 times as large were sent 1/10 as frequently. Assuming the hosts are generating data at the same rate in the jumbopacket and normal packet scenaries, there will be only about 200 packets lost per second assuming that the router has the same problems in the jumbopacket scenario that it has in the small packet scenario. But guess what? The router is now doing 1/10 the number of look-ups per second. It might keep up, and the network could settle down into a nice steady state with no packet loss You argue the condition is unlikely. Guess what? There is so much traffic and so many packets in today's Internet that every scenario occurs, and the situation described above is probably at least as likely as finding 1987 or before pronet-10/80 adapters, buggy 4.2 BSD implementations or at least 11 years old memory starved routers in use. So you argue by permitting network fragmentation, I am designing to the needs of inadequate hardware. I say. No, I am making sure the design is robust in the face of inadequate hardware. Mogul and Kent's philosophy is exactly the reverse. They say inadequate hardware and software exist; therefore, performance on adeqate hardware and software systems should be crippled. Does such logic make any sense whatsoever? Is it good engineering? There simply is no reason to forbid network fragmentation while permitting host fragmentation. And the Mogul paper is not a reasonable basis for any 1998 design decisions (in fact any design decisions for technology to be developed after 1989 and even 1989 is a stretch because the systems that Mogul was using were probably already out-dated in 1987). 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 Thu Sep 24 06:06:37 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA01266 for ipng-dist; Thu, 24 Sep 1998 05:55:38 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA01259 for ; Thu, 24 Sep 1998 05:55:28 -0700 (PDT) From: Volsinians@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 FAA20680 for ; Thu, 24 Sep 1998 05:55:24 -0700 Received: from imo27.mx.aol.com (imo27.mx.aol.com [198.81.17.71]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA11925 for ; Thu, 24 Sep 1998 05:55:26 -0700 (PDT) Received: from Volsinians@aol.com by imo27.mx.aol.com (IMOv16.10) id 7EDJa10655; Thu, 24 Sep 1998 08:55:17 -0400 (EDT) Message-ID: <27e927f0.360a4135@aol.com> Date: Thu, 24 Sep 1998 08:55:17 EDT To: carlson@ironbridgenetworks.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6515) Re: Host Fragmentation 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-09-24 08:20:02 EDT, carlson@ironbridgenetworks.com writes: > lindberg@cdg.chalmers.se (Gunnar Lindberg) writes: > > b) The other fragments may still have been transmitted, > > using up bandwidth and other (network) resources. > > Now, that *is* bad. > Quite true. To avoid that, we'd need some kind of horrible ATM-like > PPD/EPD trick, which implies per-flow state. > This congestion problem with IP fragmentation also gets noticeably > worse as the drop rate goes up. You very quickly into a situation > where the only things that are sent are worthless shards of broken > packets because IP, unlike TCP, is not congestion-sensitive. And all > of those fragments with offset==0 cause stale reassembly buffers to > time out in the affected hosts ... > (Wonderful congestion-avoidance tricks like RED would seem to make the > problem worse still, since they cause statistical rather than bursty > packet loss, which is exactly the situation in which IP fragments fail > to reassemble at high rates.) Is there perhaps some data or a paper more reasonable than the fundamentally vacuous and worthless Mogul fragmentation paper? I will read it. We can hope the argument of such a paper will not depend on 15 year old pronet-10/80 adapters and buggy 4.2 BSD software. I have the perhaps mistaken impression that ATM systems typically do not have a lot of queuing built into them and that the designers of ATM were targeting problems like streaming video. In situations and environments that are more amenable to statistically multiplexed packet switching, sufficient per transmitter per receiver queuing in the face of transient demands for outgoing bandwidth greater than the outgoing channel bandwidth eliminates almost all fragment loss. If demand on a channel for outgoing bandwidth greater than the channel bandwidth occurs too frequently for too long, the demand is beginning to appear sustained. Either the traffic may not be amenable to statistically multiplexed packet switching techniques or the traffic engineering of network is or has become incorrect, in which case a higher bandwidth link is required. 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 Thu Sep 24 06:23:45 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA01295 for ipng-dist; Thu, 24 Sep 1998 06:11:24 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA01288 for ; Thu, 24 Sep 1998 06:11: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 GAA22845 for ; Thu, 24 Sep 1998 06:11:08 -0700 Received: from doorstep.unety.net (ns.unety.net [207.32.128.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id GAA19271 for ; Thu, 24 Sep 1998 06:11:10 -0700 (PDT) Received: from webster (webster.unir.net [207.32.159.5]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id IAA02088; Thu, 24 Sep 1998 08:11:04 -0500 Message-ID: <0cee01bde7bd$098e5540$059f20cf@webster.unir.net> Reply-To: "Jim Fleming" From: "Jim Fleming" To: , , Cc: Subject: (IPng 6516) Another Terrible Mistake or Another Terrific Move ? Date: Thu, 24 Sep 1998 08:12:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -----Original Message----- From: Volsinians@aol.com >Why permit host fragmentation and forbid network fragmentation? > IPv6 was designed by people that openly write in their documents and books that they think ATM is.... "Another Terrible Mistake" An IPv6 header is typically 40 bytes. An ATM cell payload is 48 bytes. There is not a lot of room to do anything useful. Some people see that as a "feature" or benefit of IPv6. Some also see the fragmentation design as a feature and Another Terrific Move (ATM) of IPv6 designers. The typical IPv8 (and IPv16) header is 20 bytes. It was designed to be ATM-friendly. Some people view IPv8 as Another Terrible Mistake and others view it as Another Terrific Move. Since IPv8 is basically a rework of IPv4, it is hard to imagine how it could be such a big mistake since IPv4 has served people well for several years. Despite that, the debates will continue...ATM or ATM...?...that is the question... Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)---C+@------C+@---(Java)VPC http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://www.ddj.com/index/author/idx10133.htm -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 24 06:58:55 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA01416 for ipng-dist; Thu, 24 Sep 1998 06:47:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA01409 for ; Thu, 24 Sep 1998 06:47: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 GAA28790 for ; Thu, 24 Sep 1998 06:47:06 -0700 Received: from shultz.argon.com (shultz.argon.com [208.234.161.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA06664 for ; Thu, 24 Sep 1998 06:47:09 -0700 (PDT) Received: from hochstetter (hochstetter.argon.com [208.234.161.53]) by shultz.argon.com (8.8.6/8.8.6) with SMTP id JAA12591; Thu, 24 Sep 1998 09:47:06 -0400 (EDT) Message-Id: <3.0.3.32.19980924094205.00985490@shultz.argon.com> X-Sender: kasten@shultz.argon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 24 Sep 1998 09:42:05 -0400 To: Volsinians@aol.com, ipng@sunroof.eng.sun.com From: Frank Kastenholz Subject: (IPng 6517) Packet Loss (was Re: Re: Host Fragmentation Cc: martillo@chem2.harvard.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 08:28 AM 9/24/98 EDT, Volsinians@aol.com wrote: >If someones provide some real data on today's network and reasoning >that does not depend on the assumption of old-fashioned, poorly >designed or misdesigned hardware and very old very buggy software, >there would be some reason to pay attention to his analysis. Paying >attention to the Mogul paper to design the protocol of the future is >ludicrous. Packet loss in today's network is a not insignificant problem. About a year ago I was doing some web browsing from home looking at some pages that had several moderate to large pictures on them. While I have a 28.8 modem, I was getting only a couple hundred bytes/second aggregate goodput downloading the pages, much less than the 2-3KB I should see (doing simple arithmetic). At first I thought it was just some odd property of the compression in the modem. Soon I notived that the aggregate goodput was much higher for pages with only one or two pictures than, say, 5 or 6. I turned on a packet tracer, downloaded a page with several pictures and discovered some truly odd packet reception patterns. Lots of retransmissions, occasionally I'd get the same packet (by TCP sequence number) several times back to back, etc, etc. To make a long story short, the problem was that I had multiple TCP connections open (one per image) and they all were imploding onto the same dialup server at my ISP. The server's queue was filling and packets were being discarded left and right. Basically I was getting randomly selected packets from the stream. The server TCPs were not behaving well -- either they weren't doing good congestion avoidance and backoff, or the traffic loss was so variable that the server TCP just couldn't make sense out of the acks it was getting from me. (once I saw what was happening, I reduced the number of simultaneous connections to 2 and goodput went up to about 2.5KB). So, if these packets were IP fragments rather than individual TCP segments, the odds would be good that I would have received 0 complete TCP segments. You might say "One person, at home, doing web browsing, does not a network problem make". My response is that there are a lot of people doing web browsing at home. If this is a common situation (I suspect it might be, though I have no evidence), then it does add up to a real network problem. This all said, I do not believe that an outright ban on fragmentation by routers is appropriate. I also believe that hosts should use path MTU discovery and be the primary ones responsible for fragmentation, and routers do it only as a "measure of last resort". The only way I can think of to enforce this behavior is to observe that when routers have to fragment packets their performance drops (it takes more instructions/cycles to fragment a packet than not to), so the throughput of the network will drop if/when a host sends packets that need to be fragmented. >If fragmentation loss begins to be a problem, there are ways to try to >adapt in software. Maybe the transmit congestion control mechanisms >can be modified to detect fragment loss. Arguably, this could be done. But it seems to me that having two layers do congestion control, loss detection, etc, etc, is a bad architectural choice. Even having IP and TCP both slice up large blocks of data into smaller blocks (fragmentation and segmentation respectively) is a bad idea, but because of the dynamic nature of routing, having IP do it as a measure of last resort is probably not unreasonable (since the alternative is to drop a packet, possibly sending a 'too big' message, and causing tcp backoffs when the backoff isn't necessary). >In any case, IPv6 permits host fragmentation. I can certainly >think of scenarios where host fragmentation causes problems >that are solved by network fragmentation (not to mention my >web server that gets 30% more performance with network >fragmentation than with segmentation or host fragmentation). >Why permit host fragmentation and forbid network fragmentation? > >Suppose near the transmitter there is an underpowered (non-wirespeed >router that can't keep up with data being received) when the packets >are small on a large MTU medium. That's sort of like putting a Rolls Royce Merlin engine in a Cessna 172 airframe and then whining that whenever you start the engine, the torque flips the plane over onto its back. In other words, if performance is that critical to the application, you have to engineer the whole system (by system I mean the transmitter, the routers, the media, the paths, etc, etc) to meet the goals. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 24 07:09:16 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA01448 for ipng-dist; Thu, 24 Sep 1998 07:01:35 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA01441 for ; Thu, 24 Sep 1998 07:01:23 -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 HAA02167 for ; Thu, 24 Sep 1998 07:01:19 -0700 Received: from shultz.argon.com (shultz.argon.com [208.234.161.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA14074 for ; Thu, 24 Sep 1998 07:01:22 -0700 (PDT) Received: from hochstetter (hochstetter.argon.com [208.234.161.53]) by shultz.argon.com (8.8.6/8.8.6) with SMTP id KAA14317 for ; Thu, 24 Sep 1998 10:01:21 -0400 (EDT) Message-Id: <3.0.3.32.19980924100348.0093ca10@shultz.argon.com> X-Sender: kasten@shultz.argon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 24 Sep 1998 10:03:48 -0400 To: ipng@sunroof.eng.sun.com From: Frank Kastenholz Subject: (IPng 6518) Re: Host Fragmentation In-Reply-To: <27e927f0.360a4135@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 08:55 AM 9/24/98 EDT, Volsinians@aol.com wrote: > >I have the perhaps mistaken impression that ATM systems typically do >not have a lot of queuing built into them and that the designers of >ATM were targeting problems like streaming video. ATM will and does queue. Whether a given cell is queued or not, and how much it's queued, depends on the traffic class and parameters of the cell's VC and the load. For example, CBR traffic tends to be very sensitive to delay, so will tend to have short queues, while UBR or ABR is not so sensitive so it can build up queues (of course, how large the queue gets depends on how much memory is in the switch). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 24 07:30:39 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA01513 for ipng-dist; Thu, 24 Sep 1998 07:27:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA01506 for ; Thu, 24 Sep 1998 07:26: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 HAA08843 for ; Thu, 24 Sep 1998 07:26:49 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA28400 for ; Thu, 24 Sep 1998 07:26:49 -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 KAA02108; Thu, 24 Sep 1998 10:26:45 -0400 (EDT) Message-Id: <199809241426.KAA02108@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6519) I-D ACTION:draft-ietf-ipngwg-scoped-routing-00.txt Date: Thu, 24 Sep 1998 10:26:44 -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 : Routing of Scoped Addresses in the Internet Protocol Version 6 (IPv6) Author(s) : B. Haberman Filename : draft-ietf-ipngwg-scoped-routing-00.txt Pages : 7 Date : 22-Sep-98 This document outlines a mechanism for generating routing tables that include scoped IPv6 addresses. It defines a set of rules for routers to implement in order to forward scoped unicast and multicast addresses regardless of the routing protocol. It should be noted that these rules will apply to all scoped addresses. 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-scoped-routing-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-scoped-routing-00.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-scoped-routing-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980923144350.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-scoped-routing-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-scoped-routing-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980923144350.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 24 09:27:22 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA01655 for ipng-dist; Thu, 24 Sep 1998 09:22:09 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA01648 for ; Thu, 24 Sep 1998 09:21:55 -0700 (PDT) From: Volsinians@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 JAA09018 for ; Thu, 24 Sep 1998 09:21:53 -0700 Received: from imo23.mx.aol.com (imo23.mx.aol.com [198.81.17.67]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA13643 for ; Thu, 24 Sep 1998 09:21:53 -0700 (PDT) Received: from Volsinians@aol.com by imo23.mx.aol.com (IMOv16.10) id KIFDa02329; Thu, 24 Sep 1998 12:21:02 -0400 (EDT) Message-ID: <99a771f0.360a716e@aol.com> Date: Thu, 24 Sep 1998 12:21:02 EDT To: JimFleming@unety.net, lindberg@cdg.chalmers.se, ipng@sunroof.eng.sun.com Cc: martillo@chem2.harvard.edu Mime-Version: 1.0 Subject: (IPng 6520) Re: Another Terrible Mistake or Another Terrific Move ? 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 9/24/98 9:40:52 AM Eastern Daylight Time, JimFleming@unety.net writes: > -----Original Message----- > From: Volsinians@aol.com > > >Why permit host fragmentation and forbid network fragmentation? > IPv6 was designed by people that openly write in their > documents and books that they think ATM is.... > "Another Terrible Mistake" ATM is just another medium. It supplies cell switching. It does not itself provide the store and forward statistically multiplexed packet switching that internet technology provides. So what? Circuit switching also does not provide the store and forward statistically multiplexed packet switching that internetworking provides. Computer networking engineers build packet switching on top of the medium. Right now on the WAN side that medium is commonly circuit switched. In the future on the WAN side, cell switched media may play an important role. The nature of the underlying medium is relatively unimportant, and we should not care. Our clients or employers pay us to provide the store and forward statistically multiplexed packet switched internetwork. We simply must be reasonably clever to provide our customers the biggest bang for their buck. If some people do not want to do this because they have some religious objection to cell switching, why are they taking part in the Internet *Engineering* Task Force? > An IPv6 header is typically 40 bytes. An ATM cell payload is 48 bytes. > There is not a lot of room to do anything useful. Some people see > that as a "feature" or benefit of IPv6. Some also see the fragmentation > design as a feature and Another Terrific Move (ATM) of IPv6 designers. That ridiculous Mogul paper argues that intranetwork fragmentation is generally good. Guess what? If one uses a NAT device to connect to the Internet, one could -- assuming the NAT device is capable -- configure the NAT device to reassemble fragments into a complete packet. In one fell swoop, internetwork fragmentation, which is evil, is converted to intranetwork fragmentation, which is good. If the designers of IPv6 were willing to let network designers do their job, IPv6 designers would make the decision to allow network fragmention to be the choice of the network designer. Then, those of us that wish to build high performance high throughput networks could turn on network fragmentation, while those that have religious objections could limp along with their network fragment free networks, which will of course still be carrying host fragments. > The typical IPv8 (and IPv16) header is 20 bytes. It was designed to be > ATM-friendly. Some people view IPv8 as Another Terrible Mistake and > others view it as Another Terrific Move. Since IPv8 is basically a rework > of IPv4, it is hard to imagine how it could be such a big mistake since > IPv4 has served people well for several years. Despite that, the debates > will continue...ATM or ATM...?...that is the question... Whatever one's opinion of which protocol is Another Terrible Mistake, I think we should all agree that basing design decisions for the protocol of the future on the Mogul paper, which describes the limitations of the hardware and software of the past, is outrageously silly. 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 Thu Sep 24 14:27:14 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA02027 for ipng-dist; Thu, 24 Sep 1998 14:20:38 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA02020 for ; Thu, 24 Sep 1998 14:20:17 -0700 (PDT) From: Volsinians@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 OAA11551 for ; Thu, 24 Sep 1998 14:20:13 -0700 Received: from imo20.mx.aol.com (imo20.mx.aol.com [198.81.17.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA01759 for ; Thu, 24 Sep 1998 14:20:14 -0700 (PDT) Received: from Volsinians@aol.com by imo20.mx.aol.com (IMOv16.10) id GCKYa03786; Thu, 24 Sep 1998 17:19:30 -0400 (EDT) Message-ID: <245541e6.360ab762@aol.com> Date: Thu, 24 Sep 1998 17:19:30 EDT To: kasten@argon.com, ipng@sunroof.eng.sun.com Cc: martillo@chem2.harvard.edu, http-wg@cuckoo.hpl.hp.com, Jim Gettys , Bodzia@aol.com, nadia@deas.harvard.edu Mime-Version: 1.0 Subject: (IPng 6521) Re: Packet Loss (was Re: Host Fragmentation 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 9/24/98 10:17:22 AM Eastern Daylight Time, kasten@argon.com writes: >At 08:28 AM 9/24/98 EDT, Volsinians@aol.com wrote: >>If someones provide some real data on today's network and reasoning >>that does not depend on the assumption of old-fashioned, poorly >>designed or misdesigned hardware and very old very buggy software, >>there would be some reason to pay attention to his analysis. Paying >>attention to the Mogul paper >>to design the protocol of the future is >>ludicrous. >Packet loss in today's network is a not insignificant problem. >About a year ago I was doing some web browsing from home >looking at some pages that had several moderate to large >pictures on them. While I have a 28.8 modem, I was getting >only a couple hundred bytes/second aggregate goodput >downloading the pages, much less than the 2-3KB >I should see (doing simple arithmetic). At first I >thought it was just some odd property of the compression >in the modem. Soon I notived that the aggregate goodput >was much higher for pages with only one or two pictures >than, say, 5 or 6. I turned on a packet tracer, downloaded >a page with several pictures and discovered some truly odd >packet reception patterns. Lots of retransmissions, occasionally >I'd get the same packet (by TCP sequence number) several times >back to back, etc, etc. >To make a long story short, the problem was that I had multiple TCP >connections open (one per image) and they all were imploding onto the >same dialup server at my ISP. The server's queue was filling and >packets were being discarded left and right. Basically I was getting >randomly selected packets from the stream. The server TCPs were not >behaving well -- either they weren't doing good congestion avoidance >and backoff, or the traffic loss was so variable that the server TCP >just couldn't make sense out of the acks it was getting from me. (once >I saw what was happening, I reduced the number of simultaneous >connections to 2 and goodput went up to about 2.5KB). >So, if these packets were IP fragments rather than individual TCP >segments, the odds would be good that I would have received 0 complete >TCP segments. Whenever something is retransmitted on the internet, users assume that the retransmission results from a lost packet. Under the assumption that all delays are a result of packet loss, a large file could never be sent across the network in less then a day:-> This example makes the argument for HTTP 1.1, not for path MTU discovery. I believe that a large piece of the problem seen in this example is related to the queuing delay from the network to PC over the 28k phone line. The observed problem is a result of limitation of the the TCP congestion control algorithm. This algorithm cannot deal effectively with multiple concurrent streams from or to a single host, for it is only connection oriented and not host oriented. As a result each connection queues at least one packet to the slow interface. Then, while the packets are waiting to be sent serially across the 28K connection, the TCP retransmit timer fires and the packet is sent again. It is possible that reducing the size of the packets by using only IP fragmentation instead of including the extra TCP headers might have made getting 3 streams possible rather than only 2. The observed phenomenon was certainly not a result of lost packets. This example underscores why The Critical Review of Internet Technology and Intranet Computing (The C.R.I.T.I.C) is useful and worthwhile for network administrators and designers as well as for packet switch implementers, for it provides analysis and tools to help understand this sort of situation. 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 Thu Sep 24 15:15:21 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA02090 for ipng-dist; Thu, 24 Sep 1998 15:08:55 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id PAA02083 for ; Thu, 24 Sep 1998 15:08:45 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id PAA26863; Thu, 24 Sep 1998 15:08:35 -0700 (PDT) Date: Thu, 24 Sep 1998 15:07:53 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6522) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199808141633.AA03110@wasted.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - Added defaults for multicast operations in section 5.2 and changed > the names from ADD to JOIN and DROP to LEAVE to be consistent with > IPv6 multicast terminology. > IPV6_JOIN_MEMBERSHIP | > IPV6_LEAVE_MEMBERSHIP | These names look odd - retaining the "membership" part of the name doesn't match with join/leave. Thus either keep the old names (add/drop_membership) or replace "membership" with "group" to get IPV6_JOIN_GROUP and IPV6_LEAVE_GROUP. (Sorry, I didn't see this before but I'm implementing these changes right now.) Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 24 15:42:16 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA02118 for ipng-dist; Thu, 24 Sep 1998 15:31:49 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA02111 for ; Thu, 24 Sep 1998 15:31: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 PAA01359 for ; Thu, 24 Sep 1998 15:31:33 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.9.1/8.9.1) with SMTP id PAA15015 for ; Thu, 24 Sep 1998 15:31:34 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA16264; Thu, 24 Sep 98 15:27:14 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id PAA07421; Thu, 24 Sep 1998 15:32:06 -0700 Date: Thu, 24 Sep 1998 15:32:06 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199809242232.PAA07421@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 6523) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt Cc: bound@zk3.dec.com, Erik.Nordmark@Eng X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > > > - Added defaults for multicast operations in section 5.2 and changed > > the names from ADD to JOIN and DROP to LEAVE to be consistent with > > IPv6 multicast terminology. > > > IPV6_JOIN_MEMBERSHIP | > > IPV6_LEAVE_MEMBERSHIP | > > These names look odd - retaining the "membership" part of the name > doesn't match with join/leave. > > Thus either keep the old names (add/drop_membership) or replace "membership" > with "group" to get IPV6_JOIN_GROUP and IPV6_LEAVE_GROUP. > > (Sorry, I didn't see this before but I'm implementing these changes right now.) I agree. I would prefer that we simply stick with the old style names, IPV6_ADD_MEMBERSHIP and IPV6_DROP_MEMBERSHIP. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 24 17:49:03 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA00311 for ipng-dist; Thu, 24 Sep 1998 17:36:49 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA00304 for ; Thu, 24 Sep 1998 17:36:39 -0700 (PDT) From: Volsinians@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 RAA10349 for ; Thu, 24 Sep 1998 17:36:37 -0700 Received: from imo28.mx.aol.com (imo28.mx.aol.com [198.81.17.72]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA20373 for ; Thu, 24 Sep 1998 17:36:39 -0700 (PDT) Received: from Volsinians@aol.com by imo28.mx.aol.com (IMOv16.10) id NAUQa02083; Thu, 24 Sep 1998 20:36:09 +2000 (EDT) Message-ID: Date: Thu, 24 Sep 1998 20:36:09 EDT To: ipng@sunroof.eng.sun.com Cc: http-wg@hplb.hpl.hp.com Mime-Version: 1.0 Subject: (IPng 6524) Re: Packet Loss (was Re: Host Fragmentation 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 9/24/98 10:17:22 AM Eastern Daylight Time, kasten@argon.com writes: >At 08:28 AM 9/24/98 EDT, Volsinians@aol.com wrote: >>If someones provide some real data on today's network and reasoning >>that does not depend on the assumption of old-fashioned, poorly >>designed or misdesigned hardware and very old very buggy software, >>there would be some reason to pay attention to his analysis. Paying >>attention to the Mogul paper >>to design the protocol of the future is >>ludicrous. >Packet loss in today's network is a not insignificant problem. >About a year ago I was doing some web browsing from home >looking at some pages that had several moderate to large >pictures on them. While I have a 28.8 modem, I was getting >only a couple hundred bytes/second aggregate goodput >downloading the pages, much less than the 2-3KB >I should see (doing simple arithmetic). At first I >thought it was just some odd property of the compression >in the modem. Soon I notived that the aggregate goodput >was much higher for pages with only one or two pictures >than, say, 5 or 6. I turned on a packet tracer, downloaded >a page with several pictures and discovered some truly odd >packet reception patterns. Lots of retransmissions, occasionally >I'd get the same packet (by TCP sequence number) several times >back to back, etc, etc. >To make a long story short, the problem was that I had multiple TCP >connections open (one per image) and they all were imploding onto the >same dialup server at my ISP. The server's queue was filling and >packets were being discarded left and right. Basically I was getting >randomly selected packets from the stream. The server TCPs were not >behaving well -- either they weren't doing good congestion avoidance >and backoff, or the traffic loss was so variable that the server TCP >just couldn't make sense out of the acks it was getting from me. (once >I saw what was happening, I reduced the number of simultaneous >connections to 2 and goodput went up to about 2.5KB). >So, if these packets were IP fragments rather than individual TCP >segments, the odds would be good that I would have received 0 complete >TCP segments. Whenever something is retransmitted on the internet, users assume that the retransmission results from a lost packet. Under the assumption that all delays are a result of packet loss, a large file could never be sent across the network in less then a day:-> This example makes the argument for HTTP 1.1, not for path MTU discovery. I believe that a large piece of the problem seen in this example is related to the queuing delay from the network to PC over the 28k phone line. The observed problem is a result of limitation of the the TCP congestion control algorithm. This algorithm cannot deal effectively with multiple concurrent streams from or to a single host, for it is only connection oriented and not host oriented. As a result each connection queues at least one packet to the slow interface. Then, while the packets are waiting to be sent serially across the 28K connection, the TCP retransmit timer fires and the packet is sent again. It is possible that reducing the size of the packets by using only IP fragmentation instead of including the extra TCP headers might have made getting 3 streams possible rather than only 2. The observed phenomenon was certainly not a result of lost packets. This example underscores why The Critical Review of Internet Technology and Intranet Computing (TheC.R.I.T.I.C) is useful and worthwhile for network administrators and designers as well as for packet switch implementers, for it provides analysis and tools to help understand this sort of situation. 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 Thu Sep 24 18:02:39 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA00335 for ipng-dist; Thu, 24 Sep 1998 17:51:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA00328 for ; Thu, 24 Sep 1998 17:51:07 -0700 (PDT) From: Volsinians@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 RAA13054 for ; Thu, 24 Sep 1998 17:51:05 -0700 Received: from imo17.mx.aol.com (imo17.mx.aol.com [198.81.17.7]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA26669 for ; Thu, 24 Sep 1998 17:51:06 -0700 (PDT) Received: from Volsinians@aol.com by imo17.mx.aol.com (IMOv16.10) id GUXQa10158; Thu, 24 Sep 1998 20:50:28 +2000 (EDT) Message-ID: <3499715.360ae8d4@aol.com> Date: Thu, 24 Sep 1998 20:50:28 EDT To: kasten@argon.com, ipng@sunroof.eng.sun.com Cc: martillo@chem2.harvard.edu Mime-Version: 1.0 Subject: (IPng 6525) Re: Packet Loss (was Re: Host Fragmentation 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 9/24/98 10:17:22 AM Eastern Daylight Time, kasten@argon.com writes: > >Suppose near the transmitter there is an underpowered (non-wirespeed > >router that can't keep up with data being received) when the packets > >are small on a large MTU medium. > That's sort of like putting a Rolls Royce Merlin engine in a Cessna > 172 airframe and then whining that whenever you start the engine, the > torque flips the plane over onto its back. Not a valid comparison. Who knows what sort of router might be used in some portion of the Internent to provide topological redundancy? In many configurations, the Cisco 7000 series routers are underpowered because of some serious design flaws. There are lots of Cisco 7000 series routers all over the Internet and as more powerful alternatives become available they are being moved to network edges or are being used to provide topological redundancy. In any case, I described the underpowered router scenario in order to point out that it is not hard to think of real internet situations where using TCP segmentation or host fragmentation can lead to packet loss while network fragmentation would not. > In other words, if performance is that critical to the application, > you have to engineer the whole system (by system I mean the transmitter, > the routers, the media, the paths, etc, etc) to meet the goals. Almost correct, in terms of the Internet, one engineers that portion of the system under one's control and provides mechanisms (like perhaps network fragmentation) for contingencies that may arise beyond one's control like the sudden kick in of a back up router that might be underpowered for the modifiable characteristics of the traffic that needs to be switched. 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 Sep 25 01:10:23 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id AAA00524 for ipng-dist; Fri, 25 Sep 1998 00:59:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id AAA00517 for ; Fri, 25 Sep 1998 00:59: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 AAA07359 for ; Fri, 25 Sep 1998 00:59:26 -0700 Received: from wentzl.cdg.chalmers.se (wentzl.cdg.chalmers.se [129.16.12.9]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id AAA23647 for ; Fri, 25 Sep 1998 00:59:28 -0700 (PDT) Received: from wilfer1.cdg.chalmers.se (fK0JV6ucRBVXj2ex6GtBLvQcPw3qpXgz@wilfer1.cdg.chalmers.se [129.16.12.11]) by wentzl.cdg.chalmers.se (8.8.8/8.8.8) with ESMTP id JAA28535; Fri, 25 Sep 1998 09:59:27 +0200 (MET DST) From: Gunnar Lindberg Received: (from lindberg@localhost) by wilfer1.cdg.chalmers.se (8.8.8/8.8.8) id JAA09454; Fri, 25 Sep 1998 09:59:25 +0200 (MET DST) Date: Fri, 25 Sep 1998 09:59:25 +0200 (MET DST) Message-Id: <199809250759.JAA09454@wilfer1.cdg.chalmers.se> To: Volsinians@aol.com, ipng@sunroof.eng.sun.com Subject: (IPng 6526) Re: Packet Loss (was Re: Host Fragmentation X-Mailer: UCB Mail 5.3.10 1998-06-04 (MIME) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm afraid it remains a fact of the Internet that if an IP fragment gets dropped: a) The packet cannot be reassembled by the recipient host and b) the rest of the fragments move on and keep filling the links. And, since IP packets/fragments may move along different paths, we cannot even do the "horrible ATM-like PPD/EPD trick". Then, whether or not this is a PROBLEM may and can be argued and discussed in lengthy pieces of email. My personal take is that b) is a disaster - it can give you 100% utilized links and 0% goodput AND it is likely to appear when your network is pushed near its limit. Whether this happens because up- stream links are overloaded or its the Cessna 172 router who drops packets from the Proteon interface is less important - when it happens goodput rapidly drops. It can also be argued whether the cure is better than the disease, whether the added complexity in Path MTU Discovery really pays off by avoiding b). Maybe some other problem takes over. Since the SW industry (e.g. Sun/Solaris) has put MTU Discovery into IPv4, one would assume that someone has actually looked into live Internet traffic and/or made realistic simulations. References from those people would be really useful and probably terminate this thread. Gunnar Lindberg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 25 07:31:11 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA00732 for ipng-dist; Fri, 25 Sep 1998 07:26:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA00725 for ; Fri, 25 Sep 1998 07:25: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 HAA11574 for ; Fri, 25 Sep 1998 07:25:49 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA29435 for ; Fri, 25 Sep 1998 07:25:49 -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 KAA05935; Fri, 25 Sep 1998 10:25:44 -0400 (EDT) Message-Id: <199809251425.KAA05935@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6527) I-D ACTION:draft-ietf-ipngwg-icmp-v2-02.txt Date: Fri, 25 Sep 1998 10:25:44 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart Note: This revision reflects comments received during the last call period. 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 : Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-icmp-v2-02.txt Pages : 21 Date : 24-Sep-98 This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). 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-icmp-v2-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v2-02.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-icmp-v2-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980924171804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-v2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980924171804.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 25 11:04:43 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA01070 for ipng-dist; Fri, 25 Sep 1998 10:56:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA01063 for ; Fri, 25 Sep 1998 10:56: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 KAA20289; Fri, 25 Sep 1998 10:56:29 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA09771; Fri, 25 Sep 1998 10:56:25 -0700 (PDT) Received: from flume.zk3.dec.com (broflume.zk3.dec.com [16.141.0.42]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id NAA18416; Fri, 25 Sep 1998 13:56:17 -0400 (EDT) Received: from bwasted.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA08113; Fri, 25 Sep 1998 13:56:16 -0400 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id NAA0000001732; Fri, 25 Sep 1998 13:56:16 -0400 (EDT) From: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group Message-Id: <199809251756.NAA0000001732@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6529) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-Reply-To: Your message of "Thu, 24 Sep 1998 15:07:53 PDT." Date: Fri, 25 Sep 1998 13:56:16 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, >> - Added defaults for multicast operations in section 5.2 and changed >> the names from ADD to JOIN and DROP to LEAVE to be consistent with >> IPv6 multicast terminology. > >> IPV6_JOIN_MEMBERSHIP | >> IPV6_LEAVE_MEMBERSHIP | >These names look odd - retaining the "membership" part of the name >doesn't match with join/leave. > >Thus either keep the old names (add/drop_membership) or replace "membership" >with "group" to get IPV6_JOIN_GROUP and IPV6_LEAVE_GROUP. > >(Sorry, I didn't see this before but I'm implementing these changes right now.) Good catch. I will change the suffix to GROUP. You will see an updated spec any moment now just fixing some of the nroff stuff. 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 Fri Sep 25 11:28:16 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA01129 for ipng-dist; Fri, 25 Sep 1998 11:22:08 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA01122 for ; Fri, 25 Sep 1998 11: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 LAA00999 for ; Fri, 25 Sep 1998 11:21:49 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA26688 for ; Fri, 25 Sep 1998 11:21:44 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id LAA19563; Fri, 25 Sep 1998 11:21:43 -0700 (PDT) Message-Id: <3.0.5.32.19980925111252.00af4ce0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 25 Sep 1998 11:12:52 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6530) IPng Web Site Updated Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just completed an update to the IPng web site at: http://playground.sun.com/ipng The changes include new minutes, pointers to current specifications, implementations, etc. Corrections/additions to me. 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 Fri Sep 25 12:21:48 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA01211 for ipng-dist; Fri, 25 Sep 1998 12:15:58 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA01204 for ; Fri, 25 Sep 1998 12:15:45 -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 MAA16526 for ; Fri, 25 Sep 1998 12:15:41 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.9.1/8.9.1) with SMTP id MAA29962 for ; Fri, 25 Sep 1998 12:15:41 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA25560; Fri, 25 Sep 98 12:13:47 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id MAA08085; Fri, 25 Sep 1998 12:18:41 -0700 Date: Fri, 25 Sep 1998 12:18:41 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199809251918.MAA08085@feller.mentat.com> To: bound@wasted.zk3.dec.com Subject: (IPng 6532) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > >I agree. I would prefer that we simply stick with the old style names, > >IPV6_ADD_MEMBERSHIP and IPV6_DROP_MEMBERSHIP. > > What came in was that we should move the namespace to support > Multicast Listner Discovery (MLD) terminology which uses join and leave, as > did IGMPv2 too. So I am inclinded to use them that way per that input but > use GROUP. > > I am implementing this change too. It don't seem that painful and would > make the API consistent with MLD? But I agree it is a pain. > > )---------?????? > It was a preference, but not a strong one. If IPV6_JOIN_GROUP and IPV6_- LEAVE_GROUP seem more natural relative to MLD's terminology then I can live with it. If we make the change now then at least there is some hope that I won't have to leave the old definitions in place. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 25 12:22:02 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA01199 for ipng-dist; Fri, 25 Sep 1998 12:10:51 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA01192 for ; Fri, 25 Sep 1998 12:10: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 MAA15318 for ; Fri, 25 Sep 1998 12:10:29 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA26884 for ; Fri, 25 Sep 1998 12:10:30 -0700 (PDT) Received: from flume.zk3.dec.com (broflume.zk3.dec.com [16.141.0.42]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id PAA01206; Fri, 25 Sep 1998 15:10:22 -0400 (EDT) Received: from bwasted.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA19004; Fri, 25 Sep 1998 15:10:20 -0400 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id PAA0000013907; Fri, 25 Sep 1998 15:10:20 -0400 (EDT) From: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group Message-Id: <199809251910.PAA0000013907@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6531) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-Reply-To: Your message of "Thu, 24 Sep 1998 15:32:06 PDT." <199809242232.PAA07421@feller.mentat.com> Date: Fri, 25 Sep 1998 15:10:20 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, >I agree. I would prefer that we simply stick with the old style names, >IPV6_ADD_MEMBERSHIP and IPV6_DROP_MEMBERSHIP. What came in was that we should move the namespace to support Multicast Listner Discovery (MLD) terminology which uses join and leave, as did IGMPv2 too. So I am inclinded to use them that way per that input but use GROUP. I am implementing this change too. It don't seem that painful and would make the API consistent with MLD? But I agree it is a pain. )---------?????? 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 Sat Sep 26 07:44:43 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA02020 for ipng-dist; Sat, 26 Sep 1998 07:37:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA02013 for ; Sat, 26 Sep 1998 07:37:17 -0700 (PDT) From: Volsinians@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 HAA00103 for ; Sat, 26 Sep 1998 07:37:15 -0700 Received: from imo25.mx.aol.com (imo25.mx.aol.com [198.81.17.69]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA18171 for ; Sat, 26 Sep 1998 07:37:16 -0700 (PDT) Received: from Volsinians@aol.com by imo25.mx.aol.com (IMOv16.10) id NXAAa02316; Sat, 26 Sep 1998 10:36:46 -0400 (EDT) Message-ID: Date: Sat, 26 Sep 1998 10:36:46 EDT To: ipng@sunroof.eng.sun.com Cc: Volsinians@aol.com, rstevens@kohala.com, Harald.Alvestrand@maxware.no, Bodzia@aol.com Mime-Version: 1.0 Subject: (IPng 6533) Re: Host Fragmentation 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 Harald.Alvestrand@maxware.no writes: > At 17:30 16.09.98 -0700, Wayne Hathaway wrote: > >And about fragment loss, nobody can expect to get top performance > >over a lossy net > PLEEEEEEEEEEEEEASE: Back to basics: > 1) All IP networks have TCP traffic. > 2) TCP's rate adjustment is based on losing packets. See RFC 2001. > 3) Therefore, ALL networks with TCP traffic on them lose packets. > Repeat until understood: > ALL IP NETWORKS LOSE PACKETS. I read the RFC. Unlike that ridiculous Mogul paper, there is nothing really wrong with it except that the abstract calls the *procedures* described a protocol(*). Here is a discussion of dropping due to memory starvation. Old TCPs would start a connection with the sender injecting multiple segments into the network, up to the window size advertised by the receiver. While this is OK when the two hosts are on the same LAN, if there are routers and slower links between the sender and the receiver, problems can arise. Some intermediate router must queue the packets, and it's possible for that router to run out of space. The situation described above was true at the time the research for that ridiculous Mogul paper was performed, but today memory is far less costly. With a properly engineered communications subnet, temporary demands for bandwidth greater than link speed should exceed available queue space only extremely rarely. (Frequent sustained demands for bandwidth in excess of link speed indicate poor traffic engineering.) To wit, I believe that the Alteon switch can provide a half megabyte of buffering per port. The standard Intel architecture Freeware/Shareware VLAN Router can run with an order of a gigabyte of memory available for buffering. The Alpha-based Subscriber VLAN Router can run with 20 gigabytes or more of memory available for buffering. The author of the contribution to which I am replying must repeat until it is understood: MEMORY FOR PACKET BUFFERING IS PLENTIFUL! Worrying about routers that run out of space for received packets in internets/intranets that have been properly traffic engineered is inappropriate with today's technology. Here is the the paragraph that discusses loss of packets. The assumption of the algorithm is that packet loss caused by damage is very small (much less than 1%), therefore the loss of a packet signals congestion somewhere in the network between the source and destination. There are two indications of packet loss: a timeout occurring and the receipt of duplicate ACKs. Neither the first nor the last sentence is not exactly correct. The first sentence suggests that packet loss results mainly from damaged packets or from congestion. In fact, topological instabilities (especially in large-bandwidth backbones constructed with Cisco routers -- a very common situation) are probably far more frequently the major causes packet loss. As for the second case, the overwhelming majority of the cases for today's Internet, timeouts simply indicate delay (**) in the arrival of the ACK. Delays in the reception of the ACK occur because it takes a finite time for any packet to get from its transmitter to the target receiver. The following non-exhaustive list describes some of the causes of delay. 1) Buffering due to congestion can cause delay *with no packet loss*. 2) Use of satellite links can introduce delay *with no packet loss*. 3) A sophisticated switch router like the VLAN Router can detect temporary MAC layer topological instabilities that are often not easily detectable by network layer routing and buffer packets *with no packet loss* until the instability passes. As for duplicate ACKs, these usually indicate delays *with no packet loss* as in the following scenario. 1) A packet is sent from the transmitter, 2) For some reason the packet is delayed getting to the receiver, 3) A subsequent packet is sent form the transmitter, 4) The ack on the first packet times out so that it is resent, 5) All three packets arrive at the receiver *with no packet loss* in the order transmitted. 6) The receiver may send a duplicate ACK to make sure that both the transmitter and receiver are synchronized. > How many packets they lose depends on the traffic load and the number > of TCP connections, and the presence of non-adaptive traffic. > But the ONLY IP network that doesn't lose packets is one where the > packet senders are not able to utilize the bandwidth. Damaged packets and topological instability aside, the comment is certainly not true. > I know that, you know that, we all know that. > The question is NOT whether or not we'll lose parts of fragmented > IP packets. It is HOW MANY. This sort of misunderstanding as well as the misinterpretation of 28K modem situation previously discussed are good arguments for keeping The Critical Review of Internet Technology and Intranet Computing (The C.R.I.T.I.C) handy. I also recommend The Freeware/Shareware VLAN Router to researchers (on tight budgets) that wish to investigate with more verisimilitude the behavior of real internets that use modern technology and turnkey packet switches. (I am making available by Monday at the Telford Tools Website a version that simplifies installation). These integrated L2/L3 WAN LAN multiprotocol switch routers do not duplicate flaws of Cisco routers, but a network built with these devices is a lot more realistic for simulation than a network using Linux (or some other Unix variant) running GATED. Joachim Martillo Telford Tools, Inc. (*)This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. (**) Steven's observation with regard to timeouts would be more applicable to an Internet using the old broken hardware and software described in that ridiculous Mogul paper. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Sep 26 18:09:14 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA02324 for ipng-dist; Sat, 26 Sep 1998 17:59:04 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA02317 for ; Sat, 26 Sep 1998 17:58:41 -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 RAA08782 for ; Sat, 26 Sep 1998 17:58:40 -0700 Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA07389 for ; Sat, 26 Sep 1998 17:58:41 -0700 (PDT) Received: from lana-2.trumpet.com.au (lana-2.trumpet.com.au [203.5.119.82]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id KAA22687; Sun, 27 Sep 1998 10:58:37 +1000 (EST) (envelope-from pete@trumpet.com.au) To: ipng@sunroof.eng.sun.com From: pete@trumpet.com.au (Peter R. Tattam) Subject: (IPng 6535) Re: Host Fragmentation Date: Sun, 27 Sep 1998 11:03:55 +1100 cc: Volsinians@aol.com, rstevens@kohala.com, Harald.Alvestrand@maxware.no Message-ID: <3bv1jt2$1mp@lana-2.trumpet.com.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article Volsinians@aol.com writes: >From: Volsinians@aol.com >Date: Sat, 26 Sep 1998 10:36:46 EDT Sorry to say, I totally disagree with your general comments. As a TCP stack implementor, I find that fragmentation is one of the most irritating aspects of the implementation. The cost of handling fragmentation efficiently is quite high, both in terms of implementation cost and also in terms of memory allocation. Many stacks operate at a kernel layer and thus to be reasonable and not steal too much of kernel ram space (which often has to be in non pageable memory). It is also a large risk for denial of service since it is a trivial matter to construct packets which will rapidly starve an implementation of all available fragmentation buffer space. To prevent this attack, my technique is to run two independent heaps, one for regular packets and one for fragmented packets. Still, with a 30 sec timeout for fragmented packets, *quite* a lot of damage can be done. Experience has also shown that most of the TCP stack killer attacks centre around poor implementations of fragmentation. e.g. the teardrop attacks. It's about time the computing industry took a good hard look at the attitudes that say, "let's just throw more RAM or more CPU or more DISK at the problem till it's fixed." Big is not always beautiful. I get concerned when I do a RAM utilization on a Win95 machine and find sometimes that almost half the RAM is allocated to system non-pageable memory. Also don't forget that IP6 is being touted for many low memory devices. You have to take into account the small end of the spectrum too. Peter >To: ipng@sunroof.Eng.Sun.COM >Cc: Volsinians@aol.com, rstevens@kohala.com, Harald.Alvestrand@maxware.no, >Subject: (IPng 6533) Re: Host Fragmentation >Harald.Alvestrand@maxware.no writes: >> At 17:30 16.09.98 -0700, Wayne Hathaway wrote: >> >And about fragment loss, nobody can expect to get top performance >> >over a lossy net >> PLEEEEEEEEEEEEEASE: Back to basics: >> 1) All IP networks have TCP traffic. >> 2) TCP's rate adjustment is based on losing packets. See RFC 2001. >> 3) Therefore, ALL networks with TCP traffic on them lose packets. > >> Repeat until understood: > >> ALL IP NETWORKS LOSE PACKETS. >I read the RFC. Unlike >that ridiculous >Mogul paper, >there is nothing really wrong with it except that the abstract calls >the *procedures* described a protocol(*). >Here is a discussion of dropping due to memory starvation. > Old TCPs would start a connection with the sender injecting multiple > segments into the network, up to the window size advertised by the > receiver. While this is OK when the two hosts are on the same LAN, > if there are routers and slower links between the sender and the > receiver, problems can arise. Some intermediate router must queue > the packets, and it's possible for that router to run out of space. >The situation described above was true at the time the research for >that ridiculous >Mogul paper >was performed, but today memory is far less costly. With a properly >engineered communications subnet, temporary demands for bandwidth >greater than link speed should exceed available queue space only >extremely rarely. (Frequent sustained demands for bandwidth in excess >of link speed indicate poor traffic engineering.) >To wit, I believe that the Alteon switch can provide a half megabyte >of buffering per port. The standard Intel architecture > >Freeware/Shareware VLAN Router >can run with an order of a gigabyte of >memory available for buffering. The Alpha-based Subscriber VLAN >Router can run with 20 gigabytes or more of memory available for >buffering. The author of the contribution to which I am replying >must repeat until it is understood: > MEMORY FOR PACKET BUFFERING IS PLENTIFUL! >Worrying about routers that run out of space for received packets in >internets/intranets that have been properly traffic engineered is >inappropriate with today's technology. >Here is the the paragraph that discusses loss of packets. > The assumption of the algorithm is that packet loss caused by damage > is very small (much less than 1%), therefore the loss of a packet > signals congestion somewhere in the network between the source and > destination. There are two indications of packet loss: a timeout > occurring and the receipt of duplicate ACKs. >Neither the first nor the last sentence is not exactly correct. >The first sentence suggests that packet loss results mainly from >damaged packets or from congestion. In fact, topological >instabilities (especially in large-bandwidth backbones constructed >with Cisco routers -- a very common situation) are probably far more >frequently the major causes packet loss. >As for the second case, the overwhelming majority of the cases for >today's Internet, timeouts simply indicate delay (**) in the arrival >of the ACK. Delays in the reception of the ACK occur because it takes >a finite time for any packet to get from its transmitter to the target >receiver. >The following non-exhaustive list describes some of the causes of >delay. >1) Buffering due to congestion can cause delay *with no packet loss*. >2) Use of satellite links can introduce delay *with no packet loss*. >3) A sophisticated >switch router >like the VLAN Router can detect >temporary MAC layer topological instabilities that are often not easily >detectable by network layer routing and buffer packets *with no packet >loss* until the instability passes. >As for duplicate ACKs, these usually indicate delays *with no packet >loss* as in the following scenario. >1) A packet is sent from the transmitter, >2) For some reason the packet is delayed getting to the receiver, >3) A subsequent packet is sent form the transmitter, >4) The ack on the first packet times out so that it is resent, >5) All three packets arrive at the receiver *with no packet loss* in >the order transmitted. >6) The receiver may send a duplicate ACK to make sure that both the >transmitter and receiver are synchronized. >> How many packets they lose depends on the traffic load and the number >> of TCP connections, and the presence of non-adaptive traffic. >> But the ONLY IP network that doesn't lose packets is one where the >> packet senders are not able to utilize the bandwidth. >Damaged packets and topological instability aside, the comment is >certainly not true. >> I know that, you know that, we all know that. >> The question is NOT whether or not we'll lose parts of fragmented >> IP packets. It is HOW MANY. >This sort of misunderstanding as well as the misinterpretation of 28K >modem situation previously discussed are good arguments for keeping >The Critical Review of >Internet Technology and Intranet Computing >(The C.R.I.T.I.C) >handy. >I also recommend >The Freeware/Shareware VLAN >Router >to researchers (on tight budgets) that wish to investigate with more >verisimilitude the behavior of real internets that use modern >technology and turnkey packet switches. (I am making available by >Monday at the Telford Tools Website a version that simplifies >installation). These integrated L2/L3 WAN LAN multiprotocol switch routers >do not duplicate flaws of Cisco routers, but a network built >with these devices is a lot more realistic for simulation than a >network using Linux (or some other Unix variant) running GATED. >Joachim Martillo >Telford Tools, Inc. >(*)This document specifies an Internet standards track protocol for the > Internet community, and requests discussion and suggestions for > improvements. Please refer to the current edition of the "Internet > Official Protocol Standards" (STD 1) for the standardization state > and status of this protocol. Distribution of this memo is unlimited. >(**) Steven's observation with regard to timeouts would be more >applicable to an Internet using the old broken hardware and software >described in >that ridiculous >Mogul paper. >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Sep 26 18:44:53 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id SAA02361 for ipng-dist; Sat, 26 Sep 1998 18:33:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id SAA02354 for ; Sat, 26 Sep 1998 18:32: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 SAA10322 for ; Sat, 26 Sep 1998 18:32:50 -0700 Received: from mail-oak-1.pilot.net (mail-oak-1.pilot.net [198.232.147.16]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA13052 for ; Sat, 26 Sep 1998 18:32:53 -0700 (PDT) Received: from msd-gw.hitachi.com (msd.hitachi.com [137.168.1.1]) by mail-oak-1.pilot.net with ESMTP id SAA21539; Sat, 26 Sep 1998 18:32:35 -0700 (PDT) Received: from hicam-msd.hitachi.com (thunder [137.168.16.3]) by msd-gw.hitachi.com with ESMTP id SAA17930; Sat, 26 Sep 1998 18:31:27 -0700 (PDT) Received: from hw20.hitachi.com (hw20 [192.48.128.101]) by hicam-msd.hitachi.com with SMTP id SAA06977; Sat, 26 Sep 1998 18:30:51 -0700 (PDT) Received: from hw20 by hw20.hitachi.com (SMI-8.6/SMI-SVR4) id SAA06693; Sat, 26 Sep 1998 18:29:41 -0700 Message-Id: <199809270129.SAA06693@hw20.hitachi.com> Date: Sat, 26 Sep 1998 18:29:40 -0700 (PDT) From: Thomas Dineen Reply-To: Thomas Dineen Subject: (IPng 6536) Re: Host Fragmentation To: ipng@sunroof.eng.sun.com, pete@trumpet.com.au Cc: Volsinians@aol.com, rstevens@kohala.com, Harald.Alvestrand@maxware.no MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vPEzhKIU/Yp8OgUuZ571eQ== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter: I totally agree with your article. I believe that dropping router fragmentation from IPv6 was a seldom seen vote for engineering practiallly. Thomas Dineen >> >> In article Volsinians@aol.com writes: >> >From: Volsinians@aol.com >> >Date: Sat, 26 Sep 1998 10:36:46 EDT >> >> Sorry to say, I totally disagree with your general comments. As a TCP stack >> implementor, I find that fragmentation is one of the most irritating aspects >> of the implementation. The cost of handling fragmentation efficiently is >> quite high, both in terms of implementation cost and also in terms of memory >> allocation. Many stacks operate at a kernel layer and thus to be reasonable >> and not steal too much of kernel ram space (which often has to be in non >> pageable memory). >> >> It is also a large risk for denial of service since it is a trivial matter to >> construct packets which will rapidly starve an implementation of all available >> fragmentation buffer space. To prevent this attack, my technique is >> to run two independent heaps, one for regular packets and one for >> fragmented packets. Still, with a 30 sec timeout for fragmented packets, >> *quite* a lot of damage can be done. Experience has also shown that most of >> the TCP stack killer attacks centre around poor implementations of >> fragmentation. e.g. the teardrop attacks. >> >> It's about time the computing industry took a good hard look at the attitudes >> that say, "let's just throw more RAM or more CPU or more DISK at the problem >> till it's fixed." Big is not always beautiful. I get concerned when I do a >> RAM utilization on a Win95 machine and find sometimes that almost half >> the RAM is allocated to system non-pageable memory. Also don't forget that >> IP6 is being touted for many low memory devices. You have to take into >> account the small end of the spectrum too. >> >> Peter >> >> >> >To: ipng@sunroof.Eng.Sun.COM >> >Cc: Volsinians@aol.com, rstevens@kohala.com, Harald.Alvestrand@maxware.no, >> >Subject: (IPng 6533) Re: Host Fragmentation >> >> >Harald.Alvestrand@maxware.no writes: >> >> >> At 17:30 16.09.98 -0700, Wayne Hathaway wrote: >> >> >> >And about fragment loss, nobody can expect to get top performance >> >> >over a lossy net >> >> >> PLEEEEEEEEEEEEEASE: Back to basics: >> >> >> 1) All IP networks have TCP traffic. >> >> 2) TCP's rate adjustment is based on losing packets. See RFC 2001. >> >> 3) Therefore, ALL networks with TCP traffic on them lose packets. >> > >> >> Repeat until understood: >> > >> >> ALL IP NETWORKS LOSE PACKETS. >> >> >I read the RFC. Unlike >> >that ridiculous >> >Mogul paper, >> >there is nothing really wrong with it except that the abstract calls >> >the *procedures* described a protocol(*). >> >> >Here is a discussion of dropping due to memory starvation. >> >> > Old TCPs would start a connection with the sender injecting multiple >> > segments into the network, up to the window size advertised by the >> > receiver. While this is OK when the two hosts are on the same LAN, >> > if there are routers and slower links between the sender and the >> > receiver, problems can arise. Some intermediate router must queue >> > the packets, and it's possible for that router to run out of space. >> >> >The situation described above was true at the time the research for >> >that ridiculous >> >Mogul paper >> >was performed, but today memory is far less costly. With a properly >> >engineered communications subnet, temporary demands for bandwidth >> >greater than link speed should exceed available queue space only >> >extremely rarely. (Frequent sustained demands for bandwidth in excess >> >of link speed indicate poor traffic engineering.) >> >> >To wit, I believe that the Alteon switch can provide a half megabyte >> >of buffering per port. The standard Intel architecture >> > >> >Freeware/Shareware VLAN Router >> >can run with an order of a gigabyte of >> >memory available for buffering. The Alpha-based Subscriber VLAN >> >Router can run with 20 gigabytes or more of memory available for >> >buffering. The author of the contribution to which I am replying >> >must repeat until it is understood: >> >> > MEMORY FOR PACKET BUFFERING IS PLENTIFUL! >> >> >Worrying about routers that run out of space for received packets in >> >internets/intranets that have been properly traffic engineered is >> >inappropriate with today's technology. >> >> >Here is the the paragraph that discusses loss of packets. >> >> > The assumption of the algorithm is that packet loss caused by damage >> > is very small (much less than 1%), therefore the loss of a packet >> > signals congestion somewhere in the network between the source and >> > destination. There are two indications of packet loss: a timeout >> > occurring and the receipt of duplicate ACKs. >> >> >Neither the first nor the last sentence is not exactly correct. >> >> >The first sentence suggests that packet loss results mainly from >> >damaged packets or from congestion. In fact, topological >> >instabilities (especially in large-bandwidth backbones constructed >> >with Cisco routers -- a very common situation) are probably far more >> >frequently the major causes packet loss. >> >> >As for the second case, the overwhelming majority of the cases for >> >today's Internet, timeouts simply indicate delay (**) in the arrival >> >of the ACK. Delays in the reception of the ACK occur because it takes >> >a finite time for any packet to get from its transmitter to the target >> >receiver. >> >> >The following non-exhaustive list describes some of the causes of >> >delay. >> >> >1) Buffering due to congestion can cause delay *with no packet loss*. >> >> >2) Use of satellite links can introduce delay *with no packet loss*. >> >> >3) A sophisticated >> >switch router >> >like the VLAN Router can detect >> >temporary MAC layer topological instabilities that are often not easily >> >detectable by network layer routing and buffer packets *with no packet >> >loss* until the instability passes. >> >> >As for duplicate ACKs, these usually indicate delays *with no packet >> >loss* as in the following scenario. >> >> >1) A packet is sent from the transmitter, >> >> >2) For some reason the packet is delayed getting to the receiver, >> >> >3) A subsequent packet is sent form the transmitter, >> >> >4) The ack on the first packet times out so that it is resent, >> >> >5) All three packets arrive at the receiver *with no packet loss* in >> >the order transmitted. >> >> >6) The receiver may send a duplicate ACK to make sure that both the >> >transmitter and receiver are synchronized. >> >> >> How many packets they lose depends on the traffic load and the number >> >> of TCP connections, and the presence of non-adaptive traffic. >> >> But the ONLY IP network that doesn't lose packets is one where the >> >> packet senders are not able to utilize the bandwidth. >> >> >Damaged packets and topological instability aside, the comment is >> >certainly not true. >> >> >> I know that, you know that, we all know that. >> >> The question is NOT whether or not we'll lose parts of fragmented >> >> IP packets. It is HOW MANY. >> >> >This sort of misunderstanding as well as the misinterpretation of 28K >> >modem situation previously discussed are good arguments for keeping >> >The Critical Review of >> >Internet Technology and Intranet Computing >> >(The C.R.I.T.I.C) >> >handy. >> >> >I also recommend >> >The Freeware/Shareware VLAN >> >Router >> >to researchers (on tight budgets) that wish to investigate with more >> >verisimilitude the behavior of real internets that use modern >> >technology and turnkey packet switches. (I am making available by >> >Monday at the Telford Tools Website a version that simplifies >> >installation). These integrated L2/L3 WAN LAN multiprotocol switch routers >> >do not duplicate flaws of Cisco routers, but a network built >> >with these devices is a lot more realistic for simulation than a >> >network using Linux (or some other Unix variant) running GATED. >> >> >Joachim Martillo >> >Telford Tools, Inc. >> >> >(*)This document specifies an Internet standards track protocol for the >> > Internet community, and requests discussion and suggestions for >> > improvements. Please refer to the current edition of the "Internet >> > Official Protocol Standards" (STD 1) for the standardization state >> > and status of this protocol. Distribution of this memo is unlimited. >> >> >(**) Steven's observation with regard to timeouts would be more >> >applicable to an Internet using the old broken hardware and software >> >described in >> >that ridiculous >> >Mogul paper. >> >-------------------------------------------------------------------- >> >IETF IPng Working Group Mailing List >> >IPng Home Page: http://playground.sun.com/ipng >> >FTP archive: ftp://playground.sun.com/pub/ipng >> >Direct all administrative requests to majordomo@sunroof.eng.sun.com >> >-------------------------------------------------------------------- >> >> -------------------------------------------------------------------- >> IETF IPng Working Group Mailing List >> IPng Home Page: http://playground.sun.com/ipng >> FTP archive: ftp://playground.sun.com/pub/ipng >> Direct all administrative requests to majordomo@sunroof.eng.sun.com >> -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Sep 26 20:46:35 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id UAA02416 for ipng-dist; Sat, 26 Sep 1998 20:36:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id UAA02409 for ; Sat, 26 Sep 1998 20:36:13 -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 UAA16566 for ; Sat, 26 Sep 1998 20:36:12 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA03893 for ; Sat, 26 Sep 1998 20:36:13 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id XAA18920 for ; Sat, 26 Sep 1998 23:36:13 -0400 (EDT) Received: from bwasted.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA08381; Sat, 26 Sep 1998 23:36:12 -0400 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id XAA0000030193; Sat, 26 Sep 1998 23:36:12 -0400 (EDT) From: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group Message-Id: <199809270336.XAA0000030193@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: (IPng 6537) IPv6 Base API Doc 02a Ready to View Date: Sat, 26 Sep 1998 23:36:10 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Folks, Please find the updated Base API spec at (via anon ftp): sipper.pa-x.zk3.dec.com/pub/draft-ietf-ipngwg-bsd-api-new-02a.txt Note I labeled it suffix "02a" and after our review will submit it as new ID as suffix "02", which will incorporate all our changes since suffix 01. I removed the diffs for this version as all should know the changes pretty well by now and they were cluttering up the draft. See the Changes section for the particular changes at this time. Please send editorial comments to the authors and significant comments to the ipng wg list here. We would like to get all comments resolved by October 8th and then submit ID. Then we will ask the chairs to get this published as the Informational RFC replacement for RFC 2133. This gives us two weeks. This will then become a work item for International Standardization by The Open Group Network Working Group. Thank you for your support and hard work on this significant piece of work for IPv6. p.s. I have started the implementation changes per this draft as others on this list. /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 Sun Sep 27 16:46:21 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA02918 for ipng-dist; Sun, 27 Sep 1998 16:33:34 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA02911 for ; Sun, 27 Sep 1998 16:33:26 -0700 (PDT) From: Volsinians@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 QAA13271 for ; Sun, 27 Sep 1998 16:33:24 -0700 Received: from imo29.mx.aol.com (imo29.mx.aol.com [198.81.17.73]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA04630 for ; Sun, 27 Sep 1998 16:33:25 -0700 (PDT) Received: from Volsinians@aol.com by imo29.mx.aol.com (IMOv16.1) id GMSGa08736; Sun, 27 Sep 1998 19:33:05 -0400 (EDT) Message-ID: <8cb48e2c.360ecb31@aol.com> Date: Sun, 27 Sep 1998 19:33:05 EDT To: pete@trumpet.com.au, ipng@sunroof.eng.sun.com Cc: rstevens@kohala.com, Harald.Alvestrand@maxware.no Mime-Version: 1.0 Subject: (IPng 6539) Re: Host Fragmentation 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-09-26 21:32:19 EDT, pete@trumpet.com.au writes: >In article Volsinians@aol.com writes: >>From: Volsinians@aol.com >>Date: Sat, 26 Sep 1998 10:36:46 EDT >Sorry to say, I totally disagree with your general comments. As a TCP >stack implementor, I find that fragmentation is one of the most >irritating aspects of the implementation. The cost of handling >fragmentation efficiently is quite high, both in terms of >implementation cost and also in terms of memory allocation. Many >stacks operate at a kernel layer and thus to be reasonable and not >steal too much of kernel ram space (which often has to be in non >pageable memory). I am not sure how this comment justifies the banning of network fragmentation in the specification of IPv6. IPv6 *PERMITS* host fragmentation. The situation can be summarized as follows. We have a guy on island connected by a bridge to the mainland. At the mainland side of the bridge is a major transshipment point for goods. The guy on the island has a big sixteen wheeler and the bridge is in fact designed for big sixteen wheelers. Nevertheless because 100 years ago bridges could not bear the load of a sixteen wheeler or occasionally 100 years ago a few engineers misdesigned some bridges, we are going to make a law that he must hand-carry all of his goods accross that bridge. The analogy can be summarized as follows. The guy on the island is the massive web or file server connected by a gigabit link to the network fragmentation device which is the transshipment point. It makes a lot more sense to use the sixteen wheeler to carry goods across the bridge designed for the sixteen wheeler. >It is also a large risk for denial of service since it is a trivial >matter to construct packets which will rapidly starve an >implementation of all available fragmentation buffer space. To >prevent this attack, my technique is to run two independent heaps, one >for regular packets and one for fragmented packets. Still, with a 30 >sec timeout for fragmented packets, *quite* a lot of damage can be >done. Experience has also shown that most of the TCP stack killer >attacks centre around poor implementations of fragmentation. e.g. the >teardrop attacks. Again this comment is somewhat irrelevant because IPv6 *PERMITS* host fragmentation. But I do agree that some types of programming are harder than other types. It is easier to build systems with command line interfaces than to build systems with graphical windows based user interfaces. Windows based GUIs may occasion far more complex and subtle bugs than command line interfaces. Nevertheless the greater complexity and difficulty of windows based GUIs are not logical reasons to ban windows based GUIs. The foregoing analogy is not exactly perfect because IPv6 does not ban *all* fragmentation but rather just network fragmentation. In the more correct analogy, ISO would ban network transparent windows system based GUIs such as can be built with the X window system while permitting a MS Windows based GUI because MS Windows is not network transparent. >It's about time the computing industry took a good hard look at the >attitudes that say, "let's just throw more RAM or more CPU or more >DISK at the problem till it's fixed." Big is not always beautiful. I >get concerned when I do a RAM utilization on a Win95 machine and find >sometimes that almost half the RAM is allocated to system non-pageable >memory. Also don't forget that IP6 is being touted for many low >memory devices. You have to take into account the small end of the >spectrum too. Again this comment is sort of irrelevant because IPv6 *PERMITS* host fragmentation. In addition, low memory devices today are 32 MB or 64 MB. It is hard to find low density memory parts, and such parts would probably be expensive. Unless 32 MB counts as memory starved, it is probably too costly today to build memory starved embedded systems. If I were going to build some sort of memory starved embedded system, I would use IPv4. Addresses are smaller, headers are smaller, routing tables are smallers and minimum MAX MTU is smaller. It simply is not reasonable to argue that IPv6 somehow targets memory starved systems. I have to ask, "What is the real problem with forbidden network fragmentation from which permissible host fragmentation does not suffer?" If the ban on network fragmentation is removed, I think the only required change to the actual IPv6 protocol would be the addition of a NETWORK-DONT-FRAGMENT bit. Is there no place in the IPv6 header to add such a bit? Joachim Martillo Telford Tools, Inc. > > > >To: ipng@sunroof.Eng.Sun.COM > >Cc: Volsinians@aol.com, rstevens@kohala.com, Harald.Alvestrand@maxware.no, > >Subject: (IPng 6533) Re: Host Fragmentation > > >Harald.Alvestrand@maxware.no writes: > > >> At 17:30 16.09.98 -0700, Wayne Hathaway wrote: > > >> >And about fragment loss, nobody can expect to get top performance > >> >over a lossy net > > >> PLEEEEEEEEEEEEEASE: Back to basics: > > >> 1) All IP networks have TCP traffic. > >> 2) TCP's rate adjustment is based on losing packets. See RFC 2001. > >> 3) Therefore, ALL networks with TCP traffic on them lose packets. > > > >> Repeat until understood: > > > >> ALL IP NETWORKS LOSE PACKETS. > > >I read the RFC. Unlike > >that ridiculous > >Mogul paper, > >there is nothing really wrong with it except that the abstract calls > >the *procedures* described a protocol(*). > > >Here is a discussion of dropping due to memory starvation. > > > Old TCPs would start a connection with the sender injecting multiple > > segments into the network, up to the window size advertised by the > > receiver. While this is OK when the two hosts are on the same LAN, > > if there are routers and slower links between the sender and the > > receiver, problems can arise. Some intermediate router must queue > > the packets, and it's possible for that router to run out of space. > > >The situation described above was true at the time the research for > >that ridiculous > >Mogul paper > >was performed, but today memory is far less costly. With a properly > >engineered communications subnet, temporary demands for bandwidth > >greater than link speed should exceed available queue space only > >extremely rarely. (Frequent sustained demands for bandwidth in excess > >of link speed indicate poor traffic engineering.) > > >To wit, I believe that the Alteon switch can provide a half megabyte > >of buffering per port. The standard Intel architecture > > > >Freeware/Shareware VLAN Router > >can run with an order of a gigabyte of > >memory available for buffering. The Alpha-based Subscriber VLAN > >Router can run with 20 gigabytes or more of memory available for > >buffering. The author of the contribution to which I am replying > >must repeat until it is understood: > > > MEMORY FOR PACKET BUFFERING IS PLENTIFUL! > > >Worrying about routers that run out of space for received packets in > >internets/intranets that have been properly traffic engineered is > >inappropriate with today's technology. > > >Here is the the paragraph that discusses loss of packets. > > > The assumption of the algorithm is that packet loss caused by damage > > is very small (much less than 1%), therefore the loss of a packet > > signals congestion somewhere in the network between the source and > > destination. There are two indications of packet loss: a timeout > > occurring and the receipt of duplicate ACKs. > > >Neither the first nor the last sentence is not exactly correct. > > >The first sentence suggests that packet loss results mainly from > >damaged packets or from congestion. In fact, topological > >instabilities (especially in large-bandwidth backbones constructed > >with Cisco routers -- a very common situation) are probably far more > >frequently the major causes packet loss. > > >As for the second case, the overwhelming majority of the cases for > >today's Internet, timeouts simply indicate delay (**) in the arrival > >of the ACK. Delays in the reception of the ACK occur because it takes > >a finite time for any packet to get from its transmitter to the target > >receiver. > > >The following non-exhaustive list describes some of the causes of > >delay. > > >1) Buffering due to congestion can cause delay *with no packet loss*. > > >2) Use of satellite links can introduce delay *with no packet loss*. > > >3) A sophisticated > >switch router > >like the VLAN Router can detect > >temporary MAC layer topological instabilities that are often not easily > >detectable by network layer routing and buffer packets *with no packet > >loss* until the instability passes. > > >As for duplicate ACKs, these usually indicate delays *with no packet > >loss* as in the following scenario. > > >1) A packet is sent from the transmitter, > > >2) For some reason the packet is delayed getting to the receiver, > > >3) A subsequent packet is sent form the transmitter, > > >4) The ack on the first packet times out so that it is resent, > > >5) All three packets arrive at the receiver *with no packet loss* in > >the order transmitted. > > >6) The receiver may send a duplicate ACK to make sure that both the > >transmitter and receiver are synchronized. > > >> How many packets they lose depends on the traffic load and the number > >> of TCP connections, and the presence of non-adaptive traffic. > >> But the ONLY IP network that doesn't lose packets is one where the > >> packet senders are not able to utilize the bandwidth. > > >Damaged packets and topological instability aside, the comment is > >certainly not true. > > >> I know that, you know that, we all know that. > >> The question is NOT whether or not we'll lose parts of fragmented > >> IP packets. It is HOW MANY. > > >This sort of misunderstanding as well as the misinterpretation of 28K > >modem situation previously discussed are good arguments for keeping > >The Critical Review of > >Internet Technology and Intranet Computing > >(The C.R.I.T.I.C ) > >handy. > > >I also recommend > >The Freeware/Shareware VLAN > >Router > >to researchers (on tight budgets) that wish to investigate with more > >verisimilitude the behavior of real internets that use modern > >technology and turnkey packet switches. (I am making available by > >Monday at the Telford Tools Website a version that simplifies > >installation). These integrated L2/L3 WAN LAN multiprotocol switch routers > > >do not duplicate flaws of Cisco routers, but a network built > >with these devices is a lot more realistic for simulation than a > >network using Linux (or some other Unix variant) running GATED. > > >Joachim Martillo > >Telford Tools, Inc. > > >(*)This document specifies an Internet standards track protocol for the > > Internet community, and requests discussion and suggestions for > > improvements. Please refer to the current edition of the "Internet > > Official Protocol Standards" (STD 1) for the standardization state > > and status of this protocol. Distribution of this memo is unlimited. > > >(**) Steven's observation with regard to timeouts would be more > >applicable to an Internet using the old broken hardware and software > >described in > >that ridiculous > >Mogul paper. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 27 18:24:54 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id SAA03018 for ipng-dist; Sun, 27 Sep 1998 18:15:02 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id SAA03011 for ; Sun, 27 Sep 1998 18:14:54 -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 SAA19134 for ; Sun, 27 Sep 1998 18:14:53 -0700 Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA23623 for ; Sun, 27 Sep 1998 18:14:53 -0700 (PDT) Received: from jimmy.trumpet.com.au (jimmy.trumpet.com.au [203.5.119.2]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id LAA06499 for ; Mon, 28 Sep 1998 11:14:51 +1000 (EST) (envelope-from pete@trumpet.com.au) To: ipng@sunroof.eng.sun.com From: pete@trumpet.com.au (Peter R. Tattam) Subject: (IPng 6540) Re: Host Fragmentation Date: Mon, 28 Sep 1998 11:14:47 +1100 Message-ID: <3bva8n8$1fe@jimmy.trumpet.com.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hmm. At the risk of getting involved in a holy war, my only comment in reply is.. 1. I fully appreciate that IPv6 allows fragmentation. In fact my stck implements it (hopefully correctly). 2. I can can fully appreciate should routers need not concern themselves with fragmentation due to the cost of having to do so as I outlined in my previous message. The cost for a router is *much* more than would be for a host. I would guess that issues like packet forwarding time would become critical, and also I suspect that quality routers would be using high grade memory which would impact critically in a cost sensitive market. Keeping hardware resources to a minimum is important from engineering and manufacturing point of view. Applying the rule that fragmentation should not occur across the network removes some significant problems for backbone routers. In general, memory is required for other more important things like BGP tables etc. Now how would you like it if some fragment bombed all the critical paths in your network connection? Having the don't fragment bit forces routers to do fragmentation which is not good in the design of a router. 3. I don't personally care whether fragmentation is in or out. All I am saying is that it comes at a cost. For future expansion of the internet it is important to do a cost analysis to measure the cost of implementation and maintenance of that internetwork. Peter -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. Phone: +61-3-6245-0220 Fax: +61-3-6245-0210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 27 21:44:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id VAA03106 for ipng-dist; Sun, 27 Sep 1998 21:33:08 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id VAA03099 for ; Sun, 27 Sep 1998 21:32:55 -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 VAA02968 for ; Sun, 27 Sep 1998 21:32:54 -0700 Received: from mail-oak-3.pilot.net (mail-oak-3.pilot.net [198.232.147.18]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA09414 for ; Sun, 27 Sep 1998 21:32:54 -0700 (PDT) Received: from msd-gw.hitachi.com (msd.hitachi.com [137.168.1.1]) by mail-oak-3.pilot.net with ESMTP id UAA01096; Sun, 27 Sep 1998 20:53:41 -0700 (PDT) Received: from hicam-msd.hitachi.com (thunder [137.168.16.3]) by msd-gw.hitachi.com with ESMTP id VAA21546; Sun, 27 Sep 1998 21:31:40 -0700 (PDT) Received: from hw20.hitachi.com (hw20 [192.48.128.101]) by hicam-msd.hitachi.com with SMTP id VAA19962; Sun, 27 Sep 1998 21:31:02 -0700 (PDT) Received: from hw20 by hw20.hitachi.com (SMI-8.6/SMI-SVR4) id VAA07809; Sun, 27 Sep 1998 21:29:50 -0700 Message-Id: <199809280429.VAA07809@hw20.hitachi.com> Date: Sun, 27 Sep 1998 21:29:50 -0700 (PDT) From: Thomas Dineen Reply-To: Thomas Dineen Subject: (IPng 6541) Re: Host Fragmentation To: ipng@sunroof.eng.sun.com, pete@trumpet.com.au Cc: thomasd@hicam-msd.hitachi.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7kEsQ04erDM/uABTFAYFAg== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter: I fully concur with your article shown below. Cost and complexity are the controlling factors here! And low cost implementations are driving the modern inter-networking business. Right on. Thomas Dineen 1. I fully appreciate that IPv6 allows fragmentation. In fact my stck implements it (hopefully correctly). 2. I can can fully appreciate should routers need not concern themselves with fragmentation due to the cost of having to do so as I outlined in my previous message. The cost for a router is *much* more than would be for a host. I would guess that issues like packet forwarding time would become critical, and also I suspect that quality routers would be using high grade memory which would impact critically in a cost sensitive market. Keeping hardware resources to a minimum is important from engineering and manufacturing point of view. Applying the rule that fragmentation should not occur across the network removes some significant problems for backbone routers. In general, memory is required for other more important things like BGP tables etc. Now how would you like it if some fragment bombed all the critical paths in your network connection? Having the don't fragment bit forces routers to do fragmentation which is not good in the design of a router. 3. I don't personally care whether fragmentation is in or out. All I am saying is that it comes at a cost. For future expansion of the internet it is important to do a cost analysis to measure the cost of implementation and maintenance of that internetwork. Peter -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. Phone: +61-3-6245-0220 Fax: +61-3-6245-0210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------------- End Forwarded Message ------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 27 22:23:13 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id WAA03162 for ipng-dist; Sun, 27 Sep 1998 22:14:22 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id WAA03155 for ; Sun, 27 Sep 1998 22:14: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 WAA06864 for ; Sun, 27 Sep 1998 22:14:11 -0700 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id WAA21311 for ; Sun, 27 Sep 1998 22:14:09 -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 OAA13550; Mon, 28 Sep 1998 14:11:39 +0900 (JST) To: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com In-reply-to: bound's message of Sat, 26 Sep 1998 23:36:10 -0400. <199809270336.XAA0000030193@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 6542) Re: IPv6 Base API Doc 02a Ready to View From: Jun-ichiro itojun Itoh Date: Mon, 28 Sep 1998 14:11:39 +0900 Message-ID: <13546.906959499@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Please find the updated Base API spec at (via anon ftp): > sipper.pa-x.zk3.dec.com/pub/draft-ietf-ipngwg-bsd-api-new-02a.txt It looks that there's no domain name called "pa-x" under "zk3.dec.com". Is it my fault? itojun % dig @yield.zk3.dec.com. pa-x.zk3.dec.com. any ; <<>> DiG 2.2 <<>> @yield.zk3.dec.com. pa-x.zk3.dec.com. any ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10 ;; flags: qr aa rd ra; Ques: 1, Ans: 0, Auth: 1, Addit: 0 ;; QUESTIONS: ;; pa-x.zk3.dec.com, type = ANY, class = IN ;; AUTHORITY RECORDS: zk3.dec.com. 43200 SOA yield.zk3.dec.com. postmaster.yield.zk3.dec.com. ( 14377 ; serial 3600 ; refresh (1 hour) 1200 ; retry (20 mins) 1209600 ; expire (14 days) 43200 ) ; minimum (12 hours) ;; Total query time: 1013 msec ;; FROM: coconut.itojun.org to SERVER: yield.zk3.dec.com. 16.140.0.12 ;; WHEN: Mon Sep 28 14:10:30 1998 ;; MSG SIZE sent: 34 rcvd: 98 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 27 23:35:35 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id XAA03229 for ipng-dist; Sun, 27 Sep 1998 23:33:00 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id XAA03222 for ; Sun, 27 Sep 1998 23:32: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 XAA13392 for ; Sun, 27 Sep 1998 23:32:51 -0700 Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id XAA12017 for ; Sun, 27 Sep 1998 23:32:50 -0700 (PDT) Received: from alden ([10.128.1.82]) by dokka.maxware.no (8.8.5/8.8.5) with SMTP id IAA18868; Mon, 28 Sep 1998 08:32:43 +0200 Message-Id: <3.0.2.32.19980928082916.023ba590@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Mon, 28 Sep 1998 08:29:16 +0200 To: Volsinians@aol.com, ipng@sunroof.eng.sun.com From: Harald Tveit Alvestrand Subject: (IPng 6543) Re: Host Fragmentation In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Big interface buffers (in excess of about 0.1 second queue time) are harmful too; rather than causing sender TCPs to choke back on transmission rate, they cause the sender TCP to increase its estimate of round trip time. IMNSHO: anyone who thinks that publicly accessible Internets can be "properly engineered" hasn't lived in Europe - bandwidth starvation has been with us since day 1, and is still a fact of life. See http://www.nextel.no/kundesenter/nettinfo/statistikk/utland.html for stats on one of the main Norwegian IP providers' US trunk. No prizes for guessing its capacity.... I'd like to know what production environment you measured when you came to the conclusion that most duplicate ACKs occur because of delayed packets, not because of packet loss. I'd also like to understand your comment: >> How many packets they lose depends on the traffic load and the number >> of TCP connections, and the presence of non-adaptive traffic. >> But the ONLY IP network that doesn't lose packets is one where the >> packet senders are not able to utilize the bandwidth. > >Damaged packets and topological instability aside, the comment is >certainly not true. Since TCP increases its transmission rate until it either fills the recipient window or a packet is lost, you seem to be saying that in some IP networks, all connections' transmission rate is limited by the recipient window, not by the media capacity. Is that what you are saying? Harald T. Alvestrand -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.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 Mon Sep 28 03:43:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id DAA03431 for ipng-dist; Mon, 28 Sep 1998 03:40:05 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id DAA03424 for ; Mon, 28 Sep 1998 03:39:55 -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 DAA01588 for ; Mon, 28 Sep 1998 03:39:54 -0700 Received: from nsys.by ([194.158.194.130]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA15228 for ; Mon, 28 Sep 1998 03:39:46 -0700 (PDT) Received: from nsys.minsk.by (d4.nsys.by [194.158.194.135]) by nsys.by (8.8.8/8.8.7) with ESMTP id NAA08801 for ; Mon, 28 Sep 1998 13:38:18 +0300 Message-ID: <360F579C.3FD07A26@geocities.com> Date: Mon, 28 Sep 1998 11:32:12 +0200 From: Siarhei Hushchyn X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 6545) Re: Packet Loss (was Re: Host Fragmentation References: <199809250759.JAA09454@wilfer1.cdg.chalmers.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think, we are working on the hardware independent protocol (high level) and it must transfer via any medias (high speed ATM or Ethernet or low speed modem and, of course we must remember about Satellite communications). In any case we must develope universal protocol which will working over any hardware dependent protocol and will not produce bad traffic (header for each fragment). Solution for this problem I see in developing appropriate software stack: > It can also be argued whether the cure is better than the disease, > whether the added complexity in Path MTU Discovery really pays off > by avoiding b). Maybe some other problem takes over. Since the SW > industry (e.g. Sun/Solaris) has put MTU Discovery into IPv4, one > would assume that someone has actually looked into live Internet > traffic and/or made realistic simulations. References from those > people would be really useful and probably terminate this thread. The second part is - What about security enhancement in new version of IP? I think, it is a subject for forbid Network Fragmentation. Siarhei Hushchyn -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 28 03:43:43 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id DAA03422 for ipng-dist; Mon, 28 Sep 1998 03:39:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id DAA03415 for ; Mon, 28 Sep 1998 03:39: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 DAA01545 for ; Mon, 28 Sep 1998 03:39:09 -0700 Received: from nsys.by ([194.158.194.130]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA15032 for ; Mon, 28 Sep 1998 03:39:02 -0700 (PDT) Received: from nsys.minsk.by (d4.nsys.by [194.158.194.135]) by nsys.by (8.8.8/8.8.7) with ESMTP id NAA08785 for ; Mon, 28 Sep 1998 13:37:20 +0300 Message-ID: <360F579C.3FD07A26@geocities.com> Date: Mon, 28 Sep 1998 11:32:12 +0200 From: Siarhei Hushchyn X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 6544) Re: Packet Loss (was Re: Host Fragmentation References: <199809250759.JAA09454@wilfer1.cdg.chalmers.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think, we are working on the hardware independent protocol (high level) and it must transfer via any medias (high speed ATM or Ethernet or low speed modem and, of course we must remember about Satellite communications). In any case we must develope universal protocol which will working over any hardware dependent protocol and will not produce bad traffic (header for each fragment). Solution for this problem I see in developing appropriate software stack: > It can also be argued whether the cure is better than the disease, > whether the added complexity in Path MTU Discovery really pays off > by avoiding b). Maybe some other problem takes over. Since the SW > industry (e.g. Sun/Solaris) has put MTU Discovery into IPv4, one > would assume that someone has actually looked into live Internet > traffic and/or made realistic simulations. References from those > people would be really useful and probably terminate this thread. The second part is - What about security enhancement in new version of IP? I think, it is a subject for forbid Network Fragmentation. Siarhei Hushchyn -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 28 07:34:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA03826 for ipng-dist; Mon, 28 Sep 1998 07:26:29 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA03819 for ; Mon, 28 Sep 1998 07:26: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 HAA27280 for ; Mon, 28 Sep 1998 07:26:13 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA07349 for ; Mon, 28 Sep 1998 07:26:13 -0700 (PDT) Received: from spruce.iprg.nokia.com (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id HAA08183 for ; Mon, 28 Sep 1998 07:26:13 -0700 (PDT) Message-Id: <3.0.5.32.19980928072417.00ae9310@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 28 Sep 1998 07:24:17 -0700 To: ipng@sunroof.eng.sun.com From: The IESG (by way of Bob Hinden ) Subject: (IPng 6546) Last Call: IPv6 over Non-Broadcast Multiple Access (NBMA) networks to Proposed Standard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the Internetworking Over NBMA Working Group to consider the following two Internet-Drafts as Proposed Standards: o IPv6 over Non-Broadcast Multiple Access (NBMA) networks o IPv6 over ATM Networks The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by October 12, 1998. Files can be obtained via: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ion-ipv6-01.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ion-ipv6-atm-02.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 28 08:10:49 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA03869 for ipng-dist; Mon, 28 Sep 1998 08:01:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA03862 for ; Mon, 28 Sep 1998 08:01:44 -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 IAA05656 for ; Mon, 28 Sep 1998 08:01:42 -0700 Received: from achilles.noc.ntua.gr (achilles.noc.ntua.gr [147.102.222.210]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA01768 for ; Mon, 28 Sep 1998 08:01:41 -0700 (PDT) Received: from theseas.softlab.ece.ntua.gr (dkonto@theseas.softlab.ece.ntua.gr [147.102.1.1]) by achilles.noc.ntua.gr (8.8.8/8.8.8) with ESMTP id SAA13237 for ; Mon, 28 Sep 1998 18:01:39 +0300 (EET DST) Received: by softlab.ece.ntua.gr id SAA28230 at Mon, 28 Sep 1998 18:01:38 +0300 (EET DST) From: Dimitris Kontopodis Message-Id: <199809281501.SAA28230@softlab.ece.ntua.gr> Subject: (IPng 6547) tcp-udp mibs To: ipng@sunroof.eng.sun.com Date: Mon, 28 Sep 1998 18:01:38 +0300 (EET DST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi my diploma thesis is about ipv6, and it has been assigned to me to build an snmp agent for the tcp and udp mibs described in draft-ietf-ipngwg-ipv6-udp-mib-02.txt and draft-ietf-ipngwg-ipv6-tcp-mib-02.txt I would like to know if there is anyone else working on the same or on a similar project. I would also like to follow the design and updating of the above mibs. (Is there a special mailing list in which the mib or snmp matters are being discussed?) thanks Dimitris -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 28 09:42:27 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA03996 for ipng-dist; Mon, 28 Sep 1998 09:32:41 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA03989 for ; Mon, 28 Sep 1998 09:32: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 JAA00211 for ; Mon, 28 Sep 1998 09:32:31 -0700 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA00146 for ; Mon, 28 Sep 1998 09:32:32 -0700 (PDT) Received: by INET-IMC-05 with Internet Mail Service (5.5.2232.9) id ; Mon, 28 Sep 1998 09:32:32 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF8131A@RED-MSG-50> From: Richard Draves To: ipng@sunroof.eng.sun.com Subject: (IPng 6548) RE: draft-ietf-ipngwg-icmp-v2-02.txt Date: Mon, 28 Sep 1998 09:32:31 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I was recently reading the IPsec documents and realized that there is a problem with the ICMPv6 spec. The problem is that the ICMPv6 spec does not say anything about whether ICMP errors should be sent in response to fragments with a non-zero offset. In the v4 world, this is prohibited. (Eg see section 4.3.2.7 of RFC 1812.) I believe it is desirable to prohibit this for v6 as well. The reason IPsec brought this to mind is that with IPsec, in some cases a sender might want to maintain path MTU information at the level of upper-layer (eg TCP or UDP) connections. This is because different upper-layer connections originated by the sender might be subject to different security processing in the network, with differently-sized IPsec headers added to the packets. As a consequence, the sender wants to receive Packet Too Big messages that contain the upper-layer protocol data so it can pass the path MTU information to the appropriate upper-layer connection. Now consider the case of a sender that habitually sends fragments out of order, eg, sends the last fragment first. (I've observed implementations that do this.) When the fragments arrive at a router with a new MTU bottleneck, the router will generate a Packet Too Big for the first fragment that it sees. This will be a fragment with a non-zero offset, so it won't have the upper-layer protocol data. Because the router will implement ICMP error rate-limiting, it might not generate Packet Too Big errors for the subsequent fragments. This will be the case with any rate-limiting implementation that limits the errors to one per some time interval - one of the suggested algorithms. So in this situation, the sender will *never* get a Packet Too Big error with the upper-layer information that it wants to see. Preventing the generation of ICMP errors in response to fragments with a non-zero offset fixes this problem. Rich > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, September 25, 1998 7:26 AM > Cc: ipng@sunroof.eng.sun.com > Subject: I-D ACTION:draft-ietf-ipngwg-icmp-v2-02.txt > > > Note: This revision reflects comments received during the > last call period. > > 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 : Internet Control Message Protocol (ICMPv6) > for the Internet Protocol Version 6 > (IPv6) Specification > Author(s) : A. Conta, S. Deering > Filename : draft-ietf-ipngwg-icmp-v2-02.txt > Pages : 21 > Date : 24-Sep-98 > > This document specifies a set of Internet Control Message Protocol > (ICMP) messages for use with version 6 of the Internet Protocol > (IPv6). > > 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-icmp-v2-02.txt". > A URL for the Internet-Draft is: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v2-02.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-icmp-v2-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 28 11:54:15 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA04171 for ipng-dist; Mon, 28 Sep 1998 11:46:06 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA04164 for ; Mon, 28 Sep 1998 11:45:58 -0700 (PDT) From: Volsinians@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 LAA16256 for ; Mon, 28 Sep 1998 11:45:56 -0700 Received: from imo16.mx.aol.com (imo16.mx.aol.com [198.81.17.6]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA02613 for ; Mon, 28 Sep 1998 11:45:57 -0700 (PDT) Received: from Volsinians@aol.com by imo16.mx.aol.com (IMOv16.10) id LMSQa07908; Mon, 28 Sep 1998 14:45:50 -0400 (EDT) Message-ID: <1f0d207b.360fd95e@aol.com> Date: Mon, 28 Sep 1998 14:45:50 EDT To: richdr@microsoft.com Cc: ipng@sunroof.eng.sun.com, Bodzia@aol.com, nadia@deas.harvard.edu Mime-Version: 1.0 Subject: (IPng 6549) Re: draft-ietf-ipngwg-icmp-v2-02.txt 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 I have to ask the following. "What if the fragments travel different paths between the source and the destination and only a fragment with a non-zero offset reaches a network where the size of the fragment is too large?" Joachim Martillo Telford Tools, Inc. In a message dated 9/28/98 12:53:41 PM Eastern Daylight Time, richdr@microsoft.com writes: > I was recently reading the IPsec documents and realized that there is a > problem with the ICMPv6 spec. > > The problem is that the ICMPv6 spec does not say anything about whether ICMP > errors should be sent in response to fragments with a non-zero offset. In > the v4 world, this is prohibited. (Eg see section 4.3.2.7 of RFC 1812.) I > believe it is desirable to prohibit this for v6 as well. > > The reason IPsec brought this to mind is that with IPsec, in some cases a > sender might want to maintain path MTU information at the level of > upper-layer (eg TCP or UDP) connections. This is because different > upper-layer connections originated by the sender might be subject to > different security processing in the network, with differently-sized IPsec > headers added to the packets. > > As a consequence, the sender wants to receive Packet Too Big messages that > contain the upper-layer protocol data so it can pass the path MTU > information to the appropriate upper-layer connection. > > Now consider the case of a sender that habitually sends fragments out of > order, eg, sends the last fragment first. (I've observed implementations > that do this.) When the fragments arrive at a router with a new MTU > bottleneck, the router will generate a Packet Too Big for the first fragment > that it sees. This will be a fragment with a non-zero offset, so it won't > have the upper-layer protocol data. > > Because the router will implement ICMP error rate-limiting, it might not > generate Packet Too Big errors for the subsequent fragments. This will be > the case with any rate-limiting implementation that limits the errors to one > per some time interval - one of the suggested algorithms. > > So in this situation, the sender will *never* get a Packet Too Big error > with the upper-layer information that it wants to see. > > Preventing the generation of ICMP errors in response to fragments with a > non-zero offset fixes this problem. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 28 12:40:04 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA04245 for ipng-dist; Mon, 28 Sep 1998 12:31:17 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA04238 for ; Mon, 28 Sep 1998 12:31:08 -0700 (PDT) From: Volsinians@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 MAA28974 for ; Mon, 28 Sep 1998 12:30:34 -0700 Received: from imo23.mx.aol.com (imo23.mx.aol.com [198.81.17.67]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA00284 for ; Mon, 28 Sep 1998 12:28:32 -0700 (PDT) Received: from Volsinians@aol.com by imo23.mx.aol.com (IMOv16.10) id TZXLa02329; Mon, 28 Sep 1998 15:27:45 -0400 (EDT) Message-ID: Date: Mon, 28 Sep 1998 15:27:45 EDT To: lindberg@cdg.chalmers.se, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6550) Re: Packet Loss (was Re: Host Fragmentation 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 9/25/98 4:29:26 AM Eastern Daylight Time, lindberg@cdg.chalmers.se writes: > I'm afraid it remains a fact of the Internet that if an IP fragment > gets dropped: > a) The packet cannot be reassembled by the recipient host > and > b) the rest of the fragments move on and keep filling the links. > And, since IP packets/fragments may move along different paths, we > cannot even do the "horrible ATM-like PPD/EPD trick". > Then, whether or not this is a PROBLEM may and can be argued and > discussed in lengthy pieces of email. > My personal take is that b) is a disaster - it can give you 100% > utilized links and 0% goodput AND it is likely to appear when your > network is pushed near its limit. Whether this happens because up- > stream links are overloaded or its the Cessna 172 router who drops > packets from the Proteon interface is less important - when it > happens goodput rapidly drops. Actually, the Cessna 172 router example described a situation where network fragmentation decreased packet lossage while TCP segmentation or host fragmentation would produce consistent packet losses. > It can also be argued whether the cure is better than the disease, > whether the added complexity in Path MTU Discovery really pays off > by avoiding b). Maybe some other problem takes over. Since the SW > industry (e.g. Sun/Solaris) has put MTU Discovery into IPv4, one > would assume that someone has actually looked into live Internet > traffic and/or made realistic simulations. References from those > people would be really useful and probably terminate this thread. While it is possible that the Cessna 172 style packet loss is taking place in the network today, outside of topological instabilities due to architectural problems associated with Cisco routers, unless traffic is crossing an area of the internet that is severely traffic misengineered, loss of packets in the Internet is probably much lower than seems to be believed in this forum. However, if packet loss is as high as the specifiers of IPv6 seem to believe, using ICMP in the PMTU procedures is probably inappropriate. And if we really take that ridiculous Mogul paper seriously, what if the ICMP messages themselves were subject to deterministic packet loss (not to mention issues of ICMP filtering, NAT, etc.)? 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 Sep 28 13:19:19 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA04366 for ipng-dist; Mon, 28 Sep 1998 13:07:41 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA04359 for ; Mon, 28 Sep 1998 13:07:13 -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 NAA11163 for ; Mon, 28 Sep 1998 13:07:09 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id NAA23618 for ; Mon, 28 Sep 1998 13:07:11 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id PAA25225; Mon, 28 Sep 1998 15:07:08 -0500 Message-Id: <199809282007.PAA25225@gungnir.fnal.gov> To: Richard Draves Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 6551) Re: draft-ietf-ipngwg-icmp-v2-02.txt In-reply-to: Your message of Mon, 28 Sep 1998 09:32:31 PDT. <4D0A23B3F74DD111ACCD00805F31D8100AF8131A@RED-MSG-50> Date: Mon, 28 Sep 1998 15:07:07 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > [...] > Preventing the generation of ICMP errors in response to fragments with a > non-zero offset fixes this problem. No. it just pops up in a different place. Suppose the host is in the habit of fragmenting packets "from the end", sending N-1 full-size, non-initial fragments and an intiall, probably smaller fragment. Never mind which order they're sent in, your suggestion could stop the host from getting changed PMTU information. And, we can imagine that for an extended period, fragments are load-shared across a number of equal-cost paths which just happens to equal the number of fragments which compose a typical packet. Then all the initial fragments take the same path for a while, and if the MTU of one of the other paths shrinks, the router would never be allowed to send a message. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 28 14:12:51 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA04494 for ipng-dist; Mon, 28 Sep 1998 13:57:57 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA04487 for ; Mon, 28 Sep 1998 13:57:48 -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 NAA25855 for ; Mon, 28 Sep 1998 13:57:46 -0700 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA26942 for ; Mon, 28 Sep 1998 13:57:46 -0700 (PDT) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Mon, 28 Sep 1998 13:57:45 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF8132F@RED-MSG-50> From: Richard Draves To: "'Matt Crawford'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6552) Re: draft-ietf-ipngwg-icmp-v2-02.txt Date: Mon, 28 Sep 1998 13:57:45 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > No. it just pops up in a different place. Suppose the host is in the > habit of fragmenting packets "from the end", sending N-1 full-size, > non-initial fragments and an intiall, probably smaller fragment. > Never mind which order they're sent in, your suggestion could stop > the host from getting changed PMTU information. This is a good point. Are there any implementations that fragment in this way? If ICMP errors are not sent in response to non-zero-offset fragments, then such implementations would need to be changed. There doesn't seem to be any reason to do fragmentation this way. My understanding is the existing implementations that like to send the last fragment first do so for performance reasons - to make reassembly easier. So there's some rationale for this practice. (Btw, in case you were wondering: MSR IPv6 doesn't do this :-) > And, we can imagine that for an extended period, fragments are > load-shared across a number of equal-cost paths which just happens to > equal the number of fragments which compose a typical packet. Then > all the initial fragments take the same path for a while, and if the > MTU of one of the other paths shrinks, the router would never be > allowed to send a message. Also a good point. Although is this kind of load-sharing done in practice? Wouldn't the likely reordering screw up TCP flows? I thought load-sharing / traffic-shaping is more likely to be done at a much larger granularity, instead of packet-by-packet. If packet-by-packet load-sharing is desired, one solution would be introduce some randomization instead of strictly round-robining the packets. So it seems that there are some problems either way. If you prohibit ICMP errors in response to non-zero-offset fragments, you are compatible with existing implementations and with current v4 practice. If you allow such ICMP errors, you cause problems for unlikely scenarios that don't exist yet. (OK so I'm exaggerating :-) Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 28 14:21:08 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA04527 for ipng-dist; Mon, 28 Sep 1998 14:09:36 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA04520 for ; Mon, 28 Sep 1998 14:09:23 -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 OAA00658 for ; Mon, 28 Sep 1998 14:09:20 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id OAA04667 for ; Mon, 28 Sep 1998 14:09:21 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA25546; Mon, 28 Sep 1998 16:09:19 -0500 Message-Id: <199809282109.QAA25546@gungnir.fnal.gov> To: Richard Draves Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 6553) Re: draft-ietf-ipngwg-icmp-v2-02.txt In-reply-to: Your message of Mon, 28 Sep 1998 13:57:45 PDT. <4D0A23B3F74DD111ACCD00805F31D8100AF8132F@RED-MSG-50> Date: Mon, 28 Sep 1998 16:09:18 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So it seems that there are some problems either way. If you prohibit ICMP > errors in response to non-zero-offset fragments, you are compatible with > existing implementations and with current v4 practice. If you allow such > ICMP errors, you cause problems for unlikely scenarios that don't exist yet. I'd rather emphasize compatibility with the spec than with current practice (although I've seen cases we're you'd lose big if you followed the letter of the spec, that's usually in an implementation- scarce part of the specpsace). Here's an implementation choice that has its cake and eats it too: Rate limit ICMP errors quasi-separately for initial and non-initial fragments. That is, sending an error for a non-initial fragment precludes any more errors for non-initial fragments, but has no effect on sending an error for an initial fragment. Sending an error for an initial fragment stops errors for any fragment until the timer expires. But ... when you think of hosts keeping PMTU information on a per- connection basis, are you thinking of having the routers rate limit errors on different "flows" independently? Oh, my aching browser! Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 29 00:26:47 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id AAA05165 for ipng-dist; Tue, 29 Sep 1998 00:21:47 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id AAA05158 for ; Tue, 29 Sep 1998 00:21:36 -0700 (PDT) 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 AAA11462 for ; Tue, 29 Sep 1998 00:21:36 -0700 Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id AAA02510 for ; Tue, 29 Sep 1998 00:21:30 -0700 (PDT) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id QAA28418; Tue, 29 Sep 1998 16:12:38 +0900 (JST) Received: from splash.isl.rdc.toshiba.co.jp (splash.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id QAA11873; Tue, 29 Sep 1998 16:11:41 +0900 (JST) Received: from localhost (perfume.isl.rdc.toshiba.co.jp [133.196.16.145]) by splash.isl.rdc.toshiba.co.jp (8.8.8/8.8.8/4.3) with ESMTP id QAA18216; Tue, 29 Sep 1998 16:12:37 +0900 (JST) To: richdr@microsoft.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6555) Re: draft-ietf-ipngwg-icmp-v2-02.txt In-Reply-To: Your message of "Mon, 28 Sep 1998 09:32:31 -0700" <4D0A23B3F74DD111ACCD00805F31D8100AF8131A@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8100AF8131A@RED-MSG-50> X-Mailer: Mew version 1.93 on Emacs 20.3 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980929161019T.jinmei@isl.rdc.toshiba.co.jp> Date: Tue, 29 Sep 1998 16:10:19 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-Dispatcher: imput version 980905(IM100) Lines: 45 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 28 Sep 1998 09:32:31 -0700, >>>>> Richard Draves said: > Now consider the case of a sender that habitually sends fragments out of > order, eg, sends the last fragment first. (I've observed implementations > that do this.) When the fragments arrive at a router with a new MTU > bottleneck, the router will generate a Packet Too Big for the first fragment > that it sees. This will be a fragment with a non-zero offset, so it won't > have the upper-layer protocol data. > Because the router will implement ICMP error rate-limiting, it might not > generate Packet Too Big errors for the subsequent fragments. This will be > the case with any rate-limiting implementation that limits the errors to one > per some time interval - one of the suggested algorithms. I understand the problem. Your suggestion is reasonable to some extent, but there seems to be at least two problems(they are not the typical cases, though): 1. The upper layer header is not necessarily contained in the packet which carries the first fragment. Consider the case where there is a very long Destination Options header between the fragment header and the upper layer header... 2. Unlike IPv4, there may be some intermediate headers between the IPv6 header and the Fragment Header. If we require routers the check you suggested, the routers have to examine each intermediate headers whether a Fragment Header is contained in a packet or not, and if so, the routers also have to check if it is the first fragment. This complicates routers' implementation and decreases routers' performance. I'd prefer that each host stores path MTUs per destination basis and that each router simply follows the rate limitation on sending ICMP errors. In this scenario, we can ensure the end-to-end connectivity, though we may have to stand some inefficiency when using extension headers. By the way, our implementation, called KAME, sends fragmented packets in "from the first to the end" order. Regards, JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 29 05:00:04 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA05328 for ipng-dist; Tue, 29 Sep 1998 04:49:58 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA05321 for ; Tue, 29 Sep 1998 04:49: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 EAA19884 for ; Tue, 29 Sep 1998 04:49:43 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA29460 for ; Tue, 29 Sep 1998 04:49:45 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id HAA18286; Tue, 29 Sep 1998 07:49:35 -0400 (EDT) Received: from brywasted.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA17640; Tue, 29 Sep 1998 07:49:35 -0400 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id HAA0000026259; Tue, 29 Sep 1998 07:49:34 -0400 (EDT) From: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group Message-Id: <199809291149.HAA0000026259@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Jun-ichiro itojun Itoh Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6556) Re: IPv6 Base API Doc 02a Ready to View In-Reply-To: Your message of "Mon, 28 Sep 1998 14:11:39 +0900." <13546.906959499@coconut.itojun.org> Date: Tue, 29 Sep 1998 07:49:34 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk SOrry folks its sipper.pa-x.dec.com /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 Wed Sep 30 06:42:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA06661 for ipng-dist; Wed, 30 Sep 1998 06:31:21 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA06654 for ; Wed, 30 Sep 1998 06:31:13 -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 GAA18923 for ; Wed, 30 Sep 1998 06:31:10 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA10855 for ; Wed, 30 Sep 1998 06:31:11 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id JAA03318 for ; Wed, 30 Sep 1998 09:31:10 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA02123; Wed, 30 Sep 1998 09:31:09 -0400 Message-Id: <199809301331.AA02123@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 6557) Base API: Check on IPv4 Literal Addresses Date: Wed, 30 Sep 1998 09:31:09 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks thanks for all the edits on the spec keep them coming. One came in offline to us co-authors I think should be checked with the WG thanks to Atsushi Onoe. In section 6.1 just before section 6.2 we speak of dealing with literal addresses. In addition we changed the semantics of AI_V4MAPPED or'd AI_ALL as follows per input from implementors that we should not assume v4mapped. -------------------------------------------- - If the AI_V4MAPPED flag is specified along with an af of AF_INET6, then the caller will accept IPv4-mapped IPv6 addresses. That is, if no AAAA records are found then a query is made for A records and any found are returned as IPv4-mapped IPv6 addresses (h_length will be 16). The AI_V4MAPPED flag is ignored unless af equals AF_INET6. - The AI_ALL flag is used in conjunction with the AI_V4MAPPED flag, and is only used with the IPv6 address family. When AI_ALL is logically or'd with AI_V4MAPPED flag then the caller wants all addresses: IPv6 and IPv4-mapped IPv6. A query is first made for AAAA records and if successful, the IPv6 addresses are returned. Another query is then made for A records and any found are returned as IPv4-mapped IPv6 addresses. h_length will be 16. Only if both queries fail does the function return a NULL pointer. This flag is ignored unless af equals AF_INET6. ------------------------------------------- First: What we did was force the use of AI_V4MAPPED directly when you want mapped addresses. Second: To get mapped and v6 addresses you 'or' AI_ALL with AI_V4MAPPED. The input was that each operation should be spelled out through the logic operation of the flags rather than a "default". So from the working groups perspective it was a syntax change really rather than semantics, but in fact did change the semantics of AI_ALL. for getipnodebyname.... .. if you want IPv6 addresses don't specify any flags with AF_INET6. .. if you want V4 Mapped specify AI_V4MAPPED with AF_INET6. .. if you want IPv6 address and V4 Mapped specify AI_V4MAPPED | AI_ALL and AF_INET6 and you get both. But for literal address situations and it is IPv4 dotted decimal it is not logical to specify AI_ALL with AI_V4MAPPED. Because I have no way of getting an IPv6 address from 12.10.120.3 IPv4 address. Unless I take the name returned and then do an IPv6 lookup and that is going to be a performance nightmare and a bit to many gyrations for DNS resolvers. Esp with the new A6 records being proposed for the inverse tree. Users will scream so why do it. Here is the text that was misplaced and should be in the spec just before section 6.2 using the AI_V4MAPPED flag. -------------------------------------- When name is a dotted-decimal IPv4 address and af equals AF_INET6, and flags equals AI_V4MAPPED, an IPv4-mapped IPv6 address is returned: h_name points to an IPv6 hex address containing the IPv4-mapped IPv6 address, h_aliases is a NULL pointer, h_addrtype is AF_INET6, h_length is 16, h_addr_list[0] is a pointer to the 16-byte binary address, and h_addr_list[1] is a NULL pointer. -------------------------------------- Please comment on this issue so we can wrap it up. 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 Wed Sep 30 07:37:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA06742 for ipng-dist; Wed, 30 Sep 1998 07:23:21 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA06735 for ; Wed, 30 Sep 1998 07:23: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 HAA26498 for ; Wed, 30 Sep 1998 07:23:11 -0700 Received: from onoe2.sm.sony.co.jp (onoe2.sm.sony.co.jp [133.138.10.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA07491 for ; Wed, 30 Sep 1998 07:22:53 -0700 (PDT) Received: from duplo.sm.sony.co.jp (onoe@localhost) by onoe2.sm.sony.co.jp (8.9.0/3.7W) with ESMTP id XAA21237 for ; Wed, 30 Sep 1998 23:22:46 +0900 (JST) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.8.8/8.8.8) id XAA23558; Wed, 30 Sep 1998 23:22:02 +0900 (JST) Date: Wed, 30 Sep 1998 23:22:02 +0900 (JST) From: Atsushi Onoe Message-Id: <199809301422.XAA23558@duplo.sm.sony.co.jp> To: ipng@sunroof.eng.sun.com Subject: (IPng 6559) Re: Base API: Check on IPv4 Literal Addresses In-Reply-To: Your message of "Wed, 30 Sep 1998 09:31:09 -0400" <199809301331.AA02123@quarry.zk3.dec.com> References: <199809301331.AA02123@quarry.zk3.dec.com> X-Mailer: Cue version 0.2 (980810-1527/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > for getipnodebyname.... > > .. if you want IPv6 addresses don't specify any flags with AF_INET6. > > .. if you want V4 Mapped specify AI_V4MAPPED with AF_INET6. > > .. if you want IPv6 address and V4 Mapped specify AI_V4MAPPED | > AI_ALL and AF_INET6 and you get both. > > But for literal address situations and it is IPv4 dotted decimal it is > not logical to specify AI_ALL with AI_V4MAPPED. Because I have no way > of getting an IPv6 address from 12.10.120.3 IPv4 address. Unless I take I think getipnodebyname() for IPv4 literal address with AI_V4MAPPED flag should return IPv4-mapped IPv6 address regardless AI_ALL flag. For applications support multi protocol (ex. telnet), setting AI_V4MAPPED | AI_ALL is very helpful as well as getaddrinfo(). However, if a user specifies remote host as IPv4 literal string, such applications must call inet_pton() for each address family prior calls to getipnodebyname() unless it returns IPv4-mapped address. Actually the current spec for IPv4 literal address is very confusing: with AI_V4MAPPED returns IPv4-mapped IPv6 address with AI_V4MAPPED | AI_ALL returns NULL Regards, Atsushi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 30 09:45:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA06939 for ipng-dist; Wed, 30 Sep 1998 09:37:48 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA06932 for ; Wed, 30 Sep 1998 09:37: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 JAA29341 for ; Wed, 30 Sep 1998 09:37:33 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA05694 for ; Wed, 30 Sep 1998 09:37:34 -0700 (PDT) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id MAA08814; Wed, 30 Sep 1998 12:37:32 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA19571; Wed, 30 Sep 1998 12:37:30 -0400 Message-Id: <199809301637.AA19571@quarry.zk3.dec.com> To: Atsushi Onoe Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6560) Re: Base API: Check on IPv4 Literal Addresses In-Reply-To: Your message of "Wed, 30 Sep 1998 23:22:02 +0900." <199809301422.XAA23558@duplo.sm.sony.co.jp> Date: Wed, 30 Sep 1998 12:37:30 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Atushi, >I think getipnodebyname() for IPv4 literal address with AI_V4MAPPED flag >should return IPv4-mapped IPv6 address regardless AI_ALL flag. agree. I did not have my bogon deflector on. In the spec for dotted we don't really have to set AI_V4MAPPED or AI_ALL it will return IPv4 mapped to save the inet_pton as we state in the spec. Sorry for the confusion. I thought we now wanted all IPv6 addrs in haddrlist. >For applications support multi protocol (ex. telnet), setting >AI_V4MAPPED | AI_ALL is very helpful as well as getaddrinfo(). For AF_INET6 this is in the spec now yes. >However, if a user specifies remote host as IPv4 literal string, such >applications must call inet_pton() for each address family prior calls >to getipnodebyname() unless it returns IPv4-mapped address. But with the misplaced text now in there that is fixed and I will take out the req to specifiy AI_V4MAPPED. >Actually the current spec for IPv4 literal address is very confusing: > with AI_V4MAPPED returns IPv4-mapped IPv6 address > with AI_V4MAPPED | AI_ALL returns NULL Agreed. Neither is required to be specified. 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 Wed Sep 30 16:25:24 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA07406 for ipng-dist; Wed, 30 Sep 1998 16:19:28 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id QAA07399 for ; Wed, 30 Sep 1998 16:19:15 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id QAA17600; Wed, 30 Sep 1998 16:18:47 -0700 (PDT) Date: Wed, 30 Sep 1998 16:18:03 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6561) Re: Base API: Check on IPv4 Literal Addresses To: bound@zk3.dec.com Cc: Atsushi Onoe , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199809301637.AA19571@quarry.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JIM, > >Actually the current spec for IPv4 literal address is very confusing: > > with AI_V4MAPPED returns IPv4-mapped IPv6 address > > with AI_V4MAPPED | AI_ALL returns NULL > > Agreed. Neither is required to be specified. Just to make sure ... I assume you don't want to return a mapped address (even for literal IPv4 addresses) unless AI_V4MAPPED is set since it might confuse applications. Thus I think the rules for IPv4 literals with getipnodebyname(AF_INET6, ...) should be If AI_V4MAPPED is set (with or without AI_ALL) return IPv4-mapped Otherwise return NULL 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 Wed Sep 30 21:51:37 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id VAA07709 for ipng-dist; Wed, 30 Sep 1998 21:40:23 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id VAA07702 for ; Wed, 30 Sep 1998 21:40: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 VAA06612 for ; Wed, 30 Sep 1998 21:40:13 -0700 Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA18360 for ; Wed, 30 Sep 1998 21:40:13 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id NAA18058 for ; Thu, 1 Oct 1998 13:40:12 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id NAA17434 for ; Thu, 1 Oct 1998 13:40:12 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id NAA11185 for ; Thu, 1 Oct 1998 13:40:11 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 6562) KAME 980930 stable release Mime-Version: 1.0 From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19981001134014I.kazu@iijlab.net> Date: Thu, 01 Oct 1998 13:40:14 +0900 X-Dispatcher: imput version 980923(IM101) Lines: 76 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We are happy to inform you the stable release of KAME 980930. The kits are available from: http://www.kame.net/ Summary of the differences from the previous release is enclosed below. Enjoy! --Kazu, KAME Project ---from here Here is summary of differences between KAME stable 980731 and 980930. <> - Added our home-brew NAT code, called "SuMiRe". (FreeBSD/BSDI only) NOTE: Since it lacks documentations at this moment, we don't recommend you to try this right now. <> - Supported router alert option to some extent. - Supported multicast listener discovery to some extent(host side). - Improved the management code for information obtained from router advertisements. - rtsold: router solicitation daemon, for interface management on endhosts. - Router renumbering support is ongoing. (is not working right now). - Number of multicast groups per socket is now unlimited; it was limited to 20 in the previous stable release. - Added a new mechanism to manage prefixes advertised by router advertisements for mobile stations. - IPv6 version of multicast kludge; unicast addresses can be safely deleted from an interface even if there is a multicast group on the interface. - More conformance to Neighbor Discovery specification, especially about processing router advertisements(see CHANGELOG). - IPV6_{ADD,DROP}_MEMBERSHIP is renamed to IPV6_{JOIN,LEAVE}_MEMBERSHIP. NOTE: latest revision of bsd-api-new-02, called "02a", renamed this again into IPV6_{JOIN,LEAVE}_GROUP. This kit uses definition based on "old 02". - ICMP Redirects to on-link destinations, that is, not to better routers. - ICMP error rate limitation. <> - "struct sockaddr_in6" was changed again to conform to draft-ietf-ipngwg-bsd-api-new-02 spec. sin6_ifindex member was removed, and struct members were reordered. NOTE: ALL THE USERLAND TOOLS MUST BE RECOMPILED. - Some library functions, inet6_option_XXX, are newly implemented, which are defined in RFC 2292(advanced sockets API). <> - "racoon" IKE daemon is now working in limited situations. - Proper source IPv4 address will be used for outer IPv4 header of IPv4 IPsec tunnel. Now you can configure VPN network with KAME routers. - Key management code is improved. <> - EPRT/EPSV support for ftp/ftpd. (rfc2428) - getnodeby{addr,name} has renamed to getipnodeby{addr,name} to conform to draft-ietf-ipngwg-bsd-api-new-02 spec. - Bunch of updates/additions in IPv6-ready ports collection (FreeBSD kit only). - Some of IPv6 enable patches are now distributed separately from FreeBSD ports directory, so that BSDI/NetBSD users can enjoy those patches. Please check ftp://ftp.kame.net/pub/kame/misc/. <> - For BSDI, ATM driver based on ALTQ kit has been merged into the kernel. ATM userland tools must be grabbed from ALTQ kit. visit ftp://ftp.csl.sony.co.jp/pub/kjc/. - Synchronized some of the kernel source code among three operating systems we support (FreeBSD/BSDI/NetBSD), to ease maintainance. ---to here -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------