From owner-ipng Thu Dec 1 01:59:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28323; Thu, 1 Dec 94 01:59:38 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28317; Thu, 1 Dec 94 01:59:31 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id BAA24575; Thu, 1 Dec 1994 01:53:15 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA08172; Thu, 1 Dec 94 01:54:15 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 1 Dec 94 17:53:23 +0900 From: Masataka Ohta Message-Id: <9412010853.AA01356@necom830.cc.titech.ac.jp> Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 To: craig@aland.bbn.com (Craig Partridge) Date: Thu, 1 Dec 94 17:53:22 JST Cc: ipng@sunroof.Eng.Sun.COM, craig@aland.bbn.com, end2end-interest@ISI.EDU, flows@research.ftp.com, int-serv@ISI.EDU In-Reply-To: <199412010101.RAA02781@aland.bbn.com>; from "Craig Partridge" at Nov 30, 94 5:01 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The idea behind this is the following. Take Van J's fast IP forwarding > code and write it up in assembler for your favorite current processor. > What you'll discover is that, in almost all cases, you are memory bound > not instruction bound. I.e. the instruction count is small and you're > usually running in-cache instructions, and so the key performance issue > is how likely is your routing table entry to be in the primary cache in > the processor? Provided your cache hit rate is high, you run pretty > quickly. Aren't you trying to support tommorrow's network with yesterday's LSIs? If you are using a newtwork of 1500B packets over 1GBps line, you have 12 micro seconds for the forwarding, which is more than enough for tens of NON-CACHED DRAM accesses. You may even use multiple processors per an interface. When the memory latency is the bottleneck, having muptiple processors really helps. If you are using shorter transfer unit of ATM, MAC layer flow label: VPI/VCI, which is somehow supposed be recognized by hardware for the necessary translation, will do the job (provided that RSVP indirectly affects the link layer setup). Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 07:55:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28505; Thu, 1 Dec 94 07:55:02 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28499; Thu, 1 Dec 94 07:54:55 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id HAA28498; Thu, 1 Dec 1994 07:48:40 -0800 From: makholm@diku.dk Received: from odin.diku.dk by Sun.COM (sun-barr.Sun.COM) id AA15626; Thu, 1 Dec 94 07:49:42 PST Received: from jarnsaxa.diku.dk by odin.diku.dk with SMTP id AA20705 (5.65c8/IDA-1.4.4 for ); Thu, 1 Dec 1994 16:49:30 +0100 Received: by jarnsaxa.diku.dk id AA24991 (5.65c8/IDA-1.4.4 for ipng@sunroof.eng.sun.com); Thu, 1 Dec 1994 16:49:29 +0100 Message-Id: <199412011549.AA24991@jarnsaxa.diku.dk> Subject: (IPng) Wording of Flow ID definition To: ipng@sunroof.Eng.Sun.COM Date: Thu, 1 Dec 1994 16:49:28 +0100 (MET) In-Reply-To: <199411291712.JAA01689@aland.bbn.com> from "Craig Partridge" at Nov 29, 94 09:12:15 am X-Mailer: ELM [version 2.4 PL20] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Howdy Craig Partridge > The Flow ID is a pseudo-random number between 1 and FFFFFF (hex) that > is unique when combined with the source address. The zero Flow ID is > reserved to say that no Flow ID is being used. The specification > requires that a source must not reuse a Flow ID value until all state > information for the previous use of the Flow ID has been flushed from > all routers in the internet. Sorry for breaking in here (and this is apparently not even the original source of the wording), but isn't it slightly misworded to describe the Flow ID as 'pseudo-random' when there's a uniqueness requirement on it? 'Uninterpreted' would be a better choice, I think. -- _ Henning Makholm - Math and CS student - University of Copenhagen |_|_\/| Email: makholm@diku.dk - Fido: 2:236/151.12 - Phone +45 42845582 | |_ | Snail-mail: Aamosevej 44, DK-2610 Rodovre - HAM callsign: OZ2HEM ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 08:21:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28522; Thu, 1 Dec 94 08:21:18 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28516; Thu, 1 Dec 94 08:21:10 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id IAA05652; Thu, 1 Dec 1994 08:14:54 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA19937; Thu, 1 Dec 94 08:16:02 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14630(7)>; Thu, 1 Dec 1994 08:15:52 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Thu, 1 Dec 1994 08:15:37 -0800 To: makholm@diku.dk Cc: craig@aland.bbn.com, ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) Wording of Flow ID definition In-Reply-To: makholm's message of Thu, 01 Dec 94 07:49:28 -0800. <199412011549.AA24991@jarnsaxa.diku.dk> Date: Thu, 1 Dec 1994 08:15:31 PST From: Steve Deering Message-Id: <94Dec1.081537pst.12173@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Sorry for breaking in here (and this is apparently not even the original > source of the wording), but isn't it slightly misworded to describe the > Flow ID as 'pseudo-random' when there's a uniqueness requirement on it? > 'Uninterpreted' would be a better choice, I think. If you read the IPv6 spec, you will see that it is a requirement that the nodes use a [pseudo-]random number generator to generate new flow IDs. Yes, when such a number is generated, the node must then check if it already has an outstanding flow with that same Flow ID and, if so, repeat the generation process until it gets a unique one. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 08:25:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28534; Thu, 1 Dec 94 08:25:47 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28528; Thu, 1 Dec 94 08:25:36 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA11085; Thu, 1 Dec 1994 08:20:33 -0800 Date: Thu, 1 Dec 1994 08:20:33 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199412011620.IAA11085@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Cc: hinden@jurassic Subject: (IPng) Updated IPng Web Pages Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I updated the IPng web pages. The URL is: http://playground.sun.com/pub/ipng/html/ipng-main.html The ptrs to the internet drafts have been changed to reflect the current and new drafts plus a number of smaller fixes and changes. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 08:38:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28569; Thu, 1 Dec 94 08:38:53 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28281; Wed, 30 Nov 94 23:33:56 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id XAA13651; Wed, 30 Nov 1994 23:27:40 -0800 Received: from ginger.lcs.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA23499; Wed, 30 Nov 94 23:28:49 PST Received: by ginger.lcs.mit.edu id AA04089; Thu, 1 Dec 94 01:56:04 -0500 Date: Thu, 1 Dec 94 01:56:04 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9412010656.AA04089@ginger.lcs.mit.edu> To: craig@aland.bbn.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 Cc: end2end-interest@isi.edu, flows@research.ftp.com, int-serv@isi.edu, jnc@ginger.lcs.mit.edu Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: Craig Partridge Take Van J's fast IP forwarding code and write it up in assembler for your favorite current processor. Do any major router vendors actually use this approach (plain old RISC CPU's) for forwarding in their high-end boxes? If not, aren't we solving a non- problem? Flows force one to split the first level cache into two caches -- one of flow IDs and one of routing entries See, if you made flows the basic forwarding element, like I'm suggesting, this problem would go away! :-) What's more, the flow space is bigger, so rather than using the, say, 100 or 200 most recent routes (ala Feldmeier's and Mogul's studies), we may have to cache the most recent 200-500 flow IDs. Craig, is this a guess, or is there some study we can look at? Feldmeier's TM-352, "Estimated Performance of a Gateway Routing Cache" is old (it was done in '88), but it contains some interesting data when studied closely. For instance, it shows, for number of active "trains" (defined as ones whose interpacket arrival times do not exceed 10 seconds) in the most active internal router at MIT, a nice bell curve centered on about 65, with a standard deviation of about 13. There is more of a tail on the high side, true, but it peters out by about 120. I'd expect these numbers to be higher today, of course, but is traffic growth faster than growth in cache size? (Remember that cache size will grow as the *square* of the feature size, whereas speed goes only as the feature size.) Noel ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 08:39:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28589; Thu, 1 Dec 94 08:39:34 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28291; Thu, 1 Dec 94 00:08:14 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id AAA23398; Thu, 1 Dec 1994 00:02:00 -0800 Received: from nacho.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA28647; Thu, 1 Dec 94 00:03:04 PST Received: from [171.69.126.104] (sl-charlatan-14.cisco.com [171.69.126.104]) by nacho.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id AAA16279; Thu, 1 Dec 1994 00:02:45 -0800 X-Sender: fred@nacho.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 1 Dec 1994 00:02:52 -0800 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: fred@cisco.com (Fred Baker) Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 Cc: craig@aland.bbn.com, ipng@sunroof.Eng.Sun.COM, kc@upeksa.sdsc.edu, end2end-interest@ISI.EDU, flows@research.ftp.com, int-serv@ISI.EDU Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 10:56 PM 11/30/94, Noel Chiappa wrote: > > What's more, the flow space is bigger, so rather than using the, say, 100 > or 200 most recent routes (ala Feldmeier's and Mogul's studies), we may > have to cache the most recent 200-500 flow IDs. > >Craig, is this a guess, or is there some study we can look at? Feldmeier's >TM-352, "Estimated Performance of a Gateway Routing Cache" is old (it was >done in '88), but it contains some interesting data when studied closely. You might look at Kim Claffey's papers last year - what she came up with was somewhere in the ballpark of caching 200-500 LRU flows depending on your timeouts and the service point (500-1000 in an NSFNET router like SDSC or UIUC, 100-200 in a t-1 hub router, up to (say) 50 on a typical workstation LAN. You can argue with the numbers if your favorite router has different numbers, but she has some interesting sample points. ============================================================================= If you're not living on the edge, you're taking up too much room! ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 08:49:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28610; Thu, 1 Dec 94 08:49:05 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28604; Thu, 1 Dec 94 08:48:57 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id IAA13168; Thu, 1 Dec 1994 08:42:42 -0800 Received: from bells.cs.ucl.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA25509; Thu, 1 Dec 94 08:43:45 PST Received: from thud.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 1 Dec 1994 16:43:33 +0000 To: ipng@sunroof.Eng.Sun.COM Cc: craig@aland.bbn.com Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 In-Reply-To: Your message of "Thu, 01 Dec 94 01:56:04 EST." <9412010656.AA04089@ginger.lcs.mit.edu> Date: Thu, 01 Dec 94 16:43:42 +0000 Message-Id: <4653.786300222@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Take Van J's fast IP forwarding code and write it up in assembler for your > favorite current processor. >Do any major router vendors actually use this approach (plain old RISC CPU's) >for forwarding in their high-end boxes? If not, aren't we solving a non- >problem? off the record, a friend of mine used to work for a large (largest?) router vendor, and his discreptions of their fancy hardware for fast forwarding did not impress me - our general purpose risc machien code was better...... note that router vendors 'special fancy hardware' may have deadended itself a bit like symbolics did when the sun-2 interpreted lisp outperformed their fancy microcoded one:-) j ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 09:32:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28671; Thu, 1 Dec 94 09:32:02 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28665; Thu, 1 Dec 94 09:31:50 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id JAA14423; Thu, 1 Dec 1994 09:26:43 -0800 Date: Thu, 1 Dec 1994 09:26:43 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199412011726.JAA14423@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), craig@aland.bbn.com, ipng@sunroof.Eng.Sun.COM, kc@upeksa.sdsc.edu, end2end-interest@ISI.EDU, flows@research.ftp.com, int-serv@ISI.EDU In-Reply-To: Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, Can we please have this discussion on only one list. I think ipng, end2end, flows, and int-serv is three too many. I propose that it be only on ipng. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 09:43:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28707; Thu, 1 Dec 94 09:43:13 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28619; Thu, 1 Dec 94 09:05:50 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id IAA17838; Thu, 1 Dec 1994 08:59:34 -0800 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA28820; Thu, 1 Dec 94 09:00:39 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 To: ipng@sunroof.Eng.Sun.COM Date: Thu, 1 Dec 1994 16:58:39 +0100 (GMT) In-Reply-To: <4653.786300222@cs.ucl.ac.uk> from "Jon Crowcroft" at Dec 1, 94 04:43:42 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > off the record, a friend of mine used to work for a large (largest?) > router vendor, and his discreptions of their fancy hardware for fast > forwarding did not impress me - our general purpose risc machien code > was better...... Another reference point. The stuff I'm involved in is all RISC based using MIPS chips for routing 6 ISDN, 2 Megastreams (2*2Mbits/sec) + an ethernet port. Not big end but the little end stuff is all risc based, or some of it even 386 based. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 09:44:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28728; Thu, 1 Dec 94 09:44:10 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28683; Thu, 1 Dec 94 09:40:10 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id JAA27333; Thu, 1 Dec 1994 09:33:54 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA03130; Thu, 1 Dec 94 09:20:00 PST Received: by rodan.UU.NET id QQxskr15119; Thu, 1 Dec 1994 12:15:58 -0500 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 To: fred@cisco.com (Fred Baker) Date: Thu, 1 Dec 1994 12:15:58 -0500 (EST) Cc: jnc@ginger.lcs.mit.edu, craig@aland.bbn.com, ipng@sunroof.Eng.Sun.COM, kc@upeksa.sdsc.edu, end2end-interest@ISI.EDU, flows@Research.Ftp.Com, int-serv@ISI.EDU In-Reply-To: from "Fred Baker" at Dec 1, 94 00:02:52 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >Craig, is this a guess, or is there some study we can look at? Feldmeier's > >TM-352, "Estimated Performance of a Gateway Routing Cache" is old (it was > >done in '88), but it contains some interesting data when studied closely. AlterNet's backbone routers typically have a few 1000 cache entries. Some of my routers currently have 7,000 cache entries. --asp@uunet.uu.net (Andrew Partan) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 10:09:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28767; Thu, 1 Dec 94 10:09:21 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28751; Thu, 1 Dec 94 09:51:07 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id JAA00414; Thu, 1 Dec 1994 09:44:51 -0800 Received: from curtis.ansremote.com by Sun.COM (sun-barr.Sun.COM) id AA05700; Thu, 1 Dec 94 09:30:57 PST Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id MAA00378; Thu, 1 Dec 1994 12:28:34 -0500 Message-Id: <199412011728.MAA00378@curtis.ansremote.com> To: Masataka Ohta Cc: craig@aland.bbn.com (Craig Partridge), ipng@sunroof.Eng.Sun.COM, end2end-interest@isi.edu, flows@research.ftp.com, int-serv@isi.edu Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 In-Reply-To: Your message of "Thu, 01 Dec 1994 17:53:22 +0200." <9412010853.AA01356@necom830.cc.titech.ac.jp> Date: Thu, 01 Dec 1994 12:27:18 -0500 From: Curtis Villamizar Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In message <9412010853.AA01356@necom830.cc.titech.ac.jp>, Masataka Ohta writes: > > If you are using a newtwork of 1500B packets over 1GBps line, you have > 12 micro seconds for the forwarding, which is more than enough for tens > of NON-CACHED DRAM accesses. It's those pesky TCP ACKs. Now if we could just stop people from sending ACKs and using DNS, etc .... :-) TCP data packets are more often 552 byte packets and 40 byte acks. Data point: average packet size according to Merit data on the NSFNET varies from 180-260 bytes depending on which month you look at. I agree that even a radix tree lookup can be done easily within this time. If that was the only thing a processor on a router interface had to do, then we'd be in good shape. Curtis ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 10:32:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28843; Thu, 1 Dec 94 10:32:41 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28837; Thu, 1 Dec 94 10:32:33 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id KAA07253; Thu, 1 Dec 1994 10:26:17 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA17508; Thu, 1 Dec 94 10:27:15 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA27229; Thu, 1 Dec 94 10:02:20 -0800 Received: by xirtlu.zk3.dec.com; id AA04060; Thu, 1 Dec 1994 13:01:49 -0500 Message-Id: <9412011801.AA04060@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), craig@aland.bbn.com, kc@upeksa.sdsc.edu, end2end-interest@ISI.EDU, flows@research.ftp.com, int-serv@ISI.EDU Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 In-Reply-To: Your message of "Thu, 01 Dec 94 09:26:43 PST." <199412011726.JAA14423@jurassic.Eng.Sun.COM> Date: Thu, 01 Dec 94 13:01:43 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Can we please have this discussion on only one list. I think ipng, >end2end, flows, and int-serv is three too many. I propose that it be >only on ipng. I agree with Bob Hinden. Also IPng is a real lot of work and a real lot of specs and it requires full time attention by some of us. For that reason I have asked to be removed from e-2-e, flows, and int-serv as I can't keep up with the research work too and do IPng as thats why my company is paying for me to come to the IETF as an individual. In other words I have to do IPng very well. Hence, I would like this to be discussed on IPng so I can participate as an IPv6 implementor building this stuff. For the research, design, and future architecture needs of flows I understand the need for the other lists. But disccussions like flow-ID caches at the transport for IPv6 needs implementors of IPv6 in the discussion. We are all here on IPng list so lets keep it here. p.s. Craig and Steve - I will give you my comments in person at the IETF. Just maxed out with all our specs (overwhelmed is more accurate). From a host perspective per IPv6 implementation of course. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 10:52:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28870; Thu, 1 Dec 94 10:52:14 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28784; Thu, 1 Dec 94 10:16:53 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id KAA05412; Thu, 1 Dec 1994 10:10:37 -0800 Received: from curtis.ansremote.com by Sun.COM (sun-barr.Sun.COM) id AA11165; Thu, 1 Dec 94 09:56:42 PST Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id MAA00347; Thu, 1 Dec 1994 12:17:48 -0500 Message-Id: <199412011717.MAA00347@curtis.ansremote.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: craig@aland.bbn.com, ipng@sunroof.Eng.Sun.COM, end2end-interest@isi.edu, flows@research.ftp.com, int-serv@isi.edu Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 In-Reply-To: Your message of "Thu, 01 Dec 1994 01:56:04 EST." <9412010656.AA04089@ginger.lcs.mit.edu> Date: Thu, 01 Dec 1994 12:16:46 -0500 From: Curtis Villamizar Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In message <9412010656.AA04089@ginger.lcs.mit.edu>, Noel Chiappa writes: > From: Craig Partridge > > Take Van J's fast IP forwarding code and write it up in assembler for you > r > favorite current processor. > > Do any major router vendors actually use this approach (plain old RISC CPU's) > for forwarding in their high-end boxes? If not, aren't we solving a non- > problem? Ours use an I960 on each interface card, which do the forwarding. The RS/6K just runs the AIX system, daemons, routing protocols, snmp, etc. A few spercomputer centers run DEC Alpha or SGIs as FDDI routers because they are faster than commercial routers. > Flows force one to split the first level cache into two caches -- one of > flow IDs and one of routing entries > > See, if you made flows the basic forwarding element, like I'm suggesting, thi > s > problem would go away! :-) The problem is then the amount of state you need. Remember that commercial routers are currently having trouble with 20,000 CIDR prefixes. We have seen close to 8,000 active destination host addresses in random 90 second data samples (samples taken about 6 months ago). If we start routing on flow IDs and flow IDs are unique per TCP connection, I think we are going to have a space requirement explosion. That is also why I think connection oriented will eventually fail to scale. > What's more, the flow space is bigger, so rather than using the, say, 100 > or 200 most recent routes (ala Feldmeier's and Mogul's studies), we may > have to cache the most recent 200-500 flow IDs. > > Craig, is this a guess, or is there some study we can look at? Feldmeier's > TM-352, "Estimated Performance of a Gateway Routing Cache" is old (it was > done in '88), but it contains some interesting data when studied closely. Try closer to 10,000 most recent routes on Internet today. Right now there are already commercial routers failing (theashing their cache and pitching packets into the bit bucket at high rates) because there cache size is too small. > For instance, it shows, for number of active "trains" (defined as ones whose > interpacket arrival times do not exceed 10 seconds) in the most active > internal router at MIT, a nice bell curve centered on about 65, with a > standard deviation of about 13. There is more of a tail on the high side, > true, but it peters out by about 120. > > I'd expect these numbers to be higher today, of course, but is traffic growth > faster than growth in cache size? (Remember that cache size will grow as the > *square* of the feature size, whereas speed goes only as the feature size.) > > Noel Where is hwb when you need him? :-) You've seen his "flows.ps" paper? Curtis ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 10:52:04 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28863; Thu, 1 Dec 94 10:52:04 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28773; Thu, 1 Dec 94 10:14:18 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id KAA05156; Thu, 1 Dec 1994 10:08:03 -0800 Received: from curtis.ansremote.com by Sun.COM (sun-barr.Sun.COM) id AA10593; Thu, 1 Dec 94 09:54:09 PST Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id MAA00378; Thu, 1 Dec 1994 12:28:34 -0500 Message-Id: <199412011728.MAA00378@curtis.ansremote.com> To: Masataka Ohta Cc: craig@aland.bbn.com (Craig Partridge), ipng@sunroof.Eng.Sun.COM, end2end-interest@isi.edu, flows@research.ftp.com, int-serv@isi.edu Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 In-Reply-To: Your message of "Thu, 01 Dec 1994 17:53:22 +0200." <9412010853.AA01356@necom830.cc.titech.ac.jp> Date: Thu, 01 Dec 1994 12:27:18 -0500 From: Curtis Villamizar Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In message <9412010853.AA01356@necom830.cc.titech.ac.jp>, Masataka Ohta writes: > > If you are using a newtwork of 1500B packets over 1GBps line, you have > 12 micro seconds for the forwarding, which is more than enough for tens > of NON-CACHED DRAM accesses. It's those pesky TCP ACKs. Now if we could just stop people from sending ACKs and using DNS, etc .... :-) TCP data packets are more often 552 byte packets and 40 byte acks. Data point: average packet size according to Merit data on the NSFNET varies from 180-260 bytes depending on which month you look at. I agree that even a radix tree lookup can be done easily within this time. If that was the only thing a processor on a router interface had to do, then we'd be in good shape. Curtis ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 11:54:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28919; Thu, 1 Dec 94 11:54:31 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28913; Thu, 1 Dec 94 11:54:18 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA16548; Thu, 1 Dec 1994 11:48:02 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA03575; Thu, 1 Dec 94 11:49:04 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm035-13.dialip.mich.net [141.211.7.24]) by merit.edu (8.6.9/merit-2.0) with SMTP id OAA18775 for ; Thu, 1 Dec 1994 14:49:00 -0500 Date: Thu, 1 Dec 94 19:24:59 GMT From: "William Allen Simpson" Message-Id: <3550.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Unsolicited General Advertisements Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Wan-Yen Hsu > > A General Advertisement is only sent in response to a General Solicitation. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > This restriction prohibits a node from notifying others of a change to its > binding between an IP address and an media address. A node may have multiple > interface cards over the same link to provide a highly available network > configuration. When one interface card fails, it may move the IP address > associated with the failed card to another card. In order to make clients > aware of this change an unsolicited General Advertismement should be allowed > and sent by a node to the "All-Node multicast address" with "intra-link" scope. > Clients can then change their IP address <-> MAC address binding. > No, it SHOULD NOT! The other-identifier already has that information in previous adverts. The "gratuitous ARP hack" has long been a thorn in our sides. The requirement that a General Advertisement is only sent in response to a solicitation (along with the rest of the mechanism described) is very important for security pairings, and avoiding waking sleeping devices. We don't like the heavy traffic Hellos of ES-IS. > On receipt of a General Advertisement, regardless of whether it is solicited or > unsolicited, all nodes which have a Hop Cache entry for the Source field > address specified in the General Advertisement should update the cache entry > with the current information in the newly arrived General Advertisement. > No, this will not work as written. The old entry will not be eliminated, since the entries are based on the tuple {IPv6 address, interface, MAC address}. Since the MAC address doesn't match, the entry will not be updated. As noted above, if the implementation is operating correctly, there will already be an entry via the other-identifier. The only thing that could be done is to issue an advertisement with a zero lifetime, thereby cancelling the old entry. This is already done by routers that stop routing, and could be done by hosts. But, I don't see how you would be helped. No one could possibly know that the interface had failed until the LifeTime expired. If the host could "know" that its other interface was going to fail, a better thing to do would be to shorten the lifetimes, so that black hole detection occurs sooner. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 14:12:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29064; Thu, 1 Dec 94 14:12:18 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28898; Thu, 1 Dec 94 11:30:01 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA13668; Thu, 1 Dec 1994 11:23:45 -0800 Received: from curtis.ansremote.com by Sun.COM (sun-barr.Sun.COM) id AA26195; Thu, 1 Dec 94 11:09:52 PST Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id MAA00378; Thu, 1 Dec 1994 12:28:34 -0500 Message-Id: <199412011728.MAA00378@curtis.ansremote.com> To: Masataka Ohta Cc: craig@aland.bbn.com (Craig Partridge), ipng@sunroof.Eng.Sun.COM, end2end-interest@isi.edu, flows@research.ftp.com, int-serv@isi.edu Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 In-Reply-To: Your message of "Thu, 01 Dec 1994 17:53:22 +0200." <9412010853.AA01356@necom830.cc.titech.ac.jp> Date: Thu, 01 Dec 1994 12:27:18 -0500 From: Curtis Villamizar Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In message <9412010853.AA01356@necom830.cc.titech.ac.jp>, Masataka Ohta writes: > > If you are using a newtwork of 1500B packets over 1GBps line, you have > 12 micro seconds for the forwarding, which is more than enough for tens > of NON-CACHED DRAM accesses. It's those pesky TCP ACKs. Now if we could just stop people from sending ACKs and using DNS, etc .... :-) TCP data packets are more often 552 byte packets and 40 byte acks. Data point: average packet size according to Merit data on the NSFNET varies from 180-260 bytes depending on which month you look at. I agree that even a radix tree lookup can be done easily within this time. If that was the only thing a processor on a router interface had to do, then we'd be in good shape. Curtis ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 15:43:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29132; Thu, 1 Dec 94 15:43:49 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29126; Thu, 1 Dec 94 15:43:41 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id PAA09292; Thu, 1 Dec 1994 15:37:23 -0800 Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA16731; Thu, 1 Dec 94 15:38:12 PST Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA07408 for ipng@sunroof.eng.sun.com; Thu, 1 Dec 94 18:37:37 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id PAA00187; Thu, 1 Dec 1994 15:35:57 -0800 Message-Id: <199412012335.PAA00187@aland.bbn.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Wording of Flow ID definition In-Reply-To: Your message of Thu, 01 Dec 94 16:49:28 +0100. <199412011549.AA24991@jarnsaxa.diku.dk> From: Craig Partridge Date: Thu, 01 Dec 94 15:35:49 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi Henning: ... isn't it slightly misworded to describe the Flow ID as 'pseudo-random' when there's a uniqueness requirement on it? Interesting point. As I understand it, the true goal is (a) for each flow ID to be unique and (b) that a set of flow IDs generate by a particular host be uniformly distributed over the value space. Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 16:15:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29207; Thu, 1 Dec 94 16:15:32 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29200; Thu, 1 Dec 94 16:15:23 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id QAA13279; Thu, 1 Dec 1994 16:09:07 -0800 Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA21704; Thu, 1 Dec 94 16:10:03 PST Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA08794 for curtis@ans.net; Thu, 1 Dec 94 18:43:38 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id PAA00217; Thu, 1 Dec 1994 15:41:56 -0800 Message-Id: <199412012341.PAA00217@aland.bbn.com> To: curtis@ans.net Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), craig@aland.bbn.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 In-Reply-To: Your message of Thu, 01 Dec 94 12:16:46 -0500. <199412011717.MAA00347@curtis.ansremote.com> From: Craig Partridge Date: Thu, 01 Dec 94 15:41:50 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Try closer to 10,000 most recent routes on Internet today. Right now there are already commercial routers failing (theashing their cache and pitching packets into the bit bucket at high rates) because there cache size is too small. Curtis: Sanity check for me here. My understanding of recent literature and various network reports is that the current situation is the following: * The total routing *table* (not cache) is 10,000+ routes * The size of a cache (accessed before doing a full routing lookup to try to avoid the full lookup) required to achieve roughly 95% to 99% hit rates (i.e., 95% to 99% chance that the route for the datagram's destination is already in the routing cache) is still somewhere between 100-200 routes (though I saw a note go past that suggests this number may be climbing closer to 500). I've been worrying more about the cache, since this is where the real speed comes (and 95% of the routing is done). It is clear that if we use flows, we'll have both a flow cache and a flow table in addition to our regular routing table and cache. Memory requirements in routers definitely go up if we use flows. Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 16:26:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29255; Thu, 1 Dec 94 16:26:40 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29249; Thu, 1 Dec 94 16:26:31 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id QAA14530; Thu, 1 Dec 1994 16:20:15 -0800 Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA24356; Thu, 1 Dec 94 16:21:16 PST Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA15691 for ipng@sunroof.eng.sun.com; Thu, 1 Dec 94 19:21:05 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id QAA00409; Thu, 1 Dec 1994 16:19:24 -0800 Message-Id: <199412020019.QAA00409@aland.bbn.com> To: Masataka Ohta Cc: craig@aland.bbn.com (Craig Partridge), ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 In-Reply-To: Your message of Thu, 01 Dec 94 17:53:22 +0200. <9412010853.AA01356@necom830.cc.titech.ac.jp> From: Craig Partridge Date: Thu, 01 Dec 94 16:19:19 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Aren't you trying to support tommorrow's network with yesterday's LSIs? If you are using a newtwork of 1500B packets over 1GBps line, you have 12 micro seconds for the forwarding, which is more than enough for tens of NON-CACHED DRAM accesses. You may even use multiple processors per an interface. When the memory latency is the bottleneck, having muptiple processors really helps. Hi Masataka: There are two ways to measure throughput on a processor. One is to compute the average packet size (which is still around 1 Kbit) and figure out how long one has to do a lookup. The other is to figure out how many 20-byte (IPv4) or 40-byte (IPv6) headers you can handle per second. I find the latter number more useful because it allows you to compute the number of processor per interface (or interfaces per processor) you can support. Note that while I like multiprocessors, I also believe in trying to limit them - all the designs I've seen end up showing developing contention problems as the number of processors gets large. Anyway, if you look at IPv6's 40 bytes (320 bits) at a gigabit, that's 320 ns = about 16 memory accesses (if you use *20 ns SRAM*). Remember that as part of the forwarding process, you've got to get the header into the processor and then write the updated header out. Now you can probably get away with only writing one 32-bit word (the 2nd word, with the hop limit in it), but you probably have to read the entire header, which takes 10 accesses. So you've already used 11 memory accesses and you haven't even looked at a route yet (shallow Patricia tree required! :-)). Note, this analysis assumes you have a 32-bit cache line and you use 20 ns SRAM. If you use 70ns DRAM, you'll need at least a 128-bit cache line (less common) and in 320 ns (a bit under 5 accesses), you'll use 3 accesses to read the header, 1 to write the update, and you've got only 0.6 of an access left to look for a route (better hope for a cache hit! :-)). Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 19:07:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29333; Thu, 1 Dec 94 19:07:33 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29327; Thu, 1 Dec 94 19:07:25 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id TAA26165; Thu, 1 Dec 1994 19:01:08 -0800 Received: from relay.hp.com by Sun.COM (sun-barr.Sun.COM) id AA18746; Thu, 1 Dec 94 19:02:17 PST Received: from hpindlm.cup.hp.com by relay.hp.com with ESMTP (1.37.109.14/15.5+ECS 3.3) id AA080797335; Thu, 1 Dec 1994 19:02:16 -0800 Received: by hpindlm.cup.hp.com (1.37.109.11/15.5+IOS 3.20+cup+OMrelay) id AA003147330; Thu, 1 Dec 1994 19:02:10 -0800 Date: Thu, 1 Dec 1994 19:02:10 -0800 From: Wan-Yen Hsu Message-Id: <199412020302.AA003147330@hpindlm.cup.hp.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: Unsolicited General Advertisements Cc: wanyen@hpindlm.cup.hp.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >>> From: Wan-Yen Hsu >>> > A General Advertisement is only sent in response to a General Solicitation. >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> >>> This restriction prohibits a node from notifying others of a change to its >>> binding between an IP address and an media address. A node may have multiple >>> interface cards over the same link to provide a highly available network >>> configuration. When one interface card fails, it may move the IP address >>> associated with the failed card to another card. In order to make clients >>> aware of this change an unsolicited General Advertismement should be allowed >>> and sent by a node to the "All-Node multicast address" with "intra-link" scope. >>> Clients can then change their IP address <-> MAC address binding. >>> >>No, it SHOULD NOT! > >>The other-identifier already has that information in previous adverts. > The only mechanism currently in place to switch from one possible hop cache choice to another is the lifetime which is too slow for High Availability. The unsolicited advertisement being proposed would be an explicit indication that something has happened versus waiting for a time out. Also, if a node configures an IP address for a backup interface card after its primary card fails, then there will be no other-identifier inforamtion in previous advertisements. > >>>The "gratuitous ARP hack" has long been a thorn in our sides. > There are applications and implementations depending on unsolicited ARP replies. IPv4 does not prohibit this. The Packet Recpetion algorithm specified in ARP RFC handles unsolicited replies. IPv6 needs to provide an equivalent functionalilty to migrate those applications. > > >>>The requirement that a General Advertisement is only sent in response to >>>a solicitation (along with the rest of the mechanism described) is very >>>important for security pairings, and avoiding waking sleeping devices. I would like to understand the security pairings comment better, more info here would be helpful. > >>>We don't like the heavy traffic Hellos of ES-IS. What we are proposing is nothing like the ES-IS Hellos. Those are transmitted periodically by all end systems. What we would like is the opportunity to advertise changes under special error conditions in order to facilitate a more quick recovery. The unsolicited General advertisements will only be sent when the binding of an existant IP address and a media address changes. It should be very infrequent. In fact it should be a lot less frequent then the periodic router advertisements that are going out anyway, waking up those sleeping devices. >>> On receipt of a General Advertisement, regardless of whether it is solicited or >>> unsolicited, all nodes which have a Hop Cache entry for the Source field >>> address specified in the General Advertisement should update the cache entry >>> with the current information in the newly arrived General Advertisement. >> >>No, this will not work as written. The old entry will not be eliminated, >>since the entries are based on the tuple {IPv6 address, interface, MAC >>address}. Since the MAC address doesn't match, the entry will not be >>updated. > I did not see anywhere in the draft states the rule of updating a cache entry only when the tuple { IPv6 address, interface, MAC address } matches. > >>As noted above, if the implementation is operating correctly, there will >>already be an entry via the other-identifier. As stated above, there are some network configurations using interface card in a standby manner. An IP address will not be configured for the standby card until the primary card fails. There will be no other-id information in this situation. Also, relying on lifetime expiration to switch hop cache choice is too slow for services that provide high availability. > >>The only thing that could be done is to issue an advertisement with a >>zero lifetime, thereby cancelling the old entry. This is already done >>by routers that stop routing, and could be done by hosts. This is what I called "Unsolicited General Advertisement". If the same can be done by hosts before LifeTime expires, I am happy with this solution. > >>But, I don't see how you would be helped. No one could possibly know >>that the interface had failed until the LifeTime expired. If the host >>could "know" that its other interface was going to fail, a better thing >>to do would be to shorten the lifetimes, so that black hole detection >>occurs sooner. > I do not think there are magics for a host to know when its interface was going to fail. The black hole detection is too slow for the services that provide high availability. We are talking about a very quick failover in terms of few seconds or less! I definitely see the need for IPv6 to provide a mechanism for a host to proactively inform the network of the changes of a binding between an IP address and a media address. Wan-yen ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 19:39:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29365; Thu, 1 Dec 94 19:39:15 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29359; Thu, 1 Dec 94 19:39:08 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id TAA27758; Thu, 1 Dec 1994 19:32:51 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA22664; Thu, 1 Dec 94 19:33:51 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 2 Dec 94 12:24:34 +0900 From: Masataka Ohta Message-Id: <9412020324.AA05726@necom830.cc.titech.ac.jp> Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 To: curtis@ans.net Date: Fri, 2 Dec 94 12:24:33 JST Cc: craig@aland.bbn.com, ipng@sunroof.Eng.Sun.COM, end2end-interest@isi.edu, flows@research.ftp.com, int-serv@isi.edu In-Reply-To: <199412011728.MAA00378@curtis.ansremote.com>; from "Curtis Villamizar" at Dec 1, 94 12:27 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > In message <9412010853.AA01356@necom830.cc.titech.ac.jp>, Masataka Ohta writes: > > > > If you are using a newtwork of 1500B packets over 1GBps line, you have > > 12 micro seconds for the forwarding, which is more than enough for tens > > of NON-CACHED DRAM accesses. > > It's those pesky TCP ACKs. Now if we could just stop people from > sending ACKs and using DNS, etc .... :-) > > TCP data packets are more often 552 byte packets and 40 byte acks. ACK and DNS? What is it? It's flow. It's INT-SERV. It's QoS assured. It's MTU discovered. Well, there may be a small amount of users who use flows with time consuming setup procedure for DNS look up. So? Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 20:31:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29439; Thu, 1 Dec 94 20:31:50 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29433; Thu, 1 Dec 94 20:31:43 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id UAA29729; Thu, 1 Dec 1994 20:25:26 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA27909; Thu, 1 Dec 94 20:26:26 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 2 Dec 94 13:14:55 +0859 From: Masataka Ohta Message-Id: <9412020415.AA06168@necom830.cc.titech.ac.jp> Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 To: craig@aland.bbn.com (Craig Partridge) Date: Fri, 2 Dec 94 13:14:54 JST Cc: craig@aland.bbn.com, ipng@sunroof.Eng.Sun.COM In-Reply-To: <199412020019.QAA00409@aland.bbn.com>; from "Craig Partridge" at Dec 1, 94 4:19 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Hi Masataka: Hi, > There are two ways to measure throughput on a processor. One is to > compute the average packet size (which is still around 1 Kbit) and figure > out how long one has to do a lookup. The other is to figure out how many > 20-byte (IPv4) or 40-byte (IPv6) headers you can handle per second. You are wrong in assuming that CPUs are more expensive than DMA controllers. Moreover, controlling DMA controllers involves several non-chached off-chip data transfer and means a lot of latency. As you know, co-processors has disappeard from the modern RISC. > I find the latter number more useful because it allows you to compute > the number of processor per interface (or interfaces per processor) you > can support. "to compute the number of processor per interface" What does it mean? Could you elaborate? > Note that while I like multiprocessors, I also believe in > trying to limit them - all the designs I've seen end up showing developing > contention problems as the number of processors gets large. I wrote: > When the memory > latency is the bottleneck, having muptiple processors really helps. If, instead, the bandwidth is the bottleneck, you must widen the bus, regardless of whether you are using single or multiple processors. Note that, as you mentioned, instruction fetch does not consumes the bandwidth so much. That's still true even if there are a lot of processors. > Anyway, if you look at IPv6's 40 bytes (320 bits) at a gigabit, that's > 320 ns = about 16 memory accesses (if you use *20 ns SRAM*). Remember > that as part of the forwarding process, you've got to get the header into > the processor and then write the updated header out. Now you can probably > get away with only writing one 32-bit word (the 2nd word, with the hop > limit in it), but you probably have to read the entire header, which takes > 10 accesses. So you've already used 11 memory accesses and you haven't > even looked at a route yet (shallow Patricia tree required! :-)). Note, this > analysis assumes you have a 32-bit cache line and you use 20 ns SRAM. 32-bit cache line? Which processor are you assuming? Definitely not 64bit ones, for which IPv6 is designed. You are trying to support tommorrow's network with yesterday's LSIs. > If > you use 70ns DRAM, you'll need at least a 128-bit cache line (less common) > and in 320 ns (a bit under 5 accesses), 128-bit or more cache lines are quite common. On 64bit RISCs, cache lines will often be 256 or 512 bit. But for high performance floating point computing, a little more lengthy cache lines are preffered. See RS/6000 for example. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 21:09:20 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29458; Thu, 1 Dec 94 21:09:20 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29452; Thu, 1 Dec 94 21:09:09 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id VAA00909; Thu, 1 Dec 1994 21:02:51 -0800 Received: from ginger.lcs.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA00834; Thu, 1 Dec 94 21:04:00 PST Received: by ginger.lcs.mit.edu id AA10453; Thu, 1 Dec 94 23:42:51 -0500 Date: Thu, 1 Dec 94 23:42:51 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9412020442.AA10453@ginger.lcs.mit.edu> To: Bob.Hinden@Eng, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 Cc: end2end-interest@isi.edu, flows@research.ftp.com, int-serv@isi.edu, jnc@ginger.lcs.mit.edu Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: Bob.Hinden@eng.sun.com (Bob Hinden) Can we please have this discussion on only one list. I think ipng, end2end, flows, and int-serv is three too many. Sounds good to me. I propose that it be only on ipng. For the specific details of how to use the IPv6 flow field, this makes sense, and those should move there, but we seem to be have diverted into a generic discussion about flows, actually. I'd think it makes sense to keep those abstract, theoretical discussions out of the hair of people who are actually trying to do work, i.e. not on IPng. Noel ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 22:00:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29487; Thu, 1 Dec 94 22:00:02 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29481; Thu, 1 Dec 94 21:59:51 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id VAA02446; Thu, 1 Dec 1994 21:53:34 -0800 Received: from ginger.lcs.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA04691; Thu, 1 Dec 94 21:54:43 PST Received: by ginger.lcs.mit.edu id AA10984; Fri, 2 Dec 94 00:54:26 -0500 Date: Fri, 2 Dec 94 00:54:26 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9412020554.AA10984@ginger.lcs.mit.edu> To: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 Cc: jnc@ginger.lcs.mit.edu Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: bound@zk3.dec.com We are all here on IPng list so lets keep it here. This is not a correct assumption. I'm not, for what it's worth. Noel ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 1 23:50:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29517; Thu, 1 Dec 94 23:50:22 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29511; Thu, 1 Dec 94 23:50:15 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id XAA05498; Thu, 1 Dec 1994 23:43:57 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA13808; Thu, 1 Dec 94 23:45:08 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA02749; Thu, 1 Dec 94 23:43:33 -0800 Received: by xirtlu.zk3.dec.com; id AA18923; Fri, 2 Dec 1994 02:43:03 -0500 Message-Id: <9412020743.AA18923@xirtlu.zk3.dec.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 In-Reply-To: Your message of "Fri, 02 Dec 94 00:54:26 EST." <9412020554.AA10984@ginger.lcs.mit.edu> Date: Fri, 02 Dec 94 02:42:57 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Noel, We are all here on IPng list so lets keep it here. >This is not a correct assumption. I'm not, for what it's worth. Well if you have any interest in REAL implementations and use of FLOWS then I suggest you be on IPng because we are building real parts now and not just theory. Especially now that it is essentially a done deal (IPng is decided). Once we implement flows and put it in the market it will be tougher for the research community to impact the reality of implementations so maybe its a good idea if some of the architects take the IPng WG list very seriously and become involved regarding implementations for a moment or two. The emerging cache discussion at the transport is very timely fyi on this list. Before we build prototypes per se. >From many years of history. Once the Military has let the technology into the hands of the troops the tools begin to be used in war. Well in the case of IPng the troops are now learning how it can be useful in the real world and theory is passe for IPng. As Jim Morrison once said "We are on our Way". But as I said in previous mail (just sent) its right now just a place holder. p.s. You should also get your hands on the Gilligan-Thompson-Bound IPv6 API spec and see the interface we have defined for flows per applications for the BSD Sockets anyway. This clearly will be a driver of flows and how they are used too. p.s.s. Bottom line is XXXX-Talks and Bullxxxx-Walks. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 2 00:01:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29533; Fri, 2 Dec 94 00:01:21 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29527; Fri, 2 Dec 94 00:01:14 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id XAA05878; Thu, 1 Dec 1994 23:54:57 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA14531; Thu, 1 Dec 94 23:56:06 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA02081; Thu, 1 Dec 94 23:33:53 -0800 Received: by xirtlu.zk3.dec.com; id AA18897; Fri, 2 Dec 1994 02:33:19 -0500 Message-Id: <9412020733.AA18897@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: Bob.Hinden@Eng, end2end-interest@isi.edu, flows@research.ftp.com, int-serv@isi.edu, jnc@ginger.lcs.mit.edu Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 In-Reply-To: Your message of "Thu, 01 Dec 94 23:42:51 EST." <9412020442.AA10453@ginger.lcs.mit.edu> Date: Fri, 02 Dec 94 02:33:13 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Noel, >For the specific details of how to use the IPv6 flow field, this makes sense, >and those should move there, but we seem to be have diverted into a generic >discussion about flows, actually. I'd think it makes sense to keep those >abstract, theoretical discussions out of the hair of people who are actually >trying to do work, i.e. not on IPng. I agree. Thanks. But the work is on IPng and its real. Several of us have implementations that have flow IDs in the network layer. What we do with them is the next question but some of it is debugged as far a UNIX kernels go. But actually using it is not debugged. I was a bit confused on "...i.e. not on IPng..." we are doing real engineering work on IPng fyi, or did I miss something in your context? Because IPng is NO LONGER RESEARCH but moved to ADVANCED DEVELOPMENT and the prototypes of today will be the base for products soon. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 2 07:52:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29786; Fri, 2 Dec 94 07:52:39 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29780; Fri, 2 Dec 94 07:52:32 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id HAA18592; Fri, 2 Dec 1994 07:46:13 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA00839; Fri, 2 Dec 94 07:47:23 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14435(4)>; Fri, 2 Dec 1994 07:47:11 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Fri, 2 Dec 1994 07:47:01 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: (IPng) LocalTalk MTU? Date: Fri, 2 Dec 1994 07:46:45 PST From: Steve Deering Message-Id: <94Dec2.074701pst.12173@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Can someone who knows please describe the framing of IP packets over LocalTalk, including the maximum payload limit imposed by the LocalTalk framing (and by the DDP framing, if it is also present). Also, if the conventional IP MTU over LocalTalk is less than the maximum permitted by the local framing, please tell me that number too. (I have learned this information a few times in the past, but I can never find it when I'm looking for it!) The reason I am asking is to find out the possible consequences of raising the minimum MTU for IPv6 slightly, e.g., from 576 to 600. I think that would be advantageous because: (a) the 576-byte min MTU in IPv6 is easily confused with the 576-byte min reassembly buffer size in IPv4, but they are very different parameters and it is important that implementors not confuse them, and (b) there may be some higher-layer, UDP-based protocols that have a statically-specified maximum payload size calculated to fit in 576 bytes when using IPv4, which would no longer fit in 576 bytes when using IPv6 because of the bigger IP header. If we increased the IPv6 min packet size by at least 20 bytes (i.e., to 596 or more), those applications would not incur the costs of fragmentation. I believe that LocalTalk is the only widely-used link layer that has an MTU close to 576; please let me know if there are others. (Yes, I know that Ran worries about military satellites that have a wired-in MTU of 576 bytes that would take a Space Shuttle mission to change, so he needn't remind me of those.) Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 2 09:02:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29818; Fri, 2 Dec 94 09:02:03 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29812; Fri, 2 Dec 94 09:01:56 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id IAA23902; Fri, 2 Dec 1994 08:55:39 -0800 Received: from mailhost.wco.ftp.com (wco.ftp.com) by Sun.COM (sun-barr.Sun.COM) id AA13225; Fri, 2 Dec 94 08:56:32 PST Message-Id: <9412021651.AA15820@mailhost.wco.ftp.com> Received: from [128.127.202.230] (vida202.wco.ftp.com) by mailhost.wco.ftp.com; Fri, 2 Dec 94 08:51:56 PST X-Sender: veizades@128.127.203.200 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 2 Dec 1994 10:16:20 -0800 To: ipng@sunroof.Eng.Sun.COM From: veizades@ftp.com (John Veizades) Subject: Re: (IPng) LocalTalk MTU? Cc: deering@parc.xerox.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 7:46 AM 12/2/94 -0800, Steve Deering wrote: >Can someone who knows please describe the framing of IP packets over >LocalTalk, including the maximum payload limit imposed by the LocalTalk >framing (and by the DDP framing, if it is also present). Also, if the >conventional IP MTU over LocalTalk is less than the maximum permitted >by the local framing, please tell me that number too. (I have learned >this information a few times in the past, but I can never find it when >I'm looking for it!) Quoting from an unpublished spec: "DDP limits the data size of a DDP packet to 586 bytes. This is the Maximum Transfer Unit (MTU) for IP datagrams encapsulated in AppleTalk internets. Other networking media have larger MTUs. The smaller MTU size of AppleTalk implies that gateways must fragment packets bound for AppleTalk network which are larger than the AppleTalk MTU." Convention has used 576 as the maximum size of datagrams sent from a AppleTalk network though 586 bytes maybe sent, this avoids potential if not rare fragmentation of the 586 byte datagram. John Veizades... Author Unpublished Spec ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 2 09:19:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29839; Fri, 2 Dec 94 09:19:21 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29833; Fri, 2 Dec 94 09:19:10 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id JAA10156; Fri, 2 Dec 1994 09:14:06 -0800 Date: Fri, 2 Dec 1994 09:14:06 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199412021714.JAA10156@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Agenda for IPng Working Group Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The IPng working group has four meeting slots scheduled for San Jose. These are: Monday 1:30 - 3:30pm Monday 4:00 - 6:00pm Tuesday 4:00 - 6:00pm Wednesday 9:30 - Noon The overall goal for the meeting is to come to closure on the remaining issues with the base IPng specifications prior to submitting them for proposed standard. No tutorial presentations are planned. Attendees are expected to have read the documents they are discussing. Each agenda topic will consist of two parts. Listing of open issues and discussion leading to resolution of each issue. The agenda is as follows: Topic Presenter ---------------------------------- ----------------- 1. Review Agenda and Update Deering / Callon 2. Review Implementors Meeting Recommendations Hinden 3. IPng Specification Deering 4. ICMP/IGMP Specification Deering 5. Addressing Architecture Hinden 6. Unicast [Provider] Address Formats Rekhter 7. Security Specifications (Arch, Auth, ESP) Atkinson 8. Neighbor Discovery Specifications Simpson 9. DNS Specifications Thompson 10. Flow ID's Deering 11. Header Compression Specification Simpson Topics specific to transition, address lifetime, address auto-configuration, or IPng-OSI interoperation should be directed to the appropriate WG or BOF (ngtrans, tacit, ale, addrconf, or nosi), rather than the general IPng WG. Reminder to implementors: Jim Bound is again organizing a couple of IPng implementors' meetings (Sun 1-6, Fri 9-12), in the Garden Room at the same hotel as the IETF meetings. Presumably, the agenda for those meetings will be constructed in real time, as has been the practice in the past. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 2 09:51:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29871; Fri, 2 Dec 94 09:51:33 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29420; Thu, 1 Dec 94 20:24:39 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id UAA29509; Thu, 1 Dec 1994 20:18:22 -0800 Received: from curtis.ansremote.com by Sun.COM (sun-barr.Sun.COM) id AA27257; Thu, 1 Dec 94 20:19:29 PST Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id XAA03085; Thu, 1 Dec 1994 23:00:25 -0500 Message-Id: <199412020400.XAA03085@curtis.ansremote.com> To: Craig Partridge Cc: curtis@ans.net, jnc@ginger.lcs.mit.edu (Noel Chiappa), ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 In-Reply-To: Your message of "Thu, 01 Dec 1994 15:41:50 PST." <199412012341.PAA00217@aland.bbn.com> Date: Thu, 01 Dec 1994 23:00:23 -0500 From: Curtis Villamizar Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In message <199412012341.PAA00217@aland.bbn.com>, Craig Partridge writes: > > Try closer to 10,000 most recent routes on Internet today. Right now > there are already commercial routers failing (theashing their cache > and pitching packets into the bit bucket at high rates) because there > cache size is too small. Bzt. The previous paragraph said I measured 8,000 active hosts and eluded to the fact that someone's router caches host routes. This should say 10,000 most recent host routes. > Curtis: > > Sanity check for me here. > > My understanding of recent literature and various network reports is > that the current situation is the following: > > * The total routing *table* (not cache) is 10,000+ routes 19,000+ is the figure. > * The size of a cache (accessed before doing a full routing lookup to try > to avoid the full lookup) required to achieve roughly 95% to 99% hit rate > s > (i.e., 95% to 99% chance that the route for the datagram's destination is > already in the routing cache) is still somewhere between 100-200 routes > (though I saw a note go past that suggests this number may be climbing > closer to 500). > > I've been worrying more about the cache, since this is where the real speed > comes (and 95% of the routing is done). If you like, I can do an experiment and dump the routing table at a critical point, take a 90 second truncated packet header dump (~10MB) and try to figure out how many prefixes got used. I don't have a figure for this. > It is clear that if we use flows, we'll have both a flow cache and a flow > table in addition to our regular routing table and cache. Memory requirement > s > in routers definitely go up if we use flows. > > Craig Memory requirements would go way up. A particular brand of routers were dying on one providers network due to a ~4,000 host route entry (I'm not sure of the size) cache being exceeded. They are running alpha software that fixes this. They converted to prefix cache. As prefixes get bigger, prefixes will cover more hosts, more host pairs, and more hosts/port pairs (flows). As network attachments get faster, flow durations get shorter, so setup becomes more critical. As connectivity gets out to the pedestrians (packets to the people, community networks, and all that), you should see more isolated (in time) flows as community networks do things like process low volume mail. Personally, I think connection oriented is doomed to not scale to handle this. As long as the majority of traffic does not set up a reservation, things will continue to just need the prefixes and continue to scale. Reservations for every TCP connection I don't think stands a chance. Curtis ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 2 09:52:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29883; Fri, 2 Dec 94 09:52:15 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29691; Fri, 2 Dec 94 06:12:27 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA13660; Fri, 2 Dec 1994 06:06:09 -0800 Received: from mailer.psc.edu by Sun.COM (sun-barr.Sun.COM) id AA17850; Fri, 2 Dec 94 06:07:18 PST Received: from sabre.psc.edu by mailer.psc.edu (5.65/Ultrix3.0-C 11/12/92 nydick) id AA00616; Fri, 2 Dec 1994 09:07:08 -0500 Message-Id: <9412021407.AA00616@mailer.psc.edu> To: ipng@sunroof.Eng.Sun.COM Cc: Masataka Ohta , craig@aland.bbn.com (Craig Partridge), end2end-interest@isi.edu, flows@research.ftp.com, int-serv@isi.edu, mahdavi@sabre.psc.edu Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 In-Reply-To: Your message of "Thu, 01 Dec 1994 12:27:18 EST." <199412011728.MAA00378@curtis.ansremote.com> Date: Fri, 02 Dec 1994 09:06:54 -0500 From: "Jamshid Mahdavi" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > In message <9412010853.AA01356@necom830.cc.titech.ac.jp>, Masataka Ohta writes: > > > > If you are using a newtwork of 1500B packets over 1GBps line, you have > > 12 micro seconds for the forwarding, which is more than enough for tens > > of NON-CACHED DRAM accesses. > > It's those pesky TCP ACKs. Now if we could just stop people from > sending ACKs and using DNS, etc .... :-) > > TCP data packets are more often 552 byte packets and 40 byte acks. One would hope that the IPng and TCPng designers and implementors won't leave us in this particular bind again. MTU discovery is out there and works well when people bother... --J ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 2 12:30:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00139; Fri, 2 Dec 94 12:30:51 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00133; Fri, 2 Dec 94 12:30:44 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id MAA11313; Fri, 2 Dec 1994 12:24:24 -0800 Received: from mailhost.wco.ftp.com (kingkong.wco.ftp.com) by Sun.COM (sun-barr.Sun.COM) id AA16437; Fri, 2 Dec 94 12:25:25 PST Date: Fri, 2 Dec 94 11:34:36 PST Message-Id: <9412021934.AA16946@mailhost.wco.ftp.com> Received: from zoi (zoi.wco.ftp.com) by mailhost.wco.ftp.com; Fri, 2 Dec 94 11:34:37 PST X-Sender: veizades@128.127.203.200 X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-announce-post@cnri.reston.va.us From: veizades@ftp.com (John Veizades) Subject: (IPng) DECEMBER '94: Service Location WG (IPv6 and IPv4) Cc: srv-location@ftp.com, ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Group Name: Service Location (srvloc) IETF Area : Internet Area Date/Time : Tuesday, December 6, 1994 1330-1530 =================== The working group will discuss the final changes to the Internet draft which include some clarifications, some PDU changes and additions to the SCOPE concept. The working group will also discuss changes to the protocol specification to support the IPv6 protocols. John Veizades... ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 2 14:49:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00285; Fri, 2 Dec 94 14:49:42 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00279; Fri, 2 Dec 94 14:49:30 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA25705; Fri, 2 Dec 1994 14:43:11 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA20957; Fri, 2 Dec 94 12:56:48 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-22.dialip.mich.net [35.1.48.103]) by merit.edu (8.6.9/merit-2.0) with SMTP id OAA28927 for ; Fri, 2 Dec 1994 14:34:24 -0500 Date: Fri, 2 Dec 94 15:38:42 GMT From: "William Allen Simpson" Message-Id: <3559.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: Unsolicited General Advertisements Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Also, if a node configures an IP address for a backup interface card after > its primary card fails, then there will be no other-identifier inforamtion in > previous advertisements. > Perhaps you should take a look at the IPv6 address specification again. Every interface has at least one IPv6 address. An IPv6 address is bound to no more than one interface. > >>But, I don't see how you would be helped. No one could possibly know > >>that the interface had failed until the LifeTime expired. If the host > >>could "know" that its other interface was going to fail, a better thing > >>to do would be to shorten the lifetimes, so that black hole detection > >>occurs sooner. > > > I do not think there are magics for a host to know when its interface was > going to fail. > You don't think that _knowing_ an interface is _GOING_ to fail is magic? You have gone beyond machine "intelligence" to machine "precognition"! Patent pending, no doubt. How else would it know that the interface has failed, except that data stopped going through it? How else to measure the expectation of data, except when bound by a timer? > The black hole detection is too slow for the services that provide high > availability. We are talking about a very quick failover in terms of > few seconds or less! I definitely see the need for IPv6 to provide a > mechanism for a host to proactively inform the network of the changes of > a binding between an IP address and a media address. > If you expect recovery in a few seconds or less, set the LifeTime to a few seconds or less! Look, at the request of others, I already cut the default LifeTime from 1800 seconds in RFC-1256 to 600 seconds for hosts and 360 seconds for routers. The default needs to be reasonable (RFC-1256 specifies "negligible") for a big bridged network of thousands of nodes. There's plenty of text on reducing it further for black hole detection. Just make sure those "high availability" nodes are on very lightly loaded links. And at Perry's request, the next formats draft will change the LifeTime field definition from seconds to 1/100 seconds (following SNMP). After all, those "high availability" nodes will probably be attached to fiber, with gigabit bandwidth, so the rapid adverts will still be "negligible". Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 2 15:02:06 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00305; Fri, 2 Dec 94 15:02:06 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00299; Fri, 2 Dec 94 15:01:59 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA27169; Fri, 2 Dec 1994 14:55:39 -0800 Received: from black-ice.cc.vt.edu by Sun.COM (sun-barr.Sun.COM) id AA14163; Fri, 2 Dec 94 14:56:48 PST Received: from localhost (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.6.9/8.6.9) with ESMTP id RAA15964 for ; Fri, 2 Dec 1994 17:56:45 -0500 Message-Id: <199412022256.RAA15964@black-ice.cc.vt.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: Unsolicited General Advertisements In-Reply-To: Your message of "Fri, 02 Dec 1994 15:38:42 GMT." <3559.bill.simpson@um.cc.umich.edu> From: Valdis.Kletnieks@vt.edu Date: Fri, 02 Dec 1994 17:56:45 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Fri, 02 Dec 1994 15:38:42 GMT, you said: > You don't think that _knowing_ an interface is _GOING_ to fail is magic? > You have gone beyond machine "intelligence" to machine "precognition"! > Patent pending, no doubt. > > How else would it know that the interface has failed, except that data > stopped going through it? Well.. I think the intent here is for high-reliability machines with (for instance) 2 Ethernet interfaces. If the system kernel attempts to send a packet out one interface, and it encounters an I/O error, it may be able to tell that the interface just went to the Big Bit Bucket In The Sky in literally a hundredth of a second, and it may want to announce something on its other interface The Very Next Packet Out, so that the fact of the failed interface becomes known within several hundredths of a second, rather than waiting 360 (or whatever) seconds for a time-out. The question seems to boil down to "exactly how does the system do the Very Next Packet announcement". Valdis Kletnieks Computer Systems Engineer Virginia Tech ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 2 16:18:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00385; Fri, 2 Dec 94 16:18:13 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00379; Fri, 2 Dec 94 16:18:06 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id QAA04452; Fri, 2 Dec 1994 16:11:47 -0800 Received: from Mordor.Stanford.EDU by Sun.COM (sun-barr.Sun.COM) id AA29154; Fri, 2 Dec 94 16:12:55 PST Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id QAA09982; Fri, 2 Dec 1994 16:12:48 -0800 X-Sender: dcrocker@mordor.stanford.edu (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 2 Dec 1994 19:12:52 -0500 To: ipng@sunroof.Eng.Sun.COM From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: re: (IPng) WWW home page Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, At 2:07 PM 11/29/94, Bob Hinden wrote: >John Baltzer writes: > > Is there any substance to these claims, or is IPv6 backwards > > compatible with IPv4 as intended? > >What the articles miss is that we are designing IPng so that IPv6 >implementations will interoperate with IPv4 implementations. A number of Please forgive my indulging in some emphasis on Bob's point by referring to history. What is generally being missed by the media (and forgotten by many within the Internet community) is that Steve Deering initially developed SIPP as a response to many months of participation in an IPng transition working group (IPAE) and proceeded to integrate transition requirements into refinements of the spec. This continues in the follow-on work with the spec in the IPv6 finalization. In a very real sense, IPv6 came first from a concern about transition and THEN a concern about the final environment. (The transition work developed a very rich set of transition tools, but -- if I correctly recall Steve's views at the time -- it was what I will politely call the remarkably awkward final environment that the original transition focus produced which motivated Steve to develop SIPP, as a much cleaner and vastly more appropriate final environment.) d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 2 17:30:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00443; Fri, 2 Dec 94 17:30:43 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00437; Fri, 2 Dec 94 17:30:31 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id RAA10373; Fri, 2 Dec 1994 17:24:13 -0800 Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA09845; Fri, 2 Dec 94 17:25:21 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id UAA04479 for ipng@sunroof.Eng.Sun.COM; Fri, 2 Dec 1994 20:27:08 -0500 (EST) Date: Fri, 2 Dec 1994 20:27:08 -0500 (EST) From: Scott Bradner Message-Id: <199412030127.UAA04479@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: Unsolicited General Advertisements Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Perhaps you should take a look at the IPv6 address specification again. > Every interface has at least one IPv6 address. An IPv6 address is bound > to no more than one interface. At the IPng implementers meeting a suggestion was made and generally agreed to to change this to "An IPv6 address is bound to no more than one logical interface" to cover cases where an additional level of abstraction is present in a device. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 2 17:34:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00455; Fri, 2 Dec 94 17:34:32 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00449; Fri, 2 Dec 94 17:34:25 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id RAA10649; Fri, 2 Dec 1994 17:28:06 -0800 Received: from hp.com by Sun.COM (sun-barr.Sun.COM) id AA10359; Fri, 2 Dec 94 17:29:06 PST Received: from hpindlm.cup.hp.com by hp.com with ESMTP (1.37.109.14/15.5+ECS 3.3) id AA163038138; Fri, 2 Dec 1994 17:28:58 -0800 Received: by hpindlm.cup.hp.com (1.37.109.11/15.5+IOS 3.20+cup+OMrelay) id AA127288131; Fri, 2 Dec 1994 17:28:51 -0800 Date: Fri, 2 Dec 1994 17:28:51 -0800 From: Wan-Yen Hsu Message-Id: <199412030128.AA127288131@hpindlm.cup.hp.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: Unsolicited General Advertisements Cc: wanyen@hpindlm.cup.hp.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> Also, if a node configures an IP address for a backup interface card after >> its primary card fails, then there will be no other-identifier inforamtion in >> previous advertisements. >> >Perhaps you should take a look at the IPv6 address specification again. >Every interface has at least one IPv6 address. An IPv6 address is bound >to no more than one interface. The backup interface scenario I described above exactly follows the rule that an IPv6 address is bound to no more than one interface at a time. An IP address can "move" from one interface card to another, but it is not bound to multiple cards at the same time. > >>But, I don't see how you would be helped. No one could possibly know > >>that the interface had failed until the LifeTime expired. If the host > >>could "know" that its other interface was going to fail, a better thing > >>to do would be to shorten the lifetimes, so that black hole detection > >>occurs sooner. > > > I do not think there are magics for a host to know when its interface was > going to fail. > >You don't think that _knowing_ an interface is _GOING_ to fail is magic? >You have gone beyond machine "intelligence" to machine "precognition"! >Patent pending, no doubt. That's exactly my point- it is not possible for a node to predict its card failure! What I meant was that it's not possible for a host to predict when its interface was going to fail. Therefore, it is impractical for a host to set the Lifetime "right" for quick recovery. >How else would it know that the interface has failed, except that data >stopped going through it? >How else to measure the expectation of data, except when bound by a >timer? There are ways to detect card failure before timer expires. One example is that drivers can notify card failure instaneously. >> The black hole detection is too slow for the services that provide high >> availability. We are talking about a very quick failover in terms of >> few seconds or less! I definitely see the need for IPv6 to provide a >> mechanism for a host to proactively inform the network of the changes of >> a binding between an IP address and a media address. >> >If you expect recovery in a few seconds or less, set the LifeTime to a >few seconds or less! Card failure is an exceptional case. I don't think LifeTime should be set based on exceptional cases. Instead, it should be set for normal cases. Setting Lifetime based on exceptional cases causes unnecessarily frequent traffic for General Solicitations and Advertisements. A proactive way for a node to advertise its media address changes is a better solution. Since IPv4 provides ways for a node to notify hardware changes, the same functionality should be provided in IPv6 for migration. Wan-yen ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 2 21:30:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00551; Fri, 2 Dec 94 21:30:57 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00545; Fri, 2 Dec 94 21:30:50 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id VAA20025; Fri, 2 Dec 1994 21:24:30 -0800 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA02974; Fri, 2 Dec 94 21:25:41 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA08366; Fri, 2 Dec 94 21:23:54 -0800 Received: by xirtlu.zk3.dec.com; id AA07212; Sat, 3 Dec 1994 00:23:53 -0500 Message-Id: <9412030523.AA07212@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Re: Unsolicited General Advertisements In-Reply-To: Your message of "Fri, 02 Dec 94 20:27:08 EST." <199412030127.UAA04479@newdev.harvard.edu> Date: Sat, 03 Dec 94 00:23:47 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> Perhaps you should take a look at the IPv6 address specification again. >> Every interface has at least one IPv6 address. An IPv6 address is bound >> to no more than one interface. >At the IPng implementers meeting a suggestion was made and generally >agreed to to change this to "An IPv6 address is bound to no more than one >logical interface" to cover cases where an additional level of >abstraction is present in a device. Below is the text from the implementors meeting sent out by Bob Hinden. -------------------------------------------------------------- The addressing architecture document should add that this recommendation does not prevent the following configurations from being supported: o A single address may be assigned to multiple physical interfaces if the implementation treats the multiple physical interfaces as a single aggregate and hides the the details of this aggregation from the Internet layer. This is useful for load-sharing over multiple physical interfaces. Only one (virtual) interface should be visible to IP. -------------------------------------------------------------- /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 2 21:36:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00567; Fri, 2 Dec 94 21:36:37 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00561; Fri, 2 Dec 94 21:36:30 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id VAA20108; Fri, 2 Dec 1994 21:30:10 -0800 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA03273; Fri, 2 Dec 94 21:31:14 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA08562; Fri, 2 Dec 94 21:28:16 -0800 Received: by xirtlu.zk3.dec.com; id AA07286; Sat, 3 Dec 1994 00:28:15 -0500 Message-Id: <9412030528.AA07286@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Re: Unsolicited General Advertisements In-Reply-To: Your message of "Fri, 02 Dec 94 17:28:51 PST." <199412030128.AA127288131@hpindlm.cup.hp.com> Date: Sat, 03 Dec 94 00:28:09 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Card failure is an exceptional case. I don't think LifeTime should be > set based on exceptional cases. Instead, it should be set for normal > cases. Setting Lifetime based on exceptional cases causes unnecessarily > frequent traffic for General Solicitations and Advertisements. > A proactive way for a node to advertise its media address changes is a > better solution. Since IPv4 provides ways for a node to notify hardware > changes, the same functionality should be provided in IPv6 for migration. I think Wan-yen and other folks at HP have brought up a valid concern and presented us with new data for system discovery. Lets talk it out at the IETF in the spirit of the IETF. I am going to think about it very seriously on the plane. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Dec 3 00:12:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00593; Sat, 3 Dec 94 00:12:26 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00587; Sat, 3 Dec 94 00:12:19 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id AAA23152; Sat, 3 Dec 1994 00:05:59 -0800 From: conta@zk3.dec.com Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA13488; Sat, 3 Dec 94 00:07:09 PST Received: from flambe.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA11296; Sat, 3 Dec 1994 03:07:07 -0500 Received: from brigit.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA09854; Sat, 3 Dec 1994 03:07:06 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA02755; Sat, 3 Dec 1994 02:43:27 -0500 Message-Id: <9412030743.AA02755@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) new ICMP draft. Date: Sat, 03 Dec 94 02:43:27 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM A revised version of the ICMP draft for IPv6 was submitted to the Internet Drafts directory - it should be made availble soon. The draft contains modifications suggested at the October implementors meeting, as well as other modifications, as it follows: o ICMPv6 indicates "packet too big" as a separate error message, rather than being included as one of the causes of a "destination unreachable" error. By using a separate ICMP message type, it eliminates the need for special-case handling of the "packet too big" subtype of Destination Unreachable messages, such as allowing only such messages to be sent in response to multicasts. o The ICMPv6 specification removes previous text about how to handle too long ICMP message, and adds text that the 16-bit error pointer can in theory point beyond the end of the packet when the error point is beyond what can fit in the 576-byte limit of an ICMP error message. o Absorb the IGMP section into the ICMP section, and translated IGMP messages into ICMP messages. o Text (quite many) corrections. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Dec 3 05:01:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00652; Sat, 3 Dec 94 05:01:08 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00646; Sat, 3 Dec 94 05:00:59 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id EAA28030; Sat, 3 Dec 1994 04:54:38 -0800 Received: from cheops.anu.edu.au by Sun.COM (sun-barr.Sun.COM) id AA26207; Sat, 3 Dec 94 04:55:33 PST Message-Id: <9412031255.AA26207@Sun.COM> Received: by cheops.anu.edu.au (1.38.193.3/16.2) id AA29750; Sat, 3 Dec 94 23:55:13 +1100 From: Darren Reed Subject: (IPng) indentifying a flow. To: ipng@sunroof.Eng.Sun.COM Date: Sat, 3 Dec 1994 23:55:13 +1100 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM It was mentioned that the source address and flow id would be used as a pair to provide a unique tuple. Wouldn't it be better to use the EID in this role as we're not particularly interested in doing anything with the source address except as a partial key ? This may also be desirable for mobile hosts which change address but keep a flow open `across' an address change. darren ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Dec 3 13:01:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00690; Sat, 3 Dec 94 13:01:44 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00684; Sat, 3 Dec 94 13:01:37 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id MAA06011; Sat, 3 Dec 1994 12:55:16 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA15857; Sat, 3 Dec 94 12:56:27 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14424(7)>; Sat, 3 Dec 1994 12:56:13 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Sat, 3 Dec 1994 12:56:08 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: Re: (IPng) new ICMP draft. In-Reply-To: conta's message of Fri, 02 Dec 94 23:43:27 -0800. <9412030743.AA02755@brigit.zk3.dec.com> Date: Sat, 3 Dec 1994 12:55:54 PST From: Steve Deering Message-Id: <94Dec3.125608pst.12173@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The new ICMP-for-IPv6 is also available from: parcftp.xerox.com/pub/ipng/draft-ietf-ipng-icmp-00.txt for those who want to pick it up before it appears in the internet-drafts repositories (probably not till after IETF). Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Dec 4 12:01:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00802; Sun, 4 Dec 94 12:01:33 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00796; Sun, 4 Dec 94 12:01:24 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA25806; Sun, 4 Dec 1994 11:55:00 -0800 Received: from nbkanata.Newbridge.COM by Sun.COM (sun-barr.Sun.COM) id AA08543; Sun, 4 Dec 94 11:56:12 PST Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1) id AA28987; Sun, 4 Dec 94 14:50:43 EST Received: from mako.newbridge.com by Newbridge.COM (4.1/SMI-4.0) id AA02253; Sun, 4 Dec 94 14:50:38 EST Received: by mako.newbridge.com (4.1/SMI-4.1) id AA12252; Sun, 4 Dec 94 14:56:17 EST Date: Sun, 4 Dec 94 14:56:17 EST From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9412041956.AA12252@mako.newbridge.com> To: flows@research.att.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng) Flow State Loss Behavior Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM (Sorry to send this to two lsts, but it has both an abstract side, and a direct effect on IPv6 Flows) In Craig Partridge's ID, there was a proposed behavior for a router if it had no "flow-state" for the identified flow The proposal was that the datagram would be forwarded using normal datagram routing, and no ToS/QoS. There is an additional problem to be dealt with: As has been found when dealing with soure-routes, if some forwarders can ignore the flow, there is a loop potential. I can think of two obvious solutions: 1) If you ignore the flow information, remove it from the datagram. This is unfortunate, but guaranteed to be safe. 2) Bind flow state not just to the double but to the triple . However, to still prevent loops, if a router received a datagram with flow-id over an "incorrect" interface, and was going to send it out the "flow" interface, it would then have to remove the flow information. Thus, I don't see how this would help us much. Below I will try to describe how a loop can occur, as background. Suppose that from Source A to dstination B, there are two paths, the high-bandwidth path which goes D-E-F-G-H-I-J-K-L, and the low hop-count path which goes D-E-L Furhter suppose that there is a low-bandwidth path between H and D. If H loses flow state, then when it receives the datagram, it will forward it to D. D either obeying the flow, or obeying the normal forwarding rules, will forward it to E. If the flow information is still in the datagram, E will forward it to F, which gives G, H, D, E, ... Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. PS While Noels proposed DMFs help this, I am not confident that one will always avoid the loops even when flows are the underlying mechanism. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Dec 4 14:15:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00851; Sun, 4 Dec 94 14:15:44 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00525; Fri, 2 Dec 94 19:56:11 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id TAA17096; Fri, 2 Dec 1994 19:49:52 -0800 Received: from curtis.ansremote.com by Sun.COM (sun-barr.Sun.COM) id AA26863; Fri, 2 Dec 94 19:50:42 PST Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id WAA00731; Fri, 2 Dec 1994 22:49:11 -0500 Message-Id: <199412030349.WAA00731@curtis.ansremote.com> To: ipng@sunroof.Eng.Sun.COM Cc: curtis@ans.net Subject: (IPng) Using the Flow ID Date: Fri, 02 Dec 1994 22:49:03 -0500 From: Curtis Villamizar Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM All, This not was probably misdirected when it was sent to int-serv a long time ago. I am very concerned that for elastic traffic, connection oriented won't scale and reservations won't be practical except for large transfers that require more than "fair share" bandwidth. The idea here is that in an OCx carrier or IP provider core infrastructure at the border packets are given a FlowID by their entry point into that cloud. If the classifier finds an RSVP reservation, then the packet gets a flow ID that indicates the RSVP reservation. If a packet falls into a link share, then the flow ID indicates the exit point of the core and the link share. If a packet doesn't fall into a RSVP reservation or a link share, then it gets a Flow ID that simply indicates the exit point. The flow ID number is significant for exactly one hop, but after the first packet with a given flow ID, packets after the border the Flow ID number is all that is needed and the (different) Flow ID needed for the next hop is already know. I hope it isn't too late to consider this since I think it would work well. If there is a good technical reason why this is a bad idea, I'd like to know what it is. I haven't had time to even follow IPng closely, but if you are considering what to do with the flow ID, perhaps this idea would be of interest. If it is too late, I'll just shut up. Thanks, Curtis ------- Forwarded Message Received: from interlock.ans.net by home.ans.net with SMTP id AA26356 (5.65c/IDA-1.4.4 for ); Wed, 13 Apr 1994 18:48:05 -0400 Received: from venera.isi.edu by interlock.ans.net with SMTP id AA04785 (InterLock SMTP Gateway 1.1 for ); Wed, 13 Apr 1994 18:52:29 -0400 Received: from interlock.ans.net by venera.isi.edu (5.65c/5.61+local-14) id ; Wed, 13 Apr 1994 15:42:27 -0700 Received: by interlock.ans.net id AA20822 (InterLock SMTP Gateway 1.1 for int-serv@isi.edu); Wed, 13 Apr 1994 18:42:25 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 13 Apr 1994 18:42:25 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 13 Apr 1994 18:42:25 -0400 From: Curtis Villamizar Message-Id: <199404132239.AA117424@foo.ans.net> To: int-serv@ISI.EDU Subject: The use of a locally significant classifier "hint" Date: Wed, 13 Apr 94 18:39:24 -0500 At the Seattle IETF, we discussed the use of a "hint" field in the IPng header. One suggestion was a unique field chosen at random from a large range (ie: 32 bits or more) so that it was likely to be unique. A suggestion that I brought up was the use of a hint which was locally significant. This was discussed only briefly. I promised to get back to the list with some details on the idea. The idea is that policy on how to do classification may be somewhat localized. For example, more localized provider A might grant a subscriber up to X amount of link share credit (units?) of which some percentage can be used toward reservation. A more global provider (one that primarily interconnects more local ones) might grant provider A some link share regardless of how provider A allocates among subscribers. This is closer to the type of relationships between providers today (only today it's more pipe size oriented). Within a provider or some domain of consistent policy, there can be some fairly granularity of packet treatment. A classifier need only classify sufficiently well to obtain the right packet treatment. For example, a packet classifier may be able to classify all packets as the same if they leave the domain at the same point and share a common queueing treatment. If link sharing is on a fairly course basis, there may be a small number of possible locally significant classifications. If a packet is classified at it's entry point it may be given a classification hint number that is only locally significant (significant only to the local router). The first packet to arrive that required a new classification can be assigned a new sequential classification number. When the packet is forwarded to the next hop, if the classification number (the hint) has never been seen from the immendiate source of that packet (the previous hop), the packet must then be classified and a new locally significant hint assigned and the packet can be forwarded further. When a second packet with the same hint, the hint can provide the next hop, packet treatment (which queue), and the replacement value for the hint field. The process continues at each internal hop, with only the first packet matching a particular classification being classified. If at an internal node a new hint may arrive from a previous hop, but after classifying the packet, it is discovered that packets from a another previous hop already match the classification. In this case, a new local classification number is not needed but a new mapping is needed. At the next hop, the classification number is already known so the packet can take the fast path through the router without running the classifier. An example of where this would be useful is the case where a institution funds a specific packet treatment within a service provider for its traffic regardless of the source. (Two concrete examples: NSF funds X bandwidth over a NSP at any link regardless of which regional or source injected the traffic; A corporation funds Y amount of bandwidth regardless of which of its offices injects the traffic). At any bottleneck, the correct packet treatment can be applied without ever having to classify the traffic. Forwarding lookup can actually be much faster since the hint need only point toward the correct exit point and is by definition an integer lookup. If the number of classifications is small, forwarding degenerates to simple table lookup. An advantage of this approach is that within a domain in which classification policy or methodology was consistent, classification generally need only be done at the borders (except for the first packet of a given classification). In current networks the borders are often significantly less loaded than the interior. It is also easier and more cost effective to split the load at a border if the load is due to the aggregation of a great deal of incoming traffic (by splitting into more entry points) if processing power needed for classification becomes an issue. When exiting the claasification domain, the hint can be ignored by the border router of the bordering domain and all packets reclassified if the classification granularity is finer. If the classification granularity is similar (identical classification or more course), the hint can be used in conjunction with the exit point from the new domain, possibly to arrive at a classification more quickly than might occur if the classifier itself were used. If the classification of more global providers (those which concentrate more local providers) is the same or more course than some of the local providers, this technique might become very useful (ie: in NRENspeak, classification might occur at the entry to a regional network and be useable by the NSP without requiring the NSP to rerun the classifier for the majorty of packets). For IPv4, the hint could be held in an IP option. At certain borders the IP option can be removed. This will eliminate the overhead of carrying the option over slow links where link speed is more an issue than classifier speed. For IPng, the question arises of whether it is faster to keep a fixed header size or better to provide an optional field for the reason just cited. For IPv4 (or IPng), avoiding a radix trie lookup of the next hop could easily outweigh the overhead of processing the option field. [aside: Some routers already cache a set of host addresses. This would allow a similar fast access but could cover a much larger number of destinations with the same cache size.] Routers would need configuration knobs to cause generation of an outgoing hint on a particular interface and to cause the incoming hint on a particular interface to be used. Normally both would be set off. For interior routers, both options would be turned on for all interfaces. For most border router both options would be turned on for interior interfaces and off for exterior interfaces. For border routers where the classification was applicable to the adjacent domain or the adjacent domain's classification was applicable, the appropriate option (possibly both of them) could be enabled on external interfaces. Of course some means of determining exit point (gee - BGP and IDRP do this nicely) and specifying how to drive the classifier are needed and have to consistent within the domain. I hope this made sense. I'm afraid I didn't present the idea at all clearly at the meeting. Curtis ------- End of Forwarded Message ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Dec 4 20:24:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00923; Sun, 4 Dec 94 20:24:23 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00917; Sun, 4 Dec 94 20:24:16 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id UAA06591; Sun, 4 Dec 1994 20:17:51 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA03174; Sun, 4 Dec 94 20:18:56 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 5 Dec 94 13:10:49 +0859 From: Masataka Ohta Message-Id: <9412050411.AA04305@necom830.cc.titech.ac.jp> Subject: Re: (IPng) Flow State Loss Behavior To: ipng@sunroof.Eng.Sun.COM Date: Mon, 5 Dec 94 13:10:48 JST Cc: flows@research.att.com In-Reply-To: <9412041956.AA12252@mako.newbridge.com>; from "Joel Halpern" at Dec 4, 94 2:56 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > > (Sorry to send this to two lsts, but it has both an abstract side, and a direct > effect on IPv6 Flows) > > In Craig Partridge's ID, there was a proposed behavior for a router if it > had no "flow-state" for the identified flow The proposal was that the datagram > would be forwarded using normal datagram routing, and no ToS/QoS. > > There is an additional problem to be dealt with: > As has been found when dealing with soure-routes, if some forwarders > can ignore the flow, there is a loop potential. > > I can think of two obvious solutions: > 1) If you ignore the flow information, remove it from the datagram. > This is unfortunate, but guaranteed to be safe. Why unfortunate? As the delivery is by best effort, there is no point in keeping the original flow ID. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 5 02:20:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01017; Mon, 5 Dec 94 02:20:19 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01011; Mon, 5 Dec 94 02:20:06 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id CAA29869; Mon, 5 Dec 1994 02:13:41 -0800 Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA18289; Sun, 4 Dec 94 23:01:48 PST Subject: (IPng) IPv6 Security API To: IPng Mailing list Date: Mon, 5 Dec 1994 02:01:51 -0500 (EST) From: Dan McDonald Cc: ho@cs.arizona.edu, perry@imsi.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9412050701.aa04992@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Here is the draft I mentioned in the IPv6 implementor's meeting. I didn't distribute it widely earlier because it's (IMHO) half-baked at best. Dan =====================(Cut up to and including here.)====================== Network Working Group D. McDonald INTERNET-DRAFT NRL draft-mcdonald-ipv6-sec-api-00.txt Real Soon Now IPv6 Security API for BSD Sockets Status of this Memo 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. This Internet Draft expires on . Internet Drafts 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." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Distribution of this memo is unlimited. Introduction One of the most desirable new features of IPv6 is the security architecture [Atk94a]. The architecture has two main components, authentication [Atk94b] and encapsulating security payload [Atk94c]. Unlike other parts of IPv6, the security architecture has no counterpart in IPv4. These new features generated a need for mechanisms to allow the application to set security parameters, as well as mechanisms to allow the application to be aware of security problems. The BSD sockets interface [LMKQ89] is a commononly used Application Program Interface (API) to Internet protocols. Gilligan, et. al. have shown how sockets can be used with IPv6 [GTB94]. Security needs to be a part of any API for IPv6, and this document attempts to illustrate how sockets can enable security features. Security Concepts Following this are explanations of three important concepts: security association, authentication, and encryption. These McDonald [Page 1] INTERNET-DRAFT IPv6 Security API explanations are included for completeness, and for implementors who have not read the IPv6 Security Architecture documents. Security Association A security association exists from one endpoint to another endpoint. A security association contains several attributes, such as: * Key(s) * Source address * Destination address * Algorithm used (including algorithm mode) * Replay prevention parameters (if needed) * Security association identifier (SAID) Security associations are set up either manually, or through use of a key management protocol. Key management is beyond the scope of this document. It is hard to create and maintain a large security association table with manual key management. Ideally, there should be a separate security association per user-level socket, but this cannot always happen, and even if it does, security associations lie below the transport (e.g. TCP or UDP) level, and must be mapped into sockets in a transport-independent way. Especially in cases of manual key management, two separate user-level sockets may have their data encrypted with the same key, algorithm, and therefore, the same SAID. If more than one user's data is encrypted with the same key, then user-level security is not provided, but system level security is. The IP layer demultiplexes a packet to the appropriate authentication or decryption mechanism on the security association identifier (SAID). No TCP or UDP port numbers or mechanisms are involved in determining which algorithms or keys are used. Ideally a source/destination port/address pair will have unique SAID's going each way, but this is only feasible in the presence of good automated key management. Authentication Authentication is proof that a datagram is entirely accurate, including verifying that a datagram originated with the reported sender. Without authentication, a datagram can be easily forged as McDonald [Page 2] INTERNET-DRAFT IPv6 Security API to conceal its true origins. Any higher-level protocol (e.g. rlogin) that depends on an accurate source addresses should use some form of authentication. Authentication in IPv6 is achieved through the use of the authentication header. The authentication header contains a SAID, data associated with the authentication (such as the result of an MD5 computation), and other mundane header fields. Encryption Encryption scrambles data in such a way that if it was intercepted, no sense could be made of it. Ideally, only the intended recipient of the data knows how to unscramble (decrypt) the data. Without encryption, packets intercepted during intermediate hops in the network can be viewed by undesirable parties. If two communicating parties do not wish to have their exchanged data viewed by others, they should use encryption. Encryption is offered in IPv6 through the encapsulating security payload (ESP) header. The ESP header has two parts, an unencrypted part which contains an SAID and synchronization fields, and an encrypted part which contains other mundane header fields. Systemwide Network Security Level Each machine, or group of machines, on the IPv6 Internet will have a system-wide security level. This security level will be the default security level for newly created AF_INET6 sockets. The security level of a machine has several parameters that need to be set. Each parameter is dependent on there being a security association that supports the parameter. The parameters are (in order of least secure to most secure): AUTHENTICATION (3 settings) * No authentication * Authentication of security-critical packets (e.g. TCP SYN segment) * Authentication of all outbound packets ENCRYPTION (4 settings) * No encryption McDonald [Page 3] INTERNET-DRAFT IPv6 Security API * Encryption of each outbound packet's payload * Encryption of each entire outbound packet inside another packet * First authenticate each outbound packet, then encrypt the entire authenticated outbound packet Again, it is important to note that the system's default security level is meaningless, or weakened, in absence of the appropriate security associations. This means that if the system default has both authentication and encryption turned on, but to a certain machine only an authentication security association exists, then only authentication will be performed between those two machines. How to set a system's security level is beyond the scope of this document. The facilities that provide access to a machine's security association table would probably be the ideal place to put mechanisms to set the systemwide security level. Security Aware Applications Before continuing, an type of application has to be defined. A _security aware_ application is one that is aware that the Internet services below it are using security. _Security unaware_ applications are not aware of underlying security services. This distinction is made because many naive applications, as well as proverbial "quick-and-dirty" ports of older applications, will not expect lack of security to be a problem. A security unaware application should continue to function identically in both secure and insecure environments. Security aware applications, on the other hand, are expected to react intelligently if security problems are encountered. Per Socket Security Level At each socket, the user should have the ability to set his or her security level beyond what the system mandates, provided there are the appropriate security associations. The parameters the user can set are identical to the ones above. If an application makes security requests, even to inspect security values, an application is henceforth treated as a security aware application. Likewise, if an application makes no security requests, it is treated as a security unaware application. For security aware applications, the level of error reporting can be determined by the user application. No security errors are reported McDonald [Page 4] INTERNET-DRAFT IPv6 Security API to security unaware applications. Security aware applications will have errors reported to them by default. The error reporting parameters, and their default values are below: ERROR REPORTING * Report failure packets? (yes/no) For example: Packets that have authentication headers, but fail authentication * Default for security unaware: NO * Default for security aware: YES * Report naked packets? (yes/no) For example: Packets that are supposed to be either authenticated or encrypted, but aren't. * Default for security unaware: NO * Default for security aware: YES * Report paranoid packets? (yes/no) For example: An authenticated packet arrives with an unknown SAID. * Default for security unaware: NO * Default for security aware: YES * Pass up paranoid packets? (yes/no) For example: Should the previous authenticated packet be passed up? * Default for security unaware: NO * Default for security aware: NO The systemwide security level, if more secure, supersedes whatever the user-level socket requests. For example, assume the systemwide security level is set to encrypt packets. If an application requests authentication to a destination that has security associations for both authentication and encryption, then the application's packets will be both authenticated and encrypted. Unlike the systemwide security level, if a socket requests a security service that is unavailable, it will be notified via an error return from one of the socket calls. A security request can be made on a socket before the destination is known. If that happens, then subsequent connect() or sendto() calls may return with an error indicating what kind of security failure occured. (For example, connect() returning with errno set to ENOSAID, indicating no security association exists.) Likewise, if a security request is made on an already connected socket, the request will immediately indicate if there is a problem with the requested security level. Finally, for security unaware applications, the socket's level will default to the system's security level. This allows older McDonald [Page 5] INTERNET-DRAFT IPv6 Security API applications to be moved to IPv6 with a minimum effort. There is a danger that an insecure systemwide security level will render ignorant applications insecure, but as more applications become security aware, or as more systems turn on security by default, this danger will fade. Extensions to the BSD Socket Interface The extensions allowing per socket security take three forms. The first is new socket options which are used by the getsockopt() and setsockopt() calls. The second is new error codes to familiar calls such as connect() and sendto(). The third is using a BSD signal to notify a process of security problems. New Socket Options As in the BSD include file , socket options are #defined to be integers. The comments include the data type expected to be passed in. #define IP_SECLEVEL 0x20 /* int; get/set security level. */ IP_SECLEVEL sets or obtains the security level for a socket. The integer argument is a bitmask of possible values. The low two bits of the integer are for authentication levels. The two bits above the authentication bits indicate what parts of datagrams should be encapsulated in an ESP. The following bitmask values correspond to the settings in the systemwide security section: /* AUTHENTICATION values. */ #define IPSEC_AUTHNONE 0x0 #define IPSEC_AUTHCRIT 0x1 #define IPSEC_AUTHALL 0x2 #define IPSEC_AUTHUNUSED 0x3 /* Unused bit combination. May be used later. */ /* ENCAPSULATING SECURITY values. */ #define IPSEC_ESPNONE 0x0 #define IPSEC_ESPPAYLOAD 0x4 #define IPSEC_ESPPACKET 0x8 #define IPSEC_ESPAUTHPACKET 0xC If the IP_SECLEVEL socket option is set, error reporting will be turned on. #define IP_SECERR 0x21 /* int; get/set error reporting. */ McDonald [Page 6] INTERNET-DRAFT IPv6 Security API IP_SECERR sets or obtains the security error reporting properties of a given socket. The integer argument is a bitmask, with the low four bits answering the yes/no questions posed in the per socket security section. The bitmask values are: /* ERROR REPORTING values */ #define IPSECERR_REPFAIL 0x1 #define IPSECERR_REPNAKED 0x2 #define IPSECERR_REPPARANOID 0x4 #define IPSECERR_PASSPARANOID 0x8 New Error Codes For security aware applications, several new error codes are available. These error codes affect various system calls, and a list of calls that might generate that error code follows each error code. ENOKEY -- No key/security association exists Affects: setsockopt() For security aware applications: accept(), bind(), connect(), sendto(), sendmsg(), recvfrom(), recvmsg() ENOKEY indicates that a level of security cannot be granted because no security association, hence no key, exists for that level of security. For example, an application requests authentication, then does a connect() to a host which has no authentication security assocation. ENOKEY is returned if the FULL REQUESTED security level cannot be met. It is currently undefined whether or not partially fufilled requests are granted if ENOKEY is returned. It is also currently undefined whether or not a connection is broken if ENOKEY is returned. EKEYEXP -- Key lifetime has expired Affects: accept(), bind(), connect(), read(), readv(), recv(), recvfrom(), recvmsg(), select(), send(), sendto(), sendmsg(), write(), writev() EKEYEXP indicates that the key for the security association has expired. Keys often have finite lifetimes, because indefinite use of a key allows an adversary an indefinite amount of time to break the cryptosystem that key is a part of. Instant Security Violation Notification [NB. This is a controversial section. These could be done in McDonald [Page 7] INTERNET-DRAFT IPv6 Security API error codes instead, but would be less "up-to-date". Also the IP_SECEXCEP and IP_SECMSG options could be moved to the socket options section.] In earlier sections, several error conditions, and mechanisms to enable error reporting, were defined. This section discusses the method for implementing error reporting. A UNIX signal, SIGURG, will be sent to the owning process of a socket that has a security error occur. To determine which of the three possible error sources, failure packets, naked packets, or paranoid packets, generated the signal, another (read-only) socket option must be implemented. This socket option is IP_SECEXCEPT. #define IP_SECEXCEPT 0x22 /* int; get cause of SIGURG. */ IP_SECEXCEPT allows a process to determine if a security violation caused a SIGURG to be sent to it. The integer returned will contain a code indicating the cause, and possibly suggesting further action. The codes are: /* SECURITY EXCEPTION values */ #define IPSECEXC_NONE 0x0 /* Check for other causes of SIGURG */ #define IPSECEXC_FAIL 0x1 /* Failed auth., use IP_SECMSG */ #define IPSECEXC_NAKED 0x2 /* Naked packet, use IP_SECMSG */ #define IPSECEXC_PARANOID 0x3 /* Paranoid packet, use IP_SECMSG */ The first return value indicates that something other than security caused the SIGURG to be sent. Often this is the TCP out-of-band data mechanism. The remaining return values indicate that a retrievable security violation has occured. An example of an unretrievable security violation is an decryption failure. It is assumed a machine's operating system will log all security problems, whether they can be reported to a user or not (see Security Considerations). Retrieving additional information about a security violation is possible through the IP_SECMSG socket option. Like IP_SECEXCEPT, IP_SECMSG is a read-only socket option. #define IP_SECMSG 0x23 /* ipv6_secinfo; Get info on sec. violation */ IP_SEGMSG fills in an ipv6_secinfo structure, which contains information on the datagram. McDonald [Page 8] INTERNET-DRAFT IPv6 Security API struct ipv6_secinfo /* Assume sizeof(u_long) == 4 bytes sizeof(u_short) == 2 bytes sizeof(u_char) == 1 byte Network order unless otherwise stated */ { u_short isi_attributes; /* Bitmask of message attributes (host order): 0x1 --> Authentication of datagram 0x2 --> Encapsulation of payload 0x4 --> Encapsulation of datagram 0x8 --> Encapsulation of authenticated datagram */ u_char isi_redsrlen; /* Length of red source route */ u_char isi_blksrlen; /* Length of black source route */ /* BLACK information is for a datagram that is INSIDE an encapsulating security payload. */ u_long isi_blkflowid; /* Black flow id */ struct ipv6_addr isi_blksrc; /* Black source address */ struct ipv6_addr isi_blkdst; /* Black destination address */ u_long isi_blksaid; /* Black SAID (for auth.) */ /* RED infromation is the outlying datagram itself. */ u_long isi_redflowid; /* Red flow id */ struct ipv6_addr isi_blksrc; /* Red source address */ struct ipv6_addr isi_blkdst; /* Red destination address */ u_long isi_redsaid; /* Red source address */ u_long isi_nexthdr; /* Next header id. Put in u_long for padding purposes. Host order. */ struct ipv6_addr isi_srcrtes[1]; /* Red source route, followed by black, if user supplies enough room. Sizes given in fields above. */ }; For all address fields, the address 0000::0000 (unspecified according to [Hin94] indicates an unknown value or a value that does not exist. Likewise, all flow ids are 0 if they are unknown or do not exist. The passed-in structure should have room for source routes, if source routes are anticipated. It is currently undefined what happens if there is not enough room to place source routes at the end of the McDonald [Page 9] INTERNET-DRAFT IPv6 Security API structure. Open Questions * Any sentence with the word undefined in it needs to be fixed. * If a socket can use one of many available security associations, which one does it use? Where is the selection made? (Kernel? Yet another sockopt?) * What if I want "the best available security"? This is important for a program like inetd, which dispatches new sockets to other programs. Security Considerations It is assumed that the operating system will keep an audit log of ALL IPv6 security problems. Many IPv6 security problems cannot be reported to a particular socket, failed decryption being the best example. Comprehensive audit trails is the only way to make sure all security violations are reported. Setting the systemwide security level should have proper protections, so random users cannot downgrade the systems level to a point where unwanted packets can reach a system. If two sockets happen to use the same security association, it is possible for one socket to rig itself to read data bound for the other socket. Acknowledgements Thanks to Ran Atkinson for hearing and answering many questions that came up during the writing of this document. Thanks to Sean O'Malley for asking some very tough questions during the early stages of this draft. Thanks to Bao Phan and Brian Adamson for useful input during the early stages of this draft. References [Atk94a] Atkinson, Randall, "IPv6 Security Architecture", Internet Draft. [Atk94b] Atkinson, Randall, "IPv6 Authentication Header", Internet Draft. [Atk94c] Atkinson, Randall, "IPv6 Encapsulating Security Payload", Internet Draft. McDonald [Page 10] INTERNET-DRAFT IPv6 Security API [Hin94] Hinden, Bob (Editor), "IPv6 Routing and Addressing", Internet Draft. [GTB94] Gilligan, Robert E., Thomson, Susan, and Bound, Jim, "IPv6 Program Interfaces for BSD Systems", Internet Draft [LMKQ89] Leffler, Samuel J., McKusick, Marshall Kirk, Karels, Michael J., and Quarterman, John S., "The Design and Implementation of the 4.3BSD UNIX Operating System", Addison-Wesley, 1989. Author's Address Daniel L. McDonald United States Naval Research Laboratory Code 5544 4555 Overlook Ave. SW Washington, DC 20375 Phone: (202) 404-7122 E-mail: danmcd@itd.nrl.navy.mil McDonald [Page 11] ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 5 02:41:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01085; Mon, 5 Dec 94 02:41:47 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01079; Mon, 5 Dec 94 02:41:35 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id CAA01495; Mon, 5 Dec 1994 02:35:10 -0800 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AB12329; Mon, 5 Dec 94 02:36:20 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) IPv6 Security API To: ipng@sunroof.Eng.Sun.COM Date: Mon, 5 Dec 1994 10:36:11 +0100 (GMT) In-Reply-To: <9412050701.aa04992@sundance.itd.nrl.navy.mil> from "Dan McDonald" at Dec 5, 94 02:01:51 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > A UNIX signal, SIGURG, will be sent to the owning process of a socket > that has a security error occur. To determine which of the three > possible error sources, failure packets, naked packets, or paranoid > packets, generated the signal, another (read-only) socket option must > be implemented. This socket option is IP_SECEXCEPT. Well I can see why this would be controversial. Since it can be set up so that a read terminates with this error when it occurs, and a select() returns an exception case what is the problem. Secondly and I think very importantly in this context BSD signals are unreliable. You might take a SIGURG, read out of bound data miss the security violation event just after it and continue. Thats probably a very small window but if it exists it will be exploited. > The passed-in structure should have room for source routes, if source > routes are anticipated. It is currently undefined what happens if The obvious thing would be not to fill them in. People won't always want full detail. > * If a socket can use one of many available security associations, > which one does it use? Where is the selection made? (Kernel? Yet > another sockopt?) At the very least encryption keys may need to be registered per socket. It's all very well having encryption but not being able to keep the keys only usable by suitable applications will weaken their value. For example encrypted routing rules may be useful, but if its a host level crypt then people on that host can still read the data. Another missing security option is some kind of port reserve option to ensure nobody can ever share the socket. > * What if I want "the best available security"? This is important > for a program like inetd, which dispatches new sockets to other > programs. Inetd seems to make problems easily solved. Suppose inet.conf had a security level in it. Then inetd can pass applications sockets of appropriate security to match the administrators policy choice. > It is assumed that the operating system will keep an audit log of ALL > IPv6 security problems. Many IPv6 security problems cannot be > reported to a particular socket, failed decryption being the best > example. Comprehensive audit trails is the only way to make sure all > security violations are reported. Comprehensive audit trails are a nice myth for most people. Worse still the 'security bomb' will no doubt become popular (eg a ping -f from a cracked host with an invalid authentication key deliberately set up). Logging will need some thought for most users. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 7 23:11:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02776; Wed, 7 Dec 94 23:11:10 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02770; Wed, 7 Dec 94 23:11:03 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id XAA14880; Wed, 7 Dec 1994 23:04:29 -0800 Received: from nms.etri.re.kr by Sun.COM (sun-barr.Sun.COM) id AA10822; Wed, 7 Dec 94 23:05:40 PST Received: from cote.etri.re.kr by nms.etri.re.kr (4.1/NMS-0.1) id AA22597; Thu, 8 Dec 94 16:06:46 KST Received: from pec.etri.re.kr (spring.etri.re.kr) by cote.etri.re.kr (4.1/SMI-4.1) id AA06771; Thu, 8 Dec 94 16:04:49 KST Received: from piero.etri.re.kr by pec.etri.re.kr (4.1/SMI-4.1) id AA09512; Thu, 8 Dec 94 16:01:03 KST Received: by piero.etri.re.kr (4.1/SMI-4.1) id AA03489; Fri, 9 Dec 94 05:09:44 KST From: sykim@piero.etri.re.kr (Su-Yeon Kim) Message-Id: <9412082009.AA03489@piero.etri.re.kr> Subject: (IPng) Source code for TCP/IP in Windows NT To: end2end-interest@isi.edu Date: Fri, 9 Dec 94 5:09:43 KST Cc: ipng@sunroof.Eng.Sun.COM X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hello Guys? Could you tell me the place or company I can get a source code for TCP/IP in Windows NT? Thanks in advance. Su-Yeon Kim -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 12 10:09:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04657; Mon, 12 Dec 94 10:09:54 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04520; Mon, 12 Dec 94 06:03:22 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id FAA08574; Mon, 12 Dec 1994 05:58:00 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA13253; Mon, 12 Dec 94 05:57:57 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA10892; Mon, 12 Dec 1994 14:57:53 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA22944; Mon, 12 Dec 1994 14:57:49 +0100 Message-Id: <9412121357.AA22944@dxcoms.cern.ch> Subject: (IPng) Summary of NOSI BOF To: ipng@sunroof.Eng.Sun.COM (IPv6 List), nosi@sunroof.Eng.Sun.COM Date: Mon, 12 Dec 1994 14:57:49 +0100 (MET) From: "Brian Carpenter CERN-CN" X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [Sent as an FYI to the IPng wg and NOSI lists. Full minutes are pending. Discussion on the NOSI list please. To join, send email to majordomo@sunroof.eng.sun.com with "subscribe nosi" as the message body.] -- Summary of Next Generation and OSI BOF (NOSI) held 8 December 1994 Brian Carpenter brian@dxcoms.cern.ch About 35 people attended the BOF. Presentations were made by Brian Carpenter (summary of possible requirements, scenarios and mechanisms); Ross Callon (outline of ABUT transition plan); Jim Bound, Jack Houldsworth and Dan Harrington (three variants of how to carry NSAPs in IPv6 headers). Rapid agreement was reached that three mechanisms should be pursued in any case: - RFC 1006bis (ISO transport over TCP, small mods to existing RFC). - Classic CLNP over IPv6 tunnels (NextHeader = CLNP; probably no new document needed, at most a very short RFC) - TP4 over IPv6 (requires some real work, volunteer needed) It was also agreed that Ross Callon should write up the ABUT outline. There was a lot of discussion about the need for and the details of carrying NSAPs in IPv6 packets. The ideal would be to find a way to combine the best aspects of the three proposals. It was agreed to continue this discussion on the NOSI list in the expectation of reaching closure at the next IETF in a second BOF. Also the IANA is looking at Alan Lloyd's and Jack Houldsworth's proposals to allocate some IPv6 address space as genuine NSAP space. -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 12 13:43:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04846; Mon, 12 Dec 94 13:43:29 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04840; Mon, 12 Dec 94 13:43:22 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id NAA18125; Mon, 12 Dec 1994 13:37:57 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA02125; Mon, 12 Dec 94 13:37:57 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14471(6)>; Mon, 12 Dec 1994 13:37:38 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Mon, 12 Dec 1994 13:37:24 -0800 To: ipng@sunroof.Eng.Sun.COM, ngtrans@sunroof.Eng.Sun.COM, addrconf@cisco.com Cc: deering@parc.xerox.com, rcallon@wellfleet.com, hinden@Eng Subject: (IPng) interim IPng WG meeting Date: Mon, 12 Dec 1994 13:37:12 PST From: Steve Deering Message-Id: <94Dec12.133724pst.12173@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [Most of you will get duplicates of this message, but since I am not sure that everyone on the ngtrans or addrconf lists is also on the ipng list, I am posting to all three lists. Please follow up to ipng only.] The chairs of the IPng WG would like to schedule an interim meeting of the working group in February, for two purposes: (1) to act as a deadline for getting all the base documents up-to-date with all of this past week's agreements, and (2) to decide, for each document, whether we consider it in good enough shape to submit as a Proposed Standard and, if not, to fix it. The hope is that the meeting will result in a decision to submit all of the initial set of docs to the RFC editor. We propose holding the meeting at Xerox PARC in Palo Alto, CA for two full days, Feb 9 and 10. If too many people find those dates unacceptable, Feb 2 and 3 is a fallback alternative. If you would like to attend, please send me a message, saying whether or not you can make it on 9 & 10, or only on 2 & 3. The chairs of the ngtrans and addrconf WGs may also wish to have their groups meet at the same time and place. I would propose not splitting into separate meeting rooms, but simply assigning time on the agenda of the IPng meeting to cover the ngtrans and addrconf documents. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 13 08:21:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05503; Tue, 13 Dec 94 08:21:43 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05497; Tue, 13 Dec 94 08:21:36 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id IAA15920; Tue, 13 Dec 1994 08:16:11 -0800 Received: from postoffice3.mail.cornell.edu by Sun.COM (sun-barr.Sun.COM) id AA19106; Tue, 13 Dec 94 08:16:11 PST Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id LAA19529 for ; Tue, 13 Dec 1994 11:16:09 -0500 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 Dec 1994 11:16:15 -0500 To: ipng@sunroof.Eng.Sun.COM From: Scott Brim Subject: Re: (IPng) interim IPng WG meeting Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM mbone broadcast? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 13 10:11:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05635; Tue, 13 Dec 94 10:11:03 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05276; Mon, 12 Dec 94 23:42:10 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id XAA27464; Mon, 12 Dec 1994 23:36:46 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA24325; Mon, 12 Dec 94 23:36:45 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA07717; Tue, 13 Dec 1994 08:36:43 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA24462; Tue, 13 Dec 1994 08:36:42 +0100 Message-Id: <9412130736.AA24462@dxcoms.cern.ch> Subject: Re: (IPng) interim IPng WG meeting To: ipng@sunroof.Eng.Sun.COM Date: Tue, 13 Dec 1994 08:36:41 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <94Dec12.133724pst.12173@skylark.parc.xerox.com> from "Steve Deering" at Dec 12, 94 01:37:12 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, I agree that you need the interim meeting. Please assure us that it will be MBONEd. Also it would help Europeans if you could bear to start real early in the morning (or replay the MBONE session starting at midnight PST). Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 13 11:03:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05690; Tue, 13 Dec 94 11:03:29 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05684; Tue, 13 Dec 94 11:03:21 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id KAA01682; Tue, 13 Dec 1994 10:57:58 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AB19495; Tue, 13 Dec 94 10:53:19 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14693(1)>; Tue, 13 Dec 1994 10:51:01 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Tue, 13 Dec 1994 10:50:52 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com, rcallon@wellfleet.com, hinden@Eng Subject: (IPng) forwarded message, re IPv6 address plan Date: Tue, 13 Dec 1994 10:50:49 PST From: Steve Deering Message-Id: <94Dec13.105052pst.12173@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Here is a message I got from Geert Jan de Groot, forwarded with permission. My brief response to him is included at the end. Steve ------------- To: deering@parc.xerox.com, rcallon@wellfleet.com, hinden@eng.sun.com From: Geert Jan de Groot Subject: Re: (IPng) interim IPng WG meeting Date: Tue, 13 Dec 1994 09:40:31 -0800 On Mon, 12 Dec 1994 13:37:12 PST Steve Deering wrote: > The chairs of the IPng WG would like to schedule an interim meeting of the > working group in February, for two purposes: > > (1) to act as a deadline for getting all the base documents > up-to-date with all of this past week's agreements, and > > (2) to decide, for each document, whether we consider it in > good enough shape to submit as a Proposed Standard and, > if not, to fix it. One of the documents that is *missing* is a document on address space assignment policy. This document would define how much address space should be assigned to an organisation of size x. This is more difficult than one thinks. There is no such thing for IP4, except RFC1466 which isn't complete. Also, RFC1715 touches the subject but doesn't provide a good answer. Since address space depletion is one of the primary reason to have IP6 started, I think that a document like this would be a *requirement*; I feel that the spec would be incomplete on essential points without it. An assignment criteria document would define: - What the step size is for IP6 assignments (1 bit at a time, 4 bits at a time, more?) - How many hosts would be 'worth' how many address bits. - Will every assignment be at least a 80-byte prefix, to allow for hostnumber assignment using the MAC address, or will more efficient methods be used (this of course directly affects IP6 ALE. There might be some work during last IETF; I was not allowed to go and the multicast sessions were not very usable this time so I can't tell) - What is the timescale that we look at for assignments? i.e. someone claiming to build a 1000000 host network in 10 years, should he get the full address space for that now? - How well should a request be documented? Should someone who claims to build a 10000 host network get a 112-bit (108-bit? 100?)-bit prefix just for mentioning 10000, or is he required to document this and how deep? How about a 1000-host network? a 100000-host network? - Must an assignment be registered in a database at all? (if true, who will fund that database? The NSF probably does not pay like they did until now? How about maintenace?) Or do we go for a scheme like Ethernet, where we know that an address is unique but will never know to whom it belongs to? (this is easier with the new provider-based CIDR mechanisms, but there's an awful lot of private connectivity which is not using the Internet at all) There are some documents talking about assignments from a prefix point of view (i.e. done with routing in mind). I don't know of any activity that looks at the 'middle' bits: how many bits would be part of the network part, how many of the host part. I realize that this is one of the less challenging technical things but it has to be done. I am not familiar with any activity in this area; do you know of other people working on this? Thanks, Geert Jan ------------- To: Geert Jan de Groot Subject: Re: (IPng) interim IPng WG meeting Date: Tue, 13 Dec 1994 10:05:47 -0800 From: Steve Deering Geert Jan, The first attempt to specify the answers to some of your excellent questions is draft-rekhter-IPv6-address-format-00.txt, by Rekhter and Lothberg. It does not (yet) cover all of your concerns. Yakov also agreed to revise parts of it in response to comments this week in San Jose, so there should be a new version some time soon. Do you mind if I forward your message to the IPng list? Steve ------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 13 11:14:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05715; Tue, 13 Dec 94 11:14:07 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05709; Tue, 13 Dec 94 11:13:59 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA02828; Tue, 13 Dec 1994 11:08:35 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA21624; Tue, 13 Dec 94 11:08:12 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14668(4)>; Tue, 13 Dec 1994 11:05:22 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Tue, 13 Dec 1994 11:05:09 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: (IPng) Re: interim IPng WG meeting In-Reply-To: deering's message of Mon, 12 Dec 94 13:37:12 -0800. <94Dec12.133724pst.12173@skylark.parc.xerox.com> Date: Tue, 13 Dec 1994 11:04:56 PST From: Steve Deering Message-Id: <94Dec13.110509pst.12173@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM A couple people have asked that the interim IPng WG meeting at PARC be multicast on the MBone. Will do. (But please don't expect MBone participation to serve as an acceptable substitute for attendance in person, if the latter is possible.) Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 13 18:14:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06115; Tue, 13 Dec 94 18:14:48 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06109; Tue, 13 Dec 94 18:14:40 PST Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id SAA18062; Tue, 13 Dec 1994 18:09:17 -0800 Received: by bobo.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id SAA13795; Tue, 13 Dec 1994 18:09:06 -0800 Date: Tue, 13 Dec 1994 18:09:06 -0800 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199412140209.SAA13795@bobo.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) interim IPng WG meeting Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I plan on attending and Feb 9 and 10 are fine. (2nd and 3rd are fine as well.) Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 13 19:29:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06202; Tue, 13 Dec 94 19:29:27 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06196; Tue, 13 Dec 94 19:29:20 PST Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id TAA19689; Tue, 13 Dec 1994 19:23:54 -0800 Received: by bobo.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id TAA13863; Tue, 13 Dec 1994 19:23:40 -0800 Date: Tue, 13 Dec 1994 19:23:40 -0800 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199412140323.TAA13863@bobo.Eng.Sun.COM> To: bill.simpson@um.cc.umich.edu Subject: (IPng) discovery: half-link problem Cc: ipng@sunroof Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, Do you have a reference to the amateur radio routing protocol that was the base for the half-link solution in IPv6 discovery? The specs are notably empty of any references. It probably makes sense to provide an overview of the half-link solution in one of the discovery specs (so that you don't end up explaining it at every meeting), Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 13 20:19:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06286; Tue, 13 Dec 94 20:19:35 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06280; Tue, 13 Dec 94 20:19:28 PST Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id UAA20617; Tue, 13 Dec 1994 20:14:04 -0800 Received: by bobo.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id UAA00436; Tue, 13 Dec 1994 20:13:59 -0800 Date: Tue, 13 Dec 1994 20:13:59 -0800 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199412140413.UAA00436@bobo.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng) discovery: 2 vs. 4 packets Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At Friday's WG meeting there was a discussion whether discovery should be able to instantiate next-hop state on both ends of a "conversation" using 2 or 4 discovery packets. The discovery spec states that the receiver of a solicitation does not record the source IPv6 address + mac address in the next hop cache resulting in 4 discovery packets to set up both ends. I claimed that ARP does record the source address mapping in the arp cache when the node is the target of the ARP request. Many people disagreed so I went back and looked at RFC 826. Below are some quotes from RFC 826 that clearly show that ARP does handle the case in question with 2 arp packets. I also checked some common implementations. All these implementations create an ARP entry for the source when they are the target of the arp request (unless I'm completely misunderstanding the source): BSD 4.3 BSD 4.3 Reno BSD 4.4 Lite SunOS 4.1.3 SunOS 5.X Thus if we want IPv6 discovery to perform no worse than ARP we need to be able to instantiate next-hop state on both ends using 2 discovery packets on an Ethernet. We also need to make the subnets subject to the half-link problem work. Presumably that could be handled by the nodes being aware that a link is subject to the half-link problem and employ modified/extended algorithms for those links. (I think the nodes already need to know whether or not to include the system-heard extension.) Erik ------------ >From RFC 826: In the packet reception algorithm: ?Am I the target protocol address? Yes: If Merge_flag is false, add the triplet to the translation table. Later in the same section it says: Notice that the triplet is merged into the table before the opcode is looked at. This is on the assumption that communcation is bidirectional; if A has some reason to talk to B, then B will probably have some reason to talk to A. Notice also that if an entry already exists for the pair, then the new hardware address supersedes the old one. Related Issues gives some motivation for this. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 14 12:02:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06741; Wed, 14 Dec 94 12:02:15 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06711; Wed, 14 Dec 94 12:01:36 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA10462; Wed, 14 Dec 1994 06:55:15 -0800 Received: from europe.std.com by Sun.COM (sun-barr.Sun.COM) id AA01456; Wed, 14 Dec 94 06:55:16 PST Received: from world.std.com by europe.std.com (8.6.8.1/Spike-8-1.0) id JAA15149; Wed, 14 Dec 1994 09:55:15 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA18137; Wed, 14 Dec 1994 09:55:25 -0500 Date: Wed, 14 Dec 1994 09:55:25 +0001 (EST) From: Peter Loshin Subject: (IPng) Request for Comments (for magazine article) To: ipng@sunroof.Eng.Sun.COM Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Please forgive me if this an inappropriate forum for this question, but I'm pretty sure the people with the answers are here. PC Magazine/Network edition assigned me the task of writing a 'Technology Spotlight" on IPng. I've read the RFCs, looked at the archives on parcftp.xerox.com, and checked out playground.sun.com. Any comments or brief descriptions of how IPng will affect the average user would be very much appreciated. My biggest questions include: - Benefits (beyond expansion of address space; ie, routing) - Timetables (specifications, products - when are they expected?) - Impacts (on end-users, network administrators, service providers) Other questions: - IS CDIR actually being implemented? Are vendors supporting it? - What is NSAP? Thanks very much (in advance) for any help you can offer; of course, please send any comments to me by e-mail (you can also phone me at 1-617-738-1125) and if desired I will summarize my findings to the list. My deadline is the end of the week (12/16). -Peter Loshin peter@world.std.com POB 1890 Brookline, MA 02146 USA ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 14 12:02:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06750; Wed, 14 Dec 94 12:02:36 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06712; Wed, 14 Dec 94 12:01:37 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id HAA11357; Wed, 14 Dec 1994 07:10:57 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA03605; Wed, 14 Dec 94 07:10:58 PST Received: from relay.imsi.com by wintermute.imsi.com id KAA23596 for ; Wed, 14 Dec 1994 10:10:51 -0500 Received: from snark.imsi.com by relay.imsi.com id KAA22756 for ; Wed, 14 Dec 1994 10:10:50 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA13900; Wed, 14 Dec 94 10:10:50 EST Message-Id: <9412141510.AA13900@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) discovery: 2 vs. 4 packets In-Reply-To: Your message of "Tue, 13 Dec 1994 20:13:59 PST." <199412140413.UAA00436@bobo.Eng.Sun.COM> X-Reposting-Policy: redistribute only with permission Date: Wed, 14 Dec 1994 10:10:49 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Erik Nordmark says: > I claimed that ARP does record the source address mapping in the arp > cache when the node is the target of the ARP request. Many people > disagreed so I went back and looked at RFC 826. > > Below are some quotes from RFC 826 that clearly show that ARP does > handle the case in question with 2 arp packets. I claimed otherwise during the meeting, but when I ran off to test (actually, I called someone up and asked them to test) I discovered that I was wrong. I just re-confirmed that result -- it seems that most implementations do indeed seem to cache the mapping when they are the subject of the request. Here is what happens when you do a trace of the communication between two SunOS 4.1.3 machines with dry arp caches. (I did a ping from Hooves to Equus if that isn't obvious from this trace:) ---- # etherfind between equus hooves Using interface le0 icmp type lnth proto source destination src port dst port 60 arp hooves equus 60 arp equus hooves 98 icmp hooves equus echo 98 icmp equus hooves echo reply ---- Please note that I make no claims as to what the IPv6 behavior should be -- I'm only making claims about what SunOS 4.1.3 actually does. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 14 12:08:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06799; Wed, 14 Dec 94 12:08:47 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06793; Wed, 14 Dec 94 12:08:36 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id EAA04705; Wed, 14 Dec 1994 04:22:03 -0800 Received: from nero.dcrc.com ([131.226.3.20]) by Sun.COM (sun-barr.Sun.COM) id AA16753; Wed, 14 Dec 94 04:21:55 PST Received: by nero.dcrc.com (4.1/1.34) id AA18809; Wed, 14 Dec 94 07:21:44 EST Date: Wed, 14 Dec 94 07:21:44 EST From: mad@nero.dcrc.com (Mike Davis) Message-Id: <9412141221.AA18809@nero.dcrc.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <199412140209.SAA13795@bobo.Eng.Sun.COM> (nordmark@jurassic-248.Eng.Sun.COM) Subject: Re: (IPng) interim IPng WG meeting Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I'm planning on being there on either date. 2/9 - 2/10 are better. -mad - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + Mike Davis + Do not use the return address + + Penril Datability Networks + Use mike@dss.com + + 190 North Main Street +- -- -- -- -- -- -- -- -- -- -- -+ + Natick, MA 01760 + assume the smiley + - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 14 14:20:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07048; Wed, 14 Dec 94 14:20:43 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07042; Wed, 14 Dec 94 14:20:36 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA20363; Wed, 14 Dec 1994 14:15:09 -0800 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA27366; Wed, 14 Dec 94 14:11:07 PST Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA07471; Wed, 14 Dec 94 16:17:24 EST Received: from andover.wellfleet by wellfleet (4.1/SMI-4.1) id AA18558; Wed, 14 Dec 94 16:18:11 EST Date: Wed, 14 Dec 94 16:18:11 EST From: dimitry_haskin@wellfleet.com (Dimitry Haskin) Message-Id: <9412142118.AA18558@wellfleet> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi, It was decided at the San Jose's IETF to increase the minimum link MTU to 1500 bytes. The MTU for IEEE 802.3 encapsulation is 1492 bytes. Does it mean that it has been also decided not to support IPv6 over 802.3? If so, it probably should be explicitly stated in the IPv6 spec. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 14 14:42:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07075; Wed, 14 Dec 94 14:42:53 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07069; Wed, 14 Dec 94 14:42:45 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA22369; Wed, 14 Dec 1994 14:37:17 -0800 Received: from alink-gw.apple.com by Sun.COM (sun-barr.Sun.COM) id AA00720; Wed, 14 Dec 94 14:32:29 PST Received: from federal-excess.apple.com by alink-gw.apple.com with SMTP (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA26636; Wed, 14 Dec 94 14:31:53 -0800 for ipng@sunroof.eng.sun.com Received: from lilith.lansys.apple.com by federal-excess.apple.com (5.0/1-Nov-1994-eef) id AA09521; Wed, 14 Dec 1994 14:30:39 +0800 for ipng@sunroof.eng.sun.com Received: (justin@localhost) by lilith.lansys.apple.com (8.6.9/A/UX 3.1) id OAA06679; Wed, 14 Dec 1994 14:32:09 -0800 Date: Wed, 14 Dec 1994 14:32:09 -0800 From: "Justin C. Walker" Message-Id: <199412142232.OAA06679@lilith.lansys.apple.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: Dimitry Haskin's message of Wed, 14 Dec 94 16:18:11 EST <9412142118.AA18558@wellfleet> Subject: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> It was decided at the San Jose's IETF to increase the minimum >> link MTU to 1500 bytes. The MTU for IEEE 802.3 encapsulation is 1492 bytes. >> >> Does it mean that it has been also decided not to support IPv6 over 802.3? >> If so, it probably should be explicitly stated in the IPv6 spec. I asked this after the Friday AM meeting, in a "hallway" conversation. The implication is that we use "Ethernet" encapsulation, not 802.3. It's worth mentioning in the spec, I spose. Regards, Justin Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | They sentenced me to 20 years Apple Business Systems | of boredom Apple Computer, Inc. | For trying to change the system 10500 North De Anza Blvd | from within Cupertino, CA 95014 | LC *---------------------------------------*------------------------------------* ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 14 15:29:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07187; Wed, 14 Dec 94 15:29:42 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07181; Wed, 14 Dec 94 15:29:35 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id PAA27436; Wed, 14 Dec 1994 15:24:08 -0800 Received: from amdext.amd.com by Sun.COM (sun-barr.Sun.COM) id AA11657; Wed, 14 Dec 94 15:23:19 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA24277 (5.67a/IDA-1.5+AMD for ); Wed, 14 Dec 1994 15:22:37 -0800 Received: from brahms.amd.com by amdint.amd.com with SMTP id AA25174 (5.67a/IDA-1.5+AMD for ); Wed, 14 Dec 1994 15:22:37 -0800 Received: from angelo.amd.com by brahms.amd.com (4.1/AMDSN-1.18) id AA00715; Wed, 14 Dec 94 15:22:22 PST Received: by angelo.amd.com (4.1/AMDC-1.18) id AA24676; Wed, 14 Dec 94 15:22:34 PST From: David.Roberts@amd.com (Dave Roberts) Message-Id: <9412142322.AA24676@angelo.amd.com> Subject: Re: (IPng) Minimum link MTU of 1500 To: ipng@sunroof.Eng.Sun.COM Date: Wed, 14 Dec 1994 15:22:33 -0800 (PST) In-Reply-To: <199412142232.OAA06679@lilith.lansys.apple.com> from "Justin C. Walker" at Dec 14, 94 02:32:09 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I asked this after the Friday AM meeting, in a "hallway" > conversation. The implication is that we use "Ethernet" > encapsulation, not 802.3. It's worth mentioning in the spec, I spose. > > Regards, > > Justin Ummm... what was the reason for preferring Ethernet to 802.3? Ignoring the obvious usage split, it still seems a bit punative to require those using 802.3 to implement link-level fragmentation for a gain of only a few bytes per transfer. Or perhaps I'm confused... Dave Roberts Advanced Micro Devices, Inc. I/O and Network Products Division david.roberts@amd.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 14 18:01:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07339; Wed, 14 Dec 94 18:01:35 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07333; Wed, 14 Dec 94 18:01:23 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id RAA13015; Wed, 14 Dec 1994 17:55:57 -0800 Received: from ncc.ripe.net by Sun.COM (sun-barr.Sun.COM) id AA02691; Wed, 14 Dec 94 14:44:38 PST Received: from belegen.ripe.net by ncc.ripe.net with SMTP id AA11574 (5.65a/NCC-2.14); Wed, 14 Dec 1994 23:43:24 +0100 Message-Id: <9412142243.AA11574@ncc.ripe.net> To: ipng@sunroof.Eng.Sun.COM From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Wed, 14 Dec 1994 16:18:11 EST." <9412142118.AA18558@wellfleet> Date: Wed, 14 Dec 1994 23:43:23 +0100 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Wed, 14 Dec 94 16:18:11 EST Dimitry Haskin wrote: > It was decided at the San Jose's IETF to increase the minimum > link MTU to 1500 bytes. The MTU for IEEE 802.3 encapsulation is 1492 bytes. > > Does it mean that it has been also decided not to support IPv6 over 802.3? > If so, it probably should be explicitly stated in the IPv6 spec. I hope this is not true. I cannot recall this decision being made via the mailing list; locking out people that were not allowed to attend doesn't seem good practice to me. A 1500 byte MTU will do very bad things on slow serial links. The arguments against are well known. If this decision was indeed made in San Jose, I would like to see consensus on this via the mailing list too. For the record, but it's probably clear by now, I think that this is a bad decision. Geert Jan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 14 22:22:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07444; Wed, 14 Dec 94 22:22:28 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07438; Wed, 14 Dec 94 22:22:16 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id WAA25848; Wed, 14 Dec 1994 22:16:49 -0800 Received: from tenet.ICSI.Berkeley.EDU by Sun.COM (sun-barr.Sun.COM) id AA21862; Wed, 14 Dec 94 22:16:50 PST Received: from localhost (bmah@localhost) by tenet.ICSI.Berkeley.EDU (8.6.9/8.6.6) with ESMTP id WAA00225; Wed, 14 Dec 1994 22:16:48 -0800 Message-Id: <199412150616.WAA00225@tenet.ICSI.Berkeley.EDU> To: ipng@sunroof.Eng.Sun.COM Cc: bmah@tenet.ICSI.Berkeley.EDU Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Wed, 14 Dec 1994 23:43:23 +0100." <9412142243.AA11574@ncc.ripe.net> X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Mailer: exmh version 1.5omega 10/6/94 Date: Wed, 14 Dec 1994 22:16:47 PST From: "Bruce A. Mah" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Geert Jan de Groot writes: > On Wed, 14 Dec 94 16:18:11 EST Dimitry Haskin wrote: > > It was decided at the San Jose's IETF to increase the minimum > > link MTU to 1500 bytes. The MTU for IEEE 802.3 encapsulation is 1492 bytes. > > > > Does it mean that it has been also decided not to support IPv6 over 802.3? > > If so, it probably should be explicitly stated in the IPv6 spec. > > I hope this is not true. I cannot recall this decision being made via > the mailing list; locking out people that were not allowed to attend > doesn't seem good practice to me. To the best of my recollection, this was not a decision per se, but more a poll to determine what people thought of a 1500-byte MTU. The opinion was fairly heavy in favor of upping the minimum MTU to 1500 bytes. > A 1500 byte MTU will do very bad things on slow serial links. The > arguments against are well known. It also causes problems for IP-in-AppleTalk encapsulation, which has a fairly small MTU (< 600 bytes). Ran Atkinson's geosynchronous satellites (with a 1K MTU) were also a bit of a problem...(insert obligatory joke about needing a Space Shuttle mission to change MTU here). As I recall, it was suggested that serial links could use some form of intra-link fragmentation and reassembly, as could IPv6-over-AppleTalk. One suggestion for the satellites was to tunnel inside IPv4, using the existing MTU for IP. Bruce. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 15 11:56:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07840; Thu, 15 Dec 94 11:56:18 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07834; Thu, 15 Dec 94 11:56:10 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA02526; Thu, 15 Dec 1994 11:50:41 -0800 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA19751; Thu, 15 Dec 94 11:50:33 PST Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA05044; Thu, 15 Dec 94 14:41:20 EST Received: from cabernet.wellfleet by wellfleet (4.1/SMI-4.1) id AA23126; Thu, 15 Dec 94 14:42:08 EST Date: Thu, 15 Dec 94 14:42:08 EST From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9412151942.AA23126@wellfleet> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 Cc: rcallon@pobox.wellfleet.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > I asked this after the Friday AM meeting, in a "hallway" > > conversation. The implication is that we use "Ethernet" > > encapsulation, not 802.3. It's worth mentioning in the spec, I spose. > > > > Regards, > > > > Justin > > Ummm... what was the reason for preferring Ethernet to 802.3? > Ignoring the obvious usage split, it still seems a bit punative to > require those using 802.3 to implement link-level fragmentation for a > gain of only a few bytes per transfer. Or perhaps I'm confused... Given that Ethernet and 802.3 are the same physical layer, and that it is perfectly normal and reasonable and common to run both Ethernet encapsulation and 802.3 encapsulation at the same time over the same physical wire and the same adaptors; I think that it would be a mistake to have IPv6 encapsulated using both Ethernet and 802.3 encapsulations at the same time on the same wire. This would just encourage non-interoperable implementations of IPv6. So, we need to choose one or the other encapsulation. I think that the selection of 1500 byte as the size that each link must support implies that we were implicitly thinking that Ethernet is the one encapsulation that we will pick (rather than 802.3). Frankly I don't care whether we choose Ethernet encapsulation or 802.3 encapsulation, but I think that we should choose one, stick with it, document it, and make the MTU consistent. Ross ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 15 12:10:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07864; Thu, 15 Dec 94 12:10:59 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07858; Thu, 15 Dec 94 12:10:52 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id MAA04623; Thu, 15 Dec 1994 12:05:23 -0800 Received: from black-ice.cc.vt.edu by Sun.COM (sun-barr.Sun.COM) id AA23599; Thu, 15 Dec 94 12:05:09 PST Received: from localhost (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.6.9/8.6.9) with ESMTP id MAA15153; Thu, 15 Dec 1994 12:34:21 -0500 Message-Id: <199412151734.MAA15153@black-ice.cc.vt.edu> To: ipng@sunroof.Eng.Sun.COM Cc: bmah@tenet.ICSI.Berkeley.EDU Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Wed, 14 Dec 1994 22:16:47 PST." <199412150616.WAA00225@tenet.ICSI.Berkeley.EDU> From: Valdis.Kletnieks@vt.edu Date: Thu, 15 Dec 1994 12:34:20 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Wed, 14 Dec 1994 22:16:47 PST, "Bruce A. Mah" said: > It also causes problems for IP-in-AppleTalk encapsulation, which has a fairly > small MTU (< 600 bytes). Ran Atkinson's geosynchronous satellites (with a 1K > MTU) were also a bit of a problem...(insert obligatory joke about needing a > Space Shuttle mission to change MTU here). Umm.. wouldn't you also need a Space Shuttle mission to add IPv6 support? But seriously - do we have a large number of cases where a node will be able to upgrade to support IPv6, but *not* be able to upgrade to the 1500 MTU? Valdis Kletnieks Computer Systems Engineer Virginia Tech ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 15 12:26:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07945; Thu, 15 Dec 94 12:26:01 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07939; Thu, 15 Dec 94 12:25:54 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id MAA06423; Thu, 15 Dec 1994 12:20:24 -0800 Received: from interlock.ans.net by Sun.COM (sun-barr.Sun.COM) id AA27617; Thu, 15 Dec 94 12:20:11 PST Received: by interlock.ans.net id AA10483 (InterLock SMTP Gateway 1.1 for ipng@sunroof.eng.sun.com); Thu, 15 Dec 1994 15:19:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 15 Dec 1994 15:19:57 -0500 Date: Thu, 15 Dec 94 15:19:56 EST From: Guy Almes To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of Thu, 15 Dec 1994 12:34:20 -0500 Message-Id: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM space shuttles can't do geosynchronous orbits But maybe the SpaceShuttleNG will be able to. :-) -- Guy ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 15 13:08:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08000; Thu, 15 Dec 94 13:08:28 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07994; Thu, 15 Dec 94 13:08:16 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id NAA11911; Thu, 15 Dec 1994 13:02:47 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA09188; Thu, 15 Dec 94 13:02:30 PST Received: from relay.imsi.com by wintermute.imsi.com id QAA28155 for ; Thu, 15 Dec 1994 16:01:34 -0500 Received: from snark.imsi.com by relay.imsi.com id QAA05059 for ; Thu, 15 Dec 1994 16:01:34 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA01379; Thu, 15 Dec 94 16:01:33 EST Message-Id: <9412152101.AA01379@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Thu, 15 Dec 1994 12:34:20 EST." <199412151734.MAA15153@black-ice.cc.vt.edu> X-Reposting-Policy: redistribute only with permission Date: Thu, 15 Dec 1994 16:01:33 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Valdis.Kletnieks@vt.edu says: > Umm.. wouldn't you also need a Space Shuttle mission to add IPv6 support? > > But seriously - do we have a large number of cases where a node will be able > to upgrade to support IPv6, but *not* be able to upgrade to the 1500 MTU? For purposes of this discussion, lets forget about 802.3 framing for a moment. The argument made was this: 1) Increasing the MTU has many, many benefits. 2) The only popular media that absolutely cannot support large packets are Localtalk and a small number of military satelites. 3) Media like localtalk are going to need whole new stacks to deal with IPv6 anyway, so new software isn't an issue. Since these media are very slow, link layer fragmentation and reassembly isn't too bad to deal with. 4) Media like PPP over modems probably want to do link level fragmentation anyway in order to improve interactive performance. The questioni then arose of how high to raise the minimum MTU; ethernet was thought to possess the lowest packet size for a widely deployed medium so 1500 bytes was chosen. I don't think anyone really considered the 802.3 issue, though. Myself, I'd say cut the gordion knot and lose the 8 bytes; you still get all of the same benefits by specifying a minimum MTU of 1492 bytes. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 15 13:27:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08025; Thu, 15 Dec 94 13:27:54 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08018; Thu, 15 Dec 94 13:27:42 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id NAA14360; Thu, 15 Dec 1994 13:22:13 -0800 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA07590; Thu, 15 Dec 94 01:19:26 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Minimum link MTU of 1500 To: ipng@sunroof.Eng.Sun.COM Date: Thu, 15 Dec 1994 09:20:25 +0000 (GMT) In-Reply-To: <9412142118.AA18558@wellfleet> from "Dimitry Haskin" at Dec 14, 94 04:18:11 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > It was decided at the San Jose's IETF to increase the minimum > link MTU to 1500 bytes. The MTU for IEEE 802.3 encapsulation is 1492 bytes. > > Does it mean that it has been also decided not to support IPv6 over 802.3? > If so, it probably should be explicitly stated in the IPv6 spec. Who decided this and why ? A minimum link mtu of 1500 bytes is unusable over things like amateur radio without a complete replacement of almost all of the existing user hardware, a change in the US and Australian law (and parts of UK law) to permit more advanced link layer schemes to cope with burst errors and allow the encodings needed. Very clever whoever pushed that through, thats guaranteed that lots of us will be unable to implement and keep to the spec. And yes I do understand why a large MTU is 'a good thing', but thats why I thought all the MTU discovery got put in IPv6 including for multicasts. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 15 13:31:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08056; Thu, 15 Dec 94 13:31:55 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08050; Thu, 15 Dec 94 13:31:44 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id NAA15133; Thu, 15 Dec 1994 13:26:14 -0800 Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA15514; Thu, 15 Dec 94 13:26:13 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id QAA28141 for ipng@sunroof.Eng.Sun.COM; Thu, 15 Dec 1994 16:28:06 -0500 (EST) Date: Thu, 15 Dec 1994 16:28:06 -0500 (EST) From: Scott Bradner Message-Id: <199412152128.QAA28141@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I don't think anyone really considered the 802.3 issue as I remember it did come up in the discussion and the suggestion was supported with that implication in mind Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 15 13:41:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08068; Thu, 15 Dec 94 13:41:10 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08062; Thu, 15 Dec 94 13:40:57 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id NAA16341; Thu, 15 Dec 1994 13:35:28 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA17765; Thu, 15 Dec 94 13:35:29 PST Received: by rodan.UU.NET id QQxula16771; Thu, 15 Dec 1994 16:34:45 -0500 Message-Id: To: ipng@sunroof.Eng.Sun.COM From: "Louis A. Mamakos" Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Thu, 15 Dec 1994 16:01:33 EST." <9412152101.AA01379@snark.imsi.com> Date: Thu, 15 Dec 1994 16:34:44 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > 4) Media like PPP over modems probably want to do link level > fragmentation anyway in order to improve interactive performance. Plus, modern IP stacks let you associate an MTU per route which can be used when TCP is deciding on the MSS for each connection, independent of the MTU. louie ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 15 14:21:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08342; Thu, 15 Dec 94 14:21:40 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08336; Thu, 15 Dec 94 14:21:32 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA21384; Thu, 15 Dec 1994 14:16:02 -0800 Received: from alink-gw.apple.com by Sun.COM (sun-barr.Sun.COM) id AA26381; Thu, 15 Dec 94 14:15:19 PST Received: from federal-excess.apple.com by alink-gw.apple.com with SMTP (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA19566; Thu, 15 Dec 94 14:15:13 -0800 for ipng@sunroof.eng.sun.com Received: from lilith.lansys.apple.com by federal-excess.apple.com (5.0/1-Nov-1994-eef) id AA05034; Thu, 15 Dec 1994 14:13:54 +0800 for ipng@sunroof.eng.sun.com Received: (justin@localhost) by lilith.lansys.apple.com (8.6.9/A/UX 3.1) id OAA07184; Thu, 15 Dec 1994 14:15:26 -0800 Date: Thu, 15 Dec 1994 14:15:26 -0800 From: "Justin C. Walker" Message-Id: <199412152215.OAA07184@lilith.lansys.apple.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM, rcallon@pobox.wellfleet.com In-Reply-To: Ross Callon's message of Thu, 15 Dec 94 14:42:08 EST <9412151942.AA23126@wellfleet> Subject: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> > > I asked this after the Friday AM meeting, in a "hallway" >> > > conversation. The implication is that we use "Ethernet" >> > > encapsulation, not 802.3. It's worth mentioning in the spec, I spose. >> > > >> > > Regards, >> > > >> > > Justin >> > >> > Ummm... what was the reason for preferring Ethernet to 802.3? >> > Ignoring the obvious usage split, it still seems a bit punative to >> > require those using 802.3 to implement link-level fragmentation for a >> > gain of only a few bytes per transfer. Or perhaps I'm confused... >> >> Given that Ethernet and 802.3 are the same physical layer, and >> that it is perfectly normal and reasonable and common to run >> both Ethernet encapsulation and 802.3 encapsulation at the >> same time over the same physical wire and the same adaptors; >> I think that it would be a mistake to have IPv6 encapsulated >> using both Ethernet and 802.3 encapsulations at the same time >> on the same wire. This would just encourage non-interoperable >> implementations of IPv6. >> >> So, we need to choose one or the other encapsulation. I agree with this. Is there any reason to go with both? I ask because I don't have a handle on the need for direct 802.3 support (for IPv6, much less IPv4). >> Frankly I don't care whether we choose Ethernet encapsulation or >> 802.3 encapsulation, but I think that we should choose one, stick >> with it, document it, and make the MTU consistent. Again, I agree. I should also hasten to point out that there weren't any "hard" decisions made on this issue, so there's little point in debating the process (I can sense it coming). What is of interest, as Jim Bound would doubtless point out, are the technical aspects of the MTU choice, and whether we can arrive at consensus (rough side down "-}). Regards, Justin Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | They sentenced me to 20 years Apple Business Systems | of boredom Apple Computer, Inc. | For trying to change the system 10500 North De Anza Blvd | from within Cupertino, CA 95014 | LC *---------------------------------------*------------------------------------* ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 15 14:29:20 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08377; Thu, 15 Dec 94 14:29:20 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08371; Thu, 15 Dec 94 14:29:13 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA22172; Thu, 15 Dec 1994 14:23:43 -0800 Received: from alink-gw.apple.com by Sun.COM (sun-barr.Sun.COM) id AA28364; Thu, 15 Dec 94 14:23:39 PST Received: from federal-excess.apple.com by alink-gw.apple.com with SMTP (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA19946; Thu, 15 Dec 94 14:23:37 -0800 for ipng@sunroof.eng.sun.com Received: from lilith.lansys.apple.com by federal-excess.apple.com (5.0/1-Nov-1994-eef) id AA05317; Thu, 15 Dec 1994 14:22:23 +0800 for ipng@sunroof.eng.sun.com Received: (justin@localhost) by lilith.lansys.apple.com (8.6.9/A/UX 3.1) id OAA07216; Thu, 15 Dec 1994 14:23:56 -0800 Date: Thu, 15 Dec 1994 14:23:56 -0800 From: "Justin C. Walker" Message-Id: <199412152223.OAA07216@lilith.lansys.apple.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Perry E. Metzger"'s message of Thu, 15 Dec 1994 16:01:33 -0500 <9412152101.AA01379@snark.imsi.com> Subject: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> The argument made was this: >> >> 1) Increasing the MTU has many, many benefits. >> 2) The only popular media that absolutely cannot support large packets are >> Localtalk and a small number of military satelites. >> 3) Media like localtalk are going to need whole new stacks to deal >> with IPv6 anyway, so new software isn't an issue. Since these media >> are very slow, link layer fragmentation and reassembly isn't too >> bad to deal with. >> 4) Media like PPP over modems probably want to do link level >> fragmentation anyway in order to improve interactive performance. The localtalk issue is a tough one. There is a significant use of "IP in AppleTalk" tunneling, and this uses AppleTalk's network layer, DDP. The MTU for DDP is 576 bytes (more or less; see a previous note from JohnV), and therefore a 1500-byte MTU for IPv6 would cause a need to rev the AppleTalk stack. DLC fragmentation, as well as revving DDP, are possible options, but neither are easy pills to swallow. (I should point out that I'm from the Unix group in Apple, and don't speak for those who deal with AppleTalk). Regards, Justin Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | They sentenced me to 20 years Apple Business Systems | of boredom Apple Computer, Inc. | For trying to change the system 10500 North De Anza Blvd | from within Cupertino, CA 95014 | LC *---------------------------------------*------------------------------------* ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 15 18:15:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08591; Thu, 15 Dec 94 18:15:48 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08585; Thu, 15 Dec 94 18:15:40 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id SAA16371; Thu, 15 Dec 1994 18:10:00 -0800 Received: from netcom18.netcom.com by Sun.COM (sun-barr.Sun.COM) id AA12081; Thu, 15 Dec 94 18:10:04 PST Received: by netcom18.netcom.com (8.6.9/Netcom) id SAA29420; Thu, 15 Dec 1994 18:09:48 -0800 Date: Thu, 15 Dec 1994 18:09:48 -0800 From: kck@netcom.com (Richard Fox) Message-Id: <199412160209.SAA29420@netcom18.netcom.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> I don't think anyone really considered the 802.3 issue > >as I remember it did come up in the discussion and the suggestion >was supported with that implication in mind I do not remember this coming up at the IETF in the general forum. I believe we discussed Appletalk and Satellites and whether we should support MTUs like 2K, 4K, or FDDI MTU sizes. I am not sure how important it is what was said because ...... What is becoming clearly apparent is that no matter what MTU we choose, some link layers are going to be unhappy. This would suggest that no matter what MTU we choose, PathMTU discovery is going to be extremely important to implement and implement correctly. Also, if we choose a higher MTU (than what we currently have) than some links can support nodes MUST be willing to lower the MTU (based on PathMTU) to a value less than the minimum, if link layer fragmentation is not supported on the link in question. This implies that having a larger MTU is really a goal, or default value to try but may not be what is used for connections. This of course can hurt multi-cast but maybe it won't be too bad. --rich ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 15 18:24:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08608; Thu, 15 Dec 94 18:24:57 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08602; Thu, 15 Dec 94 18:24:45 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id SAA17012; Thu, 15 Dec 1994 18:19:15 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA13096; Thu, 15 Dec 94 18:19:19 PST Received: from relay.imsi.com by wintermute.imsi.com id VAA29238 for ; Thu, 15 Dec 1994 21:19:18 -0500 Received: from snark.imsi.com by relay.imsi.com id VAA07228 for ; Thu, 15 Dec 1994 21:19:17 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA01745; Thu, 15 Dec 94 21:19:17 EST Message-Id: <9412160219.AA01745@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Thu, 15 Dec 1994 14:23:56 PST." <199412152223.OAA07216@lilith.lansys.apple.com> X-Reposting-Policy: redistribute only with permission Date: Thu, 15 Dec 1994 21:19:16 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM "Justin C. Walker" says: > The localtalk issue is a tough one. There is a significant > use of "IP in AppleTalk" tunneling, and this uses AppleTalk's network > layer, DDP. The MTU for DDP is 576 bytes (more or less; see a > previous note from JohnV), and therefore a 1500-byte MTU for IPv6 > would cause a need to rev the AppleTalk stack. IPv6 is going to require a complete rewrite of the stack anyway, so the fact that this will require changes to the stack isn't particularly bad in context. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 15 18:38:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08648; Thu, 15 Dec 94 18:38:27 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08622; Thu, 15 Dec 94 18:38:04 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id SAA17937; Thu, 15 Dec 1994 18:32:31 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA14620; Thu, 15 Dec 94 18:32:27 PST Received: from relay.imsi.com by wintermute.imsi.com id VAA29265 for ; Thu, 15 Dec 1994 21:32:25 -0500 Received: from snark.imsi.com by relay.imsi.com id VAA07317 for ; Thu, 15 Dec 1994 21:32:24 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA01759; Thu, 15 Dec 94 21:32:23 EST Message-Id: <9412160232.AA01759@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Thu, 15 Dec 1994 09:20:25 GMT." X-Reposting-Policy: redistribute only with permission Date: Thu, 15 Dec 1994 21:32:23 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan Cox says: > Who decided this and why ? A minimum link mtu of 1500 bytes is unusable over > things like amateur radio without a complete replacement of almost all of the > existing user hardware, a change in the US and Australian law (and parts > of UK law) to permit more advanced link layer schemes to cope with burst > errors and allow the encodings needed. 1) Since when does better error correction require changes to the law? As a former Ham I am unaware of any US law that prohibits better error correcting schemes from being used. Could you please site the portion of the FCC regs that you are refering to? 2) There were several Ham packet folks in the audiance, including Phil Karn. I didn't hear any of them mention this. 3) The question of MTUs has been going through on various mailing lists for a while. Ran Atkinson's famous satelites and Appletalk have been mentioned repeatedly, but no one has mentioned Ham packet service before. 4) Even if you have a problem with format changes or require something like link level fragmentation, since you will be requiring a new stack anyway, this can be the time that you change your formats around -- you are going to have to change them anyway as IPv6 is a totally new protocol. > And yes I do understand why a large MTU is 'a good thing', but thats why > I thought all the MTU discovery got put in IPv6 including for multicasts. Large MTUs will are good for many reasons. Just one example is that you need them to assure that you can send public keys via the DNS. MTU discovery does nothing about assuring that MTUs aren't too small -- it just tells you what they are. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 15 18:56:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08667; Thu, 15 Dec 94 18:56:15 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08661; Thu, 15 Dec 94 18:56:03 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id SAA19071; Thu, 15 Dec 1994 18:50:32 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA16545; Thu, 15 Dec 94 18:48:48 PST Received: from relay.imsi.com by wintermute.imsi.com id VAA29289 for ; Thu, 15 Dec 1994 21:48:41 -0500 Received: from snark.imsi.com by relay.imsi.com id VAA07376 for ; Thu, 15 Dec 1994 21:48:41 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA01786; Thu, 15 Dec 94 21:48:40 EST Message-Id: <9412160248.AA01786@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Thu, 15 Dec 1994 21:32:23 EST." <9412160232.AA01759@snark.imsi.com> X-Reposting-Policy: redistribute only with permission Date: Thu, 15 Dec 1994 21:48:39 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM "Perry E. Metzger" says: > As a former Ham I am unaware of any US law that prohibits better > error correcting schemes from being used. Could you please site the ^^^^ > portion of the FCC regs that you are refering to? That should, of course, be "cite". Ah, the risks of spell checkers... .pm ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 15 19:01:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08679; Thu, 15 Dec 94 19:01:17 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08673; Thu, 15 Dec 94 19:01:10 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id SAA19319; Thu, 15 Dec 1994 18:55:40 -0800 Received: from hp.com by Sun.COM (sun-barr.Sun.COM) id AA17214; Thu, 15 Dec 94 18:55:43 PST Received: from hpindlm.cup.hp.com by hp.com with ESMTP (1.37.109.14/15.5+ECS 3.3) id AA182426541; Thu, 15 Dec 1994 18:55:42 -0800 Received: by hpindlm.cup.hp.com (1.37.109.11/15.5+IOS 3.20+cup+OMrelay) id AA150126515; Thu, 15 Dec 1994 18:55:15 -0800 Date: Thu, 15 Dec 1994 18:55:15 -0800 From: Wan-Yen Hsu Message-Id: <199412160255.AA150126515@hpindlm.cup.hp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Ummm... what was the reason for preferring Ethernet to 802.3? >Ignoring the obvious usage split, it still seems a bit punative to >require those using 802.3 to implement link-level fragmentation for a >gain of only a few bytes per transfer. Or perhaps I'm confused... I agree. With only 8 bytes shorter than 1500, IPv6 will be able to support 802.3. 1492 is easy to remember. (1492 was a good year!) I know that some boxes only talk 802.3. In order to interoperate with those boxes, a slightly smaller MTU size is needed. Wan-yen ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 15 19:22:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08695; Thu, 15 Dec 94 19:22:15 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08689; Thu, 15 Dec 94 19:22:04 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id TAA27202; Thu, 15 Dec 1994 19:16:39 -0800 Date: Thu, 15 Dec 1994 19:16:39 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199412160316.TAA27202@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <199412160255.AA150126515@hpindlm.cup.hp.com> Subject: Re: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I know that some boxes only talk 802.3. In order to interoperate with those > boxes, a slightly smaller MTU size is needed. Then they are not compliant with IPv4 host requirements. All IPv4 implementations MUST support the Ethernet format. They may also support 802.3. Having two ways to do exactly the same thing does not enhance interoperability. Given that IPv6 is a new version of IP, and that IPv4 requires Ethernet encapsulation, I think IPv6 should also require Ethernet encapsulation. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 16 02:26:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08761; Fri, 16 Dec 94 02:26:37 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08755; Fri, 16 Dec 94 02:26:29 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id CAA04557; Fri, 16 Dec 1994 02:21:03 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA24939; Fri, 16 Dec 94 02:21:01 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA12992; Fri, 16 Dec 1994 11:20:58 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA13729; Fri, 16 Dec 1994 11:20:55 +0100 Message-Id: <9412161020.AA13729@dxcoms.cern.ch> Subject: (IPng) please rush me the minutes To: ipng@sunroof.Eng.Sun.COM Date: Fri, 16 Dec 1994 11:20:55 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9412151942.AA23126@wellfleet> from "Ross Callon" at Dec 15, 94 02:42:08 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ross, I REALLY need your nosi notes today Friday. Whatever you have is fine, I can expand them. Thanks Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 16 02:39:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08778; Fri, 16 Dec 94 02:39:23 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08772; Fri, 16 Dec 94 02:39:09 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id CAA04848; Fri, 16 Dec 1994 02:33:43 -0800 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA25761; Fri, 16 Dec 94 02:33:35 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Minimum link MTU of 1500 To: ipng@sunroof.Eng.Sun.COM Date: Fri, 16 Dec 1994 10:34:39 +0000 (GMT) In-Reply-To: <9412152101.AA01379@snark.imsi.com> from "Perry E. Metzger" at Dec 15, 94 04:01:33 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The argument made was this: > 1) Increasing the MTU has many, many benefits. Why ? - the most it does is cut down a couple of packets on the MTU discovery. > 2) The only popular media that absolutely cannot support large packets are > Localtalk and a small number of military satelites. Amateur radio, 802.3 , IP over IPX, People wanting good performance over PPP/SLIP links and using a low mtu and port based priority setting. For slow links thats very very useful. > 3) Media like localtalk are going to need whole new stacks to deal > with IPv6 anyway, so new software isn't an issue. Since these media > are very slow, link layer fragmentation and reassembly isn't too > bad to deal with. Why ? they are just another encapsulation problem. Link layer fragmentation over unreliable networks like IPX is already known to be a bad thing (eg with IP 8)). > The questioni then arose of how high to raise the minimum MTU; > ethernet was thought to possess the lowest packet size for a widely > deployed medium so 1500 bytes was chosen. I don't think anyone really > considered the 802.3 issue, though. Myself, I'd say cut the gordion > knot and lose the 8 bytes; you still get all of the same benefits by > specifying a minimum MTU of 1492 bytes. The whole thing seems weak and badly thought out. MTU discovery exists precisely to avoid this kind of mess. Specify that 1492 or whatever is a strongly recommended value. MTU discovery will sort out hosts with a lower MTU and for multicast services where it is an issue you may lose access to a few facilities at worst. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 16 02:53:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08841; Fri, 16 Dec 94 02:53:34 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08835; Fri, 16 Dec 94 02:53:22 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id CAA05061; Fri, 16 Dec 1994 02:47:55 -0800 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA26697; Fri, 16 Dec 94 02:47:52 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Minimum link MTU of 1500 To: ipng@sunroof.Eng.Sun.COM Date: Fri, 16 Dec 1994 10:48:57 +0000 (GMT) In-Reply-To: <199412160316.TAA27202@jurassic.Eng.Sun.COM> from "Bob Hinden" at Dec 15, 94 07:16:39 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Having two ways to do exactly the same thing does not enhance > interoperability. Given that IPv6 is a new version of IP, and that IPv4 > requires Ethernet encapsulation, I think IPv6 should also require > Ethernet encapsulation. Definitely - but breaking 802.3 for the sake of 8 bytes is pointless. Perhaps another side issue to be considered here (that may for all I know have been discussed at your meeting) is "Does setting the MTU minimum to a memory allocator friendly size (such as say 1K)) gain anything with modern OS's" Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 16 03:23:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08856; Fri, 16 Dec 94 03:23:50 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08850; Fri, 16 Dec 94 03:23:36 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id DAA05817; Fri, 16 Dec 1994 03:18:09 -0800 Received: from nic.funet.fi by Sun.COM (sun-barr.Sun.COM) id AA02448; Fri, 16 Dec 94 03:18:07 PST Received: from iiit.swan.ac.uk ([137.44.100.1]) by nic.funet.fi with SMTP id <91463-4>; Fri, 16 Dec 1994 13:17:58 +0200 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: (IPng) MTU issues To: ipng%sunroof.eng.sun.com@nic.funet.fi Date: Fri, 16 Dec 1994 11:18:32 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > 1) Since when does better error correction require changes to the law? The US FCC regulations require the use of AX.25 for third party traffic. I can't cite a precise reference offhand but ask on tcp-group or something if you need it. [To quote from TCP group earlier this week] >Phil Karn writes to Brandon Allbery's comment. >>As of the last time I looked, it was required if third-party messages were >>transmitted. Which means it's required for any serious TCP/IP use... >Only when 3rd party is carried during unattended operation. And third party traffic is basically thinks like all BBS/mail traffic for other users of the system so it is a big issue, but an amateur radio one not really an IPng one . [End quote] AX.25 doesn't include burst correction algorithms and you are therefore forced to use AX.25 connected mode to get 1500 byte link layer fragmentation support using small fragments. AX.25 connected mode is much less efficient on ham radio (especially non duplex channels due to key up/key down time, increased probability of collisions and total amount of bandwidth to get a probable reception). Its not as much of a problem for tcp fortunately as tcp windows in AX.25 are normally 436 bytes or so, and the tcp mss can be used to force packets to fit small frames (216 bytes). At the most fundamental level the problem with AX.25 is that its the only protocol supported by existing hardware. AX.25 itself uses a simple HDLC checksum algorithm which means that the longer the packet the higher chance of noise hitting it. In some countries such as the UK you can use any data transmission but are forbidden 'encryption'. I have written confirmation from the RA (UK equivalent of the FCC) that they do not regard an error correcting code (such as a hamming based system protecting against burst errors) as encryption but would prefer I send them a copy of the protocol that would be used - just in case. > 2) There were several Ham packet folks in the audiance, including Phil > Karn. I didn't hear any of them mention this. I don't know if they've considered it from the angle of the current 1200 baud AX.25 tnc, which exists in certainly 10's of thousands. I've actually been playing with things like algorithms for IPv6 header compression over AX.25, possibilities for using the AX.25 callsign for the low bits of the address in any future amateur allocation for IPv6. I suspect Phil is of the 'its about time people got kicked into using better link layer protocols' mindset, but you'd have to ask him that, I dont presume to speak for him. > 3) The question of MTUs has been going through on various mailing > lists for a while. Ran Atkinson's famous satelites and Appletalk > have been mentioned repeatedly, but no one has mentioned Ham packet > service before. Well I wasnt on the other lists. > 4) Even if you have a problem with format changes or require something > like link level fragmentation, since you will be requiring a new > stack anyway, this can be the time that you change your formats > around -- you are going to have to change them anyway as IPv6 is a > totally new protocol. Link layer fragmentation is a very inefficient thing to be forced to do especially on what is already one of the slowest tcp/ip architectures I know of. > Large MTUs will are good for many reasons. Just one example is that > you need them to assure that you can send public keys via the DNS. MTU > discovery does nothing about assuring that MTUs aren't too small -- it > just tells you what they are. Arguably that is because we don't have a sensible reliable transaction service in IPng, but I take that as a good example. Possibly it may be better to investigate ways of tricking, co-ercing and generally persuading the other end to use a very low size (TCP mss , window settings etc) and accept that on odd occasions the massive overhead of AX.25 fragmentation will come up. With luck it won't be too often. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 16 04:48:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08873; Fri, 16 Dec 94 04:48:02 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08867; Fri, 16 Dec 94 04:47:54 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id EAA07554; Fri, 16 Dec 1994 04:42:27 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA07634; Fri, 16 Dec 94 04:42:26 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA07853; Fri, 16 Dec 1994 13:42:20 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA17364; Fri, 16 Dec 1994 13:42:18 +0100 Message-Id: <9412161242.AA17364@dxcoms.cern.ch> Subject: (IPng) sorry folks To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Date: Fri, 16 Dec 1994 13:42:18 +0100 (MET) From: "Brian Carpenter CERN-CN" X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Sorry folks, I fell in the majordomo trap and sent a message intended for Ross to the whole list. IAB members are supposed to be smarter than that :-( Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 16 07:39:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08923; Fri, 16 Dec 94 07:39:22 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08917; Fri, 16 Dec 94 07:39:15 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id HAA14502; Fri, 16 Dec 1994 07:33:46 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA27981; Fri, 16 Dec 94 07:33:46 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27434; Sat, 17 Dec 1994 02:11:51 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 Date: Sat, 17 Dec 1994 02:11:50 +1100 Message-Id: <2527.787590710@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The 1500 byte thing was discussed several times in San Jose. Each time it started out with much of the audience skeptical, and ended with a pretty general consensus, after all the arguments were heard. Those people unable to attend naturally haven't heard the arguments. I would suggest waiting till we see just how much detail the minutes go into on this issue before rehashing it all again. On the ethernet vs 802.3 thing I think first that there is some misunderstanding. As I understood it, the differences between ethernet and 802.3 are some (comparatively) trivial electrical specifications. Is it not 802.2 that imposes SAPs and all that junk? In any case on an ethernet, for IPv6, as for IPv4, 802.2 (SAPs) will never be used, if you are going to implement IPv6 on ethernet you are going to do it using the DIX frame format - just as you do for IPv4. I know nothing about token rings, etc, however. If they happen to have a 1500 byte limit on frames, then 1492 may be a better number to pick, as I believe those things always use 802.2 framing. Just a comment on one other issue - whether its more or less effecient to do link level fragmentation/reassembly for those links that can't handle 1500. They're almost always slow (all that I have heard about are), so the compute burden shouldn't be much. Further, for cases where you really want small packets, the tcp mss should accomplish that - for udp the packets are just as big as they naturally need to be. A major concern here is handling DNS packets. With 16 byte addresses, and potentially on average many more addresses/node than IPv4 allocates, plus DNS security signatures, etc, the DNS really needs to be able to count on sending the biggest possible UDP packet we can reasonably give it. I don't know about you, but I don't think I want my DNS server attempting MTU discovery on every answer it sends. Further, if the answers don't fit across your low MTU link, what you're likely to get is a truncated response, which should get your client to attempt the query again with TCP. That's not exactly going to be lessening the load... Further, its a bit hard to imagine a simple link level frag/reassembly routine being either difficult to create, or imposing the overheads that IPv6 fragmented packets would add to your slow link (one IPv6 fragmentation split point will add 56 bytes of traffic). If you can't do link level frag/reassembly in less bytes than that then I suspect something needs fixing badly. Further, for those slow links, the splitting (which can be into arbitrarily small pieces to suit current traffic conditions - IP frag with MTU discovery would only fragment into the biggest bits its allowed) can also allow other traffic to push in ahead. If you're clever you could even allow a preemptory end of a packet being sent, and insertion of higher priority traffic, if you can figure out what that is. With IPv6 level frag, your slow link is likely to get the fragments arrive back to back, you're likely to have to send all of them in a stream anyway (recall that where ESP is being used, you can't look at the port numbers to see if this is rlogin or something - and in general, finding the port numbers will be harder) kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 16 11:12:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09036; Fri, 16 Dec 94 11:12:44 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09030; Fri, 16 Dec 94 11:12:36 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA04650; Fri, 16 Dec 1994 11:07:08 -0800 Received: from alink-gw.apple.com by Sun.COM (sun-barr.Sun.COM) id AA10767; Fri, 16 Dec 94 11:00:47 PST Received: from federal-excess.apple.com by alink-gw.apple.com with SMTP (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA02669; Fri, 16 Dec 94 10:59:46 -0800 for ipng@sunroof.eng.sun.com Received: from lilith.lansys.apple.com by federal-excess.apple.com (5.0/1-Nov-1994-eef) id AA25550; Fri, 16 Dec 1994 10:58:32 +0800 for ipng@sunroof.eng.sun.com Received: (justin@localhost) by lilith.lansys.apple.com (8.6.9/A/UX 3.1) id LAA07563; Fri, 16 Dec 1994 11:00:04 -0800 Date: Fri, 16 Dec 1994 11:00:04 -0800 From: "Justin C. Walker" Message-Id: <199412161900.LAA07563@lilith.lansys.apple.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: Robert Elz's message of Sat, 17 Dec 1994 02:11:50 +1100 <2527.787590710@munnari.OZ.AU> Subject: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Robert, >> On the ethernet vs 802.3 thing I think first that there is some >> misunderstanding. As I understood it, the differences between >> ethernet and 802.3 are some (comparatively) trivial electrical >> specifications. Is it not 802.2 that imposes SAPs and all that >> junk? "802.3 encapsulation" typically includes the use of 802.2 SNAP headers. There are numerous implementations that support this encapsulation of IPv4 (although why this is used at all, I'm not sure; it's a part of history I've missed, somehow). >> I know nothing about token rings, etc, however. If they happen to >> have a 1500 byte limit on frames, then 1492 may be a better number >> to pick, as I believe those things always use 802.2 framing. Token ring (802.5) has a noticeably larger MTU, and does indeed use 802.2 SNAP headers (for IPv4, in particular). It's possible, on reflection, that the use of SNAP headers for IPv4 on ethernet is due to the desire to have bridged token ring and ethernet (so that the bridges don't have to translate too much; this is idle speculation from the truly ignorant, tho). Regards, Justin Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | They sentenced me to 20 years Apple Business Systems | of boredom Apple Computer, Inc. | For trying to change the system 10500 North De Anza Blvd | from within Cupertino, CA 95014 | LC *---------------------------------------*------------------------------------* ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 16 12:56:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09180; Fri, 16 Dec 94 12:56:31 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09174; Fri, 16 Dec 94 12:56:24 PST Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id MAA27698; Fri, 16 Dec 1994 12:50:58 -0800 Received: by kandinsky.Eng.Sun.COM (5.x/SMI-SVR4) id AA14051; Fri, 16 Dec 1994 12:51:13 -0800 Date: Fri, 16 Dec 1994 12:51:13 -0800 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9412162051.AA14051@kandinsky.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng) re: Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I don't think that a general link level fragmentation/reassembly mechanism for links with MTUs smaller than the IPv6 minimum MTU would be too difficult to design and implement. In fact, one quick and dirty way to do this would be to use IPv6-in-IPv4 encapsulation. Point-to-point tunnels could be configured between pairs of IPv6 nodes that span a small MTU link. IPv6 packets that need to cross those links could first be encapsulated in IPv4. Then IPv4 fragmentation and reassembly could take care of delivering the IPv6 packets intact across the link. Given that virtually all of the small MTU links in question already carry IPv4, and most of the IPv6 code that will be driving those links will be additions to existing IPv4 implementations, it should be easy to get this solution up and running. Also, the fact that the packet header inside the link-layer header is IPv4 should take care of any legal restrictions on what types of packet can be carried over the link. One disadvantage of using IPv6-in-IPv4 encapsulation to solve this problem is the cost of the IPv4 header: 20 bytes. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 16 18:28:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09434; Fri, 16 Dec 94 18:28:50 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09428; Fri, 16 Dec 94 18:28:27 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id SAA23677; Fri, 16 Dec 1994 18:22:59 -0800 Received: from vangogh.CS.Berkeley.EDU by Sun.COM (sun-barr.Sun.COM) id AA28651; Fri, 16 Dec 94 18:22:58 PST Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.7.Alpha.3/8.6.9.Beta0) id SAA00843 for ipng@sunroof.Eng.Sun.COM; Fri, 16 Dec 1994 18:22:16 -0800 (PST) Date: Fri, 16 Dec 1994 18:22:16 -0800 (PST) From: Keith Sklower Message-Id: <199412170222.SAA00843@vangogh.CS.Berkeley.EDU> To: ipng@sunroof.Eng.Sun.COM Subject: re: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bob Gilligan writes: I don't think that a general link level fragmentation/reassembly mechanism for links with MTUs smaller than the IPv6 minimum MTU would be too difficult to design and implement. In fact, PPP now has a fragmentation/reassembly mechanism (RFC1717), as does regular old (non-PPP) IP/Frame Relay (and IP/X.25) (RFC1490). The header for PPP is about 4 bytes; for RFC1490 its about 8. (Certainly less than 20 bytes for IPv4). ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Dec 17 05:32:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09562; Sat, 17 Dec 94 05:32:33 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09556; Sat, 17 Dec 94 05:32:23 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id FAA11925; Sat, 17 Dec 1994 05:26:55 -0800 Received: from chenas.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA00476; Sat, 17 Dec 94 05:26:52 PST Received: from asimov.cnam.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA10415; Sat, 17 Dec 1994 14:26:49 +0100 (MET) Received: from verne.cnam.fr (verne.cnam.fr [163.173.129.0]) by asimov.cnam.fr with ESMTP id OAA22658 (8.6.9/); Sat, 17 Dec 1994 14:26:45 +0100 Received: from localhost (localhost [127.0.0.1]) by verne.cnam.fr with SMTP id OAA12361 (8.6.9/ for cnam.fr); Sat, 17 Dec 1994 14:26:44 +0100 Message-Id: <199412171326.OAA12361@cnam.fr> From: Stephane Bortzmeyer To: ipng@sunroof.Eng.Sun.COM Cc: bortzmeyer@cnam.fr, Pascal.Courtois@cnam.fr, besancon@excalibur.ens.fr Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Robert Elz 's message of "Sat, 17 Dec 94 02:11:50 +1100." <2527.787590710@munnari.OZ.AU> X-Mailer: DXMail [MH] Date: Sat, 17 Dec 94 14:26:43 +0100 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Saturday 17 December 94, at 2 h 11, the keyboard of Robert Elz wrote: > The 1500 byte thing was discussed several times in San Jose. Did anyone presented studies about the relative percentages in the present Internet of the different possible values? I did myself a (modest) survey on that case. I used the "traceroute.pmtu" program available in ftp://ftp.uu.net/published/books/stevens.tcpipv1.tar.Z, and described in Stevens' book (ftp://aw.com/aw.prof.comp.series/stevens.tcpipiv1.info.tar.Z). This was made with the list of our Web clients of November. (Our Web server is http://www.cnam.fr/.) We have many clients (100 000 per month) and we believe they are quite typical of the Internet, since the most attractive page has no mirror. 5500 hosts were choosen at random in this base (the study continues with more machines). 3126 of them weren't reachable: either they don't reply (2401 of the total) or some router stops me (454). 269 weren't even in the DNS! Machines which don't reply are probably micro-computers which are not always up (and even if they are, the TCP/IP stack can be off by default) or dialup hosts. The number of unreachable machines is probably due to filtering routers (it's a terrible consequence of hackering: studies or surveys are much more difficult). So, I could reach 2374 machines. Not taking into account the MTU of unreachable ones, I probably underestimate the percentage of small MTUs like 1006 which is typical for SLIP lines. There are many other biases in that survey (for instance, if a network has a firewall and all the machines have to use it as a Web relay, I see only one host, not taking into account the MTU of machines which are beyond it). I got several pathological replies (MTU highers than 1500!) which I suppressed. Our Ethernet has a MTU of 1500 and hence I cannot observe links with highers MTUs. The values are: MTU: Number of hosts Comments 1500: 2229 Maximum available for that survey 1006: 64 Typical SLIP line 576: 16 X25 or LocalTalk 1478: 11 1010: 7 572: 5 512: 5 Netbios is the only possibility listed in RFC 1191 1492: 5 IEEE 802.3 296: 5 Recommended value in RFC 1191 for slow lines 68: 3 Lowest possible value. Who uses it??? 1482: 2 538: 2 1196: 1 596: 1 992: 1 562: 1 Stephane Bortzmeyer Conservatoire National des Arts et Metiers bortzmeyer@cnam.fr Laboratoire d'Informatique 292, rue Saint-Martin tel: +33 (1) 40 27 27 31 75141 Paris Cedex 03 fax: +33 (1) 40 27 27 72 France "C'est la nuit qu'il est beau de croire a la lumiere." E. Rostand ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Dec 17 11:28:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09656; Sat, 17 Dec 94 11:28:54 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09650; Sat, 17 Dec 94 11:28:47 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA23095; Sat, 17 Dec 1994 11:23:18 -0800 Received: from netcom6.netcom.com by Sun.COM (sun-barr.Sun.COM) id AA11926; Sat, 17 Dec 94 11:22:02 PST Received: by netcom6.netcom.com (8.6.9/Netcom) id LAA01180; Sat, 17 Dec 1994 11:18:35 -0800 Date: Sat, 17 Dec 1994 11:18:35 -0800 From: kck@netcom.com (Richard Fox) Message-Id: <199412171918.LAA01180@netcom6.netcom.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) re: Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Given that virtually all of the small MTU links in question already >carry IPv4, and most of the IPv6 code that will be driving those links >will be additions to existing IPv4 implementations, it should be easy >to get this solution up and running. Also, the fact that the packet >header inside the link-layer header is IPv4 should take care of any >legal restrictions on what types of packet can be carried over the >link. One disadvantage of using IPv6-in-IPv4 encapsulation to solve >this problem is the cost of the IPv4 header: 20 bytes. For a long time here we have been hearing that fragmentation is bad. Now it looks like we may be building in fragmentation into the IPv6 model. This seems like a contradiction in ideology. The above paragraph says that the cost is an extra 20 bytes, but in reality the cost may be higher due to fragmentation and reasembly. But before we accept a scheme like this or flame a scheme like this we need to determine the exact cost differences of running a scheme like this in contrast to just running the smaller MTU. Two notes of interest. First, this encapsulation scheme will work as a fallout scheme, esp. in cases where links are known not to support IPv6. Second, if we find that the fragmentation/reasembly case is the most efficient, then we will ahve learned that fragmentation is not bad and instead of doing this encapsulation scheme, we can just let IPv6 do its own fragmentation, assuming the security issues can be solved (which they would have to anyways) and this should help solve the UDP/DNS problems as well. --rich ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Dec 17 17:59:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09733; Sat, 17 Dec 94 17:59:43 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09727; Sat, 17 Dec 94 17:59:35 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id RAA03059; Sat, 17 Dec 1994 17:54:07 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA25801; Sat, 17 Dec 94 17:54:06 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00503; Sun, 18 Dec 1994 12:54:02 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) re: Minimum link MTU of 1500 In-Reply-To: Your message of "Sat, 17 Dec 1994 11:18:35 -0800." <199412171918.LAA01180@netcom6.netcom.com> Date: Sun, 18 Dec 1994 12:54:00 +1100 Message-Id: <2680.787715640@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Sat, 17 Dec 1994 11:18:35 -0800 From: kck@netcom.com (Richard Fox) Message-ID: <199412171918.LAA01180@netcom6.netcom.com> Second, if we find that the fragmentation/reasembly case is the most efficient, then we will ahve learned that fragmentation is not bad and instead of doing this encapsulation scheme, we can just let IPv6 do its own fragmentation No .. the major problem with IPv4 fragmentation is the cost of transmitting a whole bunch of frags across vast expanses of the net with no hope of them being useful, because one of them has been lost ages before. With link level fragmentation/reassembly that doesn't happen, the frags are reassembled at the remote end of one link, if any frag was lost in transit over the link, the whole packet can be discarded immediately. Further, the nature of most link levels implies that packets, if delivered at all, will be delivered in the same order they are sent, which vastly simplifies the reassembly & error detection procedures (unfortunately, things like Appletalk, which could be a whole (smalk by comparison) Appletalk internet make this not always applicable). As has been pointed out, link level frag/reassembly is not exactly new, its been done for ages to avoid IPv4 fragmentation. Eg: on a natural X.25, the MTU would be 128, but (pre MTU discovery anyway, which means the world as it is now) no-one sends datagrams that small. One could fragment IPv4 packets as they enter the X.25 net, but in general, one doesn't, one does link level frag and reassembly to make the MTU higher than it otherwise would be. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Dec 17 20:40:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09782; Sat, 17 Dec 94 20:40:05 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09776; Sat, 17 Dec 94 20:39:53 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id UAA06237; Sat, 17 Dec 1994 20:34:23 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA00325; Sat, 17 Dec 94 20:34:24 PST Received: from relay.imsi.com by wintermute.imsi.com id XAA03904 for ; Sat, 17 Dec 1994 23:34:22 -0500 Received: from snark.imsi.com by relay.imsi.com id XAA24840 for ; Sat, 17 Dec 1994 23:34:21 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA04241; Sat, 17 Dec 94 23:34:21 EST Message-Id: <9412180434.AA04241@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) re: Minimum link MTU of 1500 In-Reply-To: Your message of "Sat, 17 Dec 1994 11:18:35 PST." <199412171918.LAA01180@netcom6.netcom.com> X-Reposting-Policy: redistribute only with permission Date: Sat, 17 Dec 1994 23:34:20 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Richard Fox says: > For a long time here we have been hearing that fragmentation is bad. > Now it looks like we may be building in fragmentation into the IPv6 > model. Localtalk will be gone in five years. Ran Atkinson's famous satelites are of concern only to some people in the military. I'd say that we aren't so much building fragmentation into the model as recognising that there is no point in keeping the MTU low for the benefit of a few dying platforms. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Dec 18 05:17:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09891; Sun, 18 Dec 94 05:17:47 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09885; Sun, 18 Dec 94 05:17:38 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id FAA18451; Sun, 18 Dec 1994 05:12:08 -0800 Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA18826; Sun, 18 Dec 94 05:12:07 PST Received: by pluto.dss.com (4.1/SMI-4.0) id AA09227; Sun, 18 Dec 94 08:11:55 EST From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9412181311.AA09227@pluto.dss.com> Subject: Re: (IPng) re: Minimum link MTU of 1500 To: ipng@sunroof.Eng.Sun.COM Date: Sun, 18 Dec 1994 08:11:53 -0500 (EST) Cc: martillo@pluto.dss.com (Joachim Martillo), mario@pluto.dss.com (Mario Savvides) In-Reply-To: <9412180434.AA04241@snark.imsi.com> from "Perry E. Metzger" at Dec 17, 94 11:34:20 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Richard Fox says: > > For a long time here we have been hearing that fragmentation is bad. > > Now it looks like we may be building in fragmentation into the IPv6 > > model. > Localtalk will be gone in five years. Ran Atkinson's famous satelites > are of concern only to some people in the military. I'd say that we > aren't so much building fragmentation into the model as recognising > that there is no point in keeping the MTU low for the benefit of a few > dying platforms. > Perry Possibly small MTUs may be useful in some ATM environments. Some implementations of FR have very small MTUs. Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com This note does not reflect an official Penril Datability Networks, Inc. position with respect to internetworking or related issues. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Dec 18 17:33:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10035; Sun, 18 Dec 94 17:33:34 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10029; Sun, 18 Dec 94 17:33:26 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id RAA03904; Sun, 18 Dec 1994 17:27:56 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA10662; Sun, 18 Dec 94 17:27:53 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA09604; Mon, 19 Dec 1994 12:27:47 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from dcthq2.datacraft.com.au by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA03643; Mon, 19 Dec 94 12:22:22 +1100 Received: by dcthq2.datacraft.com.au; Mon, 19 Dec 94 12:24:46 +1100 Date: Mon, 19 Dec 94 10:49:26 +1100 Message-Id: From: (alan lloyd) To: ipng@sunroof.Eng.Sun.COM Subject: re: (IPng) forwarded message, re IPv6 address plan X-Incognito-Sn: 1000 X-Incognito-Format: VERSION=1.73 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM hello all, well I made it back to oz (via the uk). This one of address allocation is difficult. (that's no supprise comming from me eh!). But the real issue is one of now that the INternet is going commercial and that IP6 is to be the global Internetwork protocol that can be used by anyone, even beyond that of the way its used on the Internet, what is the address allocation policy? The best answer is to delegate the address administration to regions and recognised bodies and leave it to them as one can debate this issue based on scenarios of network size/ growth forever. This is because the IETF, the ISEG and IANA can no longer (i believe) control the topology of the Internet (as it goes commercial) or the use of IP6. ie, One can only control the addressing and technology of a network if one has (explicit or implicit) control of the network. Let us just define address mechanisms and types of registration authorities. ie. IP6 native formats and Multicast - regionally administered. IPX formats .. by IPX users. NSAPs (buggerised form.. if that must be so) - ISO NSAP (proposed 16 byte Internet forms) IANA - ISO The NSAP support permits ISO/ITU to administer some forms within country. Regional and Provider allocations permit address admin associated with the INternet or IP6 users outside of the ISO/ITU. At least this will get the IP6 process started and any issues recognised can be dealt with as they arise. Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 05:20:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10270; Mon, 19 Dec 94 05:20:12 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10264; Mon, 19 Dec 94 05:20:05 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id FAA26381; Mon, 19 Dec 1994 05:14:34 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA28503; Mon, 19 Dec 94 05:14:34 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA26433; Mon, 19 Dec 94 05:14:22 -0800 Received: by xirtlu.zk3.dec.com; id AA11490; Mon, 19 Dec 1994 08:13:25 -0500 Message-Id: <9412191313.AA11490@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Thu, 15 Dec 94 21:19:16 EST." <9412160219.AA01745@snark.imsi.com> Date: Mon, 19 Dec 94 08:13:19 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry, >IPv6 is going to require a complete rewrite of the stack anyway, so >the fact that this will require changes to the stack isn't >particularly bad in context. Hasty statement! Not sure what facts your basing your claim on because I don't see you as one of the names or companies that have claimed to be building IPv6 prototypes. I doubt any of us will have to completely rewrite our stacks. We will have to add new modules to the existing network subsystem of our OS kernels and driver code eventually. So the argument of stating lets pick this technical solution because we are re-writing it anyway is an invalid agrument IMHO. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 06:52:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10287; Mon, 19 Dec 94 06:52:37 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10281; Mon, 19 Dec 94 06:52:25 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA00151; Mon, 19 Dec 1994 06:46:53 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA08622; Mon, 19 Dec 94 06:42:40 PST Received: from relay.imsi.com by wintermute.imsi.com id JAA05480; Mon, 19 Dec 1994 09:42:32 -0500 Received: from snark.imsi.com by relay.imsi.com id JAA05606; Mon, 19 Dec 1994 09:42:32 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA05700; Mon, 19 Dec 94 09:42:31 EST Message-Id: <9412191442.AA05700@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Mon, 19 Dec 1994 08:13:19 EST." <9412191313.AA11490@xirtlu.zk3.dec.com> X-Reposting-Policy: redistribute only with permission Date: Mon, 19 Dec 1994 09:42:30 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM bound@zk3.dec.com says: > Perry, > > >IPv6 is going to require a complete rewrite of the stack anyway, so > >the fact that this will require changes to the stack isn't > >particularly bad in context. > > Hasty statement! [more on the fact that they aren't completely rewriting elided.] Well, the fact remains that IPv6 does require new code. It was argued that link level fragmentation for Localtalk would require new code, but the argument I was making was simply that supporting IPv6 requires at least some new code no matter what. The "complete rewrite" business was slight hyperbole but doesn't overall alter the gist of my argument. .pm ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 07:36:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10350; Mon, 19 Dec 94 07:36:56 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10344; Mon, 19 Dec 94 07:36:49 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id HAA02666; Mon, 19 Dec 1994 07:31:17 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA15712; Mon, 19 Dec 94 07:31:12 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA07321; Mon, 19 Dec 94 07:26:36 -0800 Received: by xirtlu.zk3.dec.com; id AA18547; Mon, 19 Dec 1994 10:25:33 -0500 Message-Id: <9412191525.AA18547@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: ngtrans@sunroof.Eng.Sun.COM, addrconf@cisco.com, deering@parc.xerox.com, rcallon@wellfleet.com, hinden@Eng Subject: Re: (IPng) interim IPng WG meeting In-Reply-To: Your message of "Mon, 12 Dec 94 13:37:12 PST." <94Dec12.133724pst.12173@skylark.parc.xerox.com> Date: Mon, 19 Dec 94 10:25:27 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, Alex Conta and I can make it Feb 9 and 10th. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 07:46:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10382; Mon, 19 Dec 94 07:46:17 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10376; Mon, 19 Dec 94 07:46:10 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id HAA03120; Mon, 19 Dec 1994 07:40:37 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA17246; Mon, 19 Dec 94 07:40:38 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA08166; Mon, 19 Dec 94 07:35:40 -0800 Received: by xirtlu.zk3.dec.com; id AA18961; Mon, 19 Dec 1994 10:34:43 -0500 Message-Id: <9412191534.AA18961@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Thu, 15 Dec 94 14:15:26 PST." <199412152215.OAA07184@lilith.lansys.apple.com> Date: Mon, 19 Dec 94 10:34:37 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> Frankly I don't care whether we choose Ethernet encapsulation or >> 802.3 encapsulation, but I think that we should choose one, stick >> with it, document it, and make the MTU consistent. > Again, I agree. I should also hasten to point out that there >weren't any "hard" decisions made on this issue, so there's little >point in debating the process (I can sense it coming). What is of >interest, as Jim Bound would doubtless point out, are the technical >aspects of the MTU choice, and whether we can arrive at consensus >(rough side down "-}). >Regards, >Justin I agree too but with the caveat what are the technical trade-offs of 802.3 vs Ethernet and they should be documented. This should include what we loose when using one or the other. Lets not assume all know that answer on this list. As a side note I think our persistence of referencing RFC 1122 is completely bogus at this point for IPv6 and below (in layers abstractly). Either RFC 1122 at the points above need to be re-written or completely scraped as a standard to measure any IPv6 functionality, especially system discovery, mobile, and flow IDs which are all new IMHO for the next generation IP protocol IPv6 at the network layer and below (and of course the damage to TCP or UDP per IPv6). Bottom-line RFC 1122 does not apply and referencing it could be an oxymoron in our discussions. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 08:22:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10413; Mon, 19 Dec 94 08:22:29 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10407; Mon, 19 Dec 94 08:22:22 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id IAA05637; Mon, 19 Dec 1994 08:16:49 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA24737; Mon, 19 Dec 94 08:16:51 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA12298; Mon, 19 Dec 94 08:14:14 -0800 Received: by xirtlu.zk3.dec.com; id AA21273; Mon, 19 Dec 1994 11:13:17 -0500 Message-Id: <9412191613.AA21273@xirtlu.zk3.dec.com> To: perry@imsi.com Cc: ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Mon, 19 Dec 94 09:42:30 EST." <9412191442.AA05700@snark.imsi.com> Date: Mon, 19 Dec 94 11:13:11 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >bound@zk3.dec.com says: >> Perry, >> >> >IPv6 is going to require a complete rewrite of the stack anyway, so >> >the fact that this will require changes to the stack isn't >> >particularly bad in context. >> >> Hasty statement! [more on the fact that they aren't completely rewriting elided.] >Well, the fact remains that IPv6 does require new code. It was argued >that link level fragmentation for Localtalk would require new code, >but the argument I was making was simply that supporting IPv6 requires >at least some new code no matter what. The "complete rewrite" business >was slight hyperbole but doesn't overall alter the gist of my >argument. My posit still holds that we should not make decisions soley based on the fact we are alteriing existing code. That was the only point of my mail. But look at the mail above its really a long leap from "complete rewrite of the stack" to "IPv6 does require new code". The first statement implies visions of massive integration of existing stacks for transition, while the second is more like No Shit Sherlock. So it does alter COMPLETELY your gist and you should just lick your wounds and lets get back to the trade-offs of 802.3 and Ethernet which I think should be stated by those who really care. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 08:34:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10437; Mon, 19 Dec 94 08:34:37 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10431; Mon, 19 Dec 94 08:34:30 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id IAA06558; Mon, 19 Dec 1994 08:28:57 -0800 Received: from netcom2.netcom.com by Sun.COM (sun-barr.Sun.COM) id AA26982; Mon, 19 Dec 94 08:28:45 PST Received: by netcom2.netcom.com (8.6.9/Netcom) id IAA22520; Mon, 19 Dec 1994 08:28:38 -0800 Date: Mon, 19 Dec 1994 08:28:38 -0800 From: kck@netcom.com (Richard Fox) Message-Id: <199412191628.IAA22520@netcom2.netcom.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >>IPv6 is going to require a complete rewrite of the stack anyway, so >>the fact that this will require changes to the stack isn't >>particularly bad in context. > >Hasty statement! Not sure what facts your basing your claim on because I >don't see you as one of the names or companies that have claimed to be >building IPv6 prototypes. I doubt any of us will have to completely rewrite >our stacks. We will have to add new modules to the existing network subsystem >of our OS kernels and driver code eventually. So the argument of stating lets >pick this technical solution because we are re-writing it anyway is an >invalid agrument IMHO. >/jim Good point Jim! In fact, I do not see most device drivers changing at all. I see a new row of a table that tells the device driver where to send a packet of type IPv6 being added, not a complete rewrite. This implies that adding fragmentation/reasembly to some device drivers may not be in the cards. This may be a moot point but ... --rich ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 09:05:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10495; Mon, 19 Dec 94 09:05:47 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10489; Mon, 19 Dec 94 09:05:40 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id JAA09329; Mon, 19 Dec 1994 09:00:07 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA03001; Mon, 19 Dec 94 09:00:08 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA16498; Mon, 19 Dec 94 08:56:17 -0800 Received: by xirtlu.zk3.dec.com; id AA22657; Mon, 19 Dec 1994 11:55:18 -0500 Message-Id: <9412191655.AA22657@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Mon, 19 Dec 94 08:28:38 PST." <199412191628.IAA22520@netcom2.netcom.com> Date: Mon, 19 Dec 94 11:55:12 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Good point Jim! In fact, I do not see most device drivers changing at >all. I see a new row of a table that tells the device driver where to >send a packet of type IPv6 being added, not a complete rewrite. This >implies that adding fragmentation/reasembly to some device drivers may >not be in the cards. This may be a moot point but ... Rich, What about the multiple addresses per interface especially multicast? Thats where I see some pain? Probably can do something better with the buffers too the addresses are rather large now? Avoiding it right now though? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 09:11:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10533; Mon, 19 Dec 94 09:11:51 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10527; Mon, 19 Dec 94 09:11:39 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id JAA09925; Mon, 19 Dec 1994 09:06:06 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA04211; Mon, 19 Dec 94 09:05:58 PST Received: from relay.imsi.com by wintermute.imsi.com id MAA06021 for ; Mon, 19 Dec 1994 12:05:57 -0500 Received: from snark.imsi.com by relay.imsi.com id MAA06973 for ; Mon, 19 Dec 1994 12:05:57 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA06475; Mon, 19 Dec 94 12:05:56 EST Message-Id: <9412191705.AA06475@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Mon, 19 Dec 1994 08:28:38 PST." <199412191628.IAA22520@netcom2.netcom.com> X-Reposting-Policy: redistribute only with permission Date: Mon, 19 Dec 1994 12:05:56 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Richard Fox says: > Good point Jim! In fact, I do not see most device drivers changing at > all. I see a new row of a table that tells the device driver where to > send a packet of type IPv6 being added, not a complete rewrite. I see someone who hasn't been writing network driver code lately. .pm ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 09:21:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10569; Mon, 19 Dec 94 09:21:00 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10563; Mon, 19 Dec 94 09:20:47 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id JAA10646; Mon, 19 Dec 1994 09:15:17 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA05815; Mon, 19 Dec 94 09:15:16 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm012-07.dialip.mich.net [35.1.48.208]) by merit.edu (8.6.9/merit-2.0) with SMTP id MAA01674 for ; Mon, 19 Dec 1994 12:15:12 -0500 Date: Mon, 19 Dec 94 16:26:28 GMT From: "William Allen Simpson" Message-Id: <3574.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I'm just back, and trying to catch up on 1.7 MB of email (since IETF). The following comment (together with Perry's) caused me to go through the roof. > From: Robert Elz > Just a comment on one other issue - whether its more or less > effecient to do link level fragmentation/reassembly for those > links that can't handle 1500. They're almost always slow (all > that I have heard about are), so the compute burden shouldn't > be much. Folks, I am tired of hearing that anything less than ethernet speeds are "slow". By usual terminology, a low speed link is <= 2400 bps. A medium speed link is <= 28.8 Kbps. Anything greater (57.6 Kbps) is high speed. T1 is very high, T3 is ultra high, and both are way beyond the budget of most people or businesses. The bad assumption here is that there is any more compute power leftover. We are talking 186s or worse here. They can barely keep up with simple framing over medium speed links. Macs achieve 115 Kbps by doing a tight loop which hangs the entire system. There is no power available for special link layer fragmentation. Indeed, we had to eliminate IP layer fragmentation for cellular (IS-99). Also, we are talking _current_ hardware, not some old leftover junk. These devices are being made in the 10s of millions, far more than those silly workstation and router vendors can dream of shipping. We had these same kind of arguments in PPP -- high speed, big ticket vendors versus the rest of us. On a vote, they always win, since the rest of us can't afford to send people to IETF. Not everyone is willing to spend 1/4 of their income each year going to damn meetings. I've been doing it for love, but .... And no, Phil Karn was not in the room. I was looking to him for support. > A major concern here is > handling DNS packets. With 16 byte addresses, and potentially > on average many more addresses/node than IPv4 allocates, plus > DNS security signatures, etc, the DNS really needs to be able to > count on sending the biggest possible UDP packet we can reasonably > give it. I don't know about you, but I don't think I want my > DNS server attempting MTU discovery on every answer it sends. > Further, if the answers don't fit across your low MTU link, what > you're likely to get is a truncated response, which should get > your client to attempt the query again with TCP. I agree that it is a concern. We should eliminate UDP for IPv6 DNS. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 09:33:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10645; Mon, 19 Dec 94 09:33:50 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10639; Mon, 19 Dec 94 09:33:38 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id JAA11822; Mon, 19 Dec 1994 09:28:07 -0800 Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA08628; Mon, 19 Dec 94 09:28:05 PST Subject: Re: (IPng) Minimum link MTU of 1500 To: perry@imsi.com, IPng Mailing list Date: Mon, 19 Dec 1994 12:27:28 -0500 (EST) From: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9412191727.aa06319@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Richard Fox wrote... >> Good point Jim! In fact, I do not see most device drivers changing at >> all. I see a new row of a table that tells the device driver where to >> send a packet of type IPv6 being added, not a complete rewrite. Perry Metzger responded... >I see someone who hasn't been writing network driver code lately. Unless IPv6 changes Ethertype, which I doubt it will, I send v6 and v4 packets from my Ethernet driver to the ipintr() routine, which then demuxes on version number to either continue in ipintr(), or call ipv6_input(). I haven't been writing network driver code lately because, quite frankly, the network drivers frame IP and IPv6 the same way. That's one of the reasons we have the first four bits. Dan McD. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 09:44:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10701; Mon, 19 Dec 94 09:44:03 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10695; Mon, 19 Dec 94 09:43:51 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id JAA15856; Mon, 19 Dec 1994 09:38:20 -0800 Date: Mon, 19 Dec 1994 09:38:20 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199412191738.JAA15856@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: Subject: re: (IPng) forwarded message, re IPv6 address plan Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan, > hello all, well I made it back to oz (via the uk). Hope you had a nice trip. > The best answer is to delegate the address administration to regions and > recognised bodies and leave it to them as one can debate this issue This is one of many choices. What is the "best" answer is far from clear. To me, the current Internet address assignment mechanisms (e.g., IANA at the top, etc.) work fine. Unless compelling evidence can be presented as to why something else would be better, I do not see any reason to change. > This is because the IETF, the ISEG and IANA can no longer (i believe) control > the topology of the Internet (as it goes commercial) or the use of IP6. The IETF, IESG, IANA does not control the topology of the Internet. The majority of the global internet has been commercial for a long time. It is the backbones (I would estimate to be 1% of the overall installed base) that are now in the process of going commercial. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 10:04:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10776; Mon, 19 Dec 94 10:04:32 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10770; Mon, 19 Dec 94 10:04:21 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id JAA14901; Mon, 19 Dec 1994 09:58:50 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA15245; Mon, 19 Dec 94 09:58:47 PST Received: from relay.imsi.com by wintermute.imsi.com id MAA06287 for ; Mon, 19 Dec 1994 12:58:46 -0500 Received: from snark.imsi.com by relay.imsi.com id MAA07766 for ; Mon, 19 Dec 1994 12:58:45 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA06700; Mon, 19 Dec 94 12:58:44 EST Message-Id: <9412191758.AA06700@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Mon, 19 Dec 1994 12:05:56 EST." <9412191705.AA06475@snark.imsi.com> X-Reposting-Policy: redistribute only with permission Date: Mon, 19 Dec 1994 12:58:43 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM "Perry E. Metzger" says: > Richard Fox says: > > Good point Jim! In fact, I do not see most device drivers changing at > > all. I see a new row of a table that tells the device driver where to > > send a packet of type IPv6 being added, not a complete rewrite. > > I see someone who hasn't been writing network driver code lately. I apologize for that remark; it was nasty and unwarranted. .pm ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 10:42:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10854; Mon, 19 Dec 94 10:42:43 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10842; Mon, 19 Dec 94 10:42:32 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id KAA19365; Mon, 19 Dec 1994 10:37:00 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA23024; Mon, 19 Dec 94 10:36:59 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA26225; Mon, 19 Dec 94 10:31:15 -0800 Received: by xirtlu.zk3.dec.com; id AA25404; Mon, 19 Dec 1994 13:30:12 -0500 Message-Id: <9412191830.AA25404@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: perry@imsi.com, IPng Mailing list , bound@zk3.dec.com Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Mon, 19 Dec 94 12:27:28 EST." <9412191727.aa06319@sundance.itd.nrl.navy.mil> Date: Mon, 19 Dec 94 13:30:05 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Unless IPv6 changes Ethertype, which I doubt it will, I send v6 and v4 >packets from my Ethernet driver to the ipintr() routine, which then >demuxes on version number to either continue in ipintr(), or call >ipv6_input(). Well said Dan. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 10:42:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10855; Mon, 19 Dec 94 10:42:48 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10848; Mon, 19 Dec 94 10:42:37 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id KAA19385; Mon, 19 Dec 1994 10:37:04 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA23041; Mon, 19 Dec 94 10:37:03 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA26225; Mon, 19 Dec 94 10:31:15 -0800 Received: by xirtlu.zk3.dec.com; id AA25404; Mon, 19 Dec 1994 13:30:12 -0500 Message-Id: <9412191830.AA25404@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: perry@imsi.com, IPng Mailing list , bound@zk3.dec.com Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Mon, 19 Dec 94 12:27:28 EST." <9412191727.aa06319@sundance.itd.nrl.navy.mil> Date: Mon, 19 Dec 94 13:30:05 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Unless IPv6 changes Ethertype, which I doubt it will, I send v6 and v4 >packets from my Ethernet driver to the ipintr() routine, which then >demuxes on version number to either continue in ipintr(), or call >ipv6_input(). Well said Dan. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 12:14:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10890; Mon, 19 Dec 94 12:14:02 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10884; Mon, 19 Dec 94 12:13:53 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id MAA00950; Mon, 19 Dec 1994 12:08:21 -0800 Received: from netcom7.netcom.com by Sun.COM (sun-barr.Sun.COM) id AA11632; Mon, 19 Dec 94 12:08:17 PST Received: by netcom7.netcom.com (8.6.9/Netcom) id MAA21729; Mon, 19 Dec 1994 12:08:15 -0800 Date: Mon, 19 Dec 1994 12:08:15 -0800 From: kck@netcom.com (Richard Fox) Message-Id: <199412192008.MAA21729@netcom7.netcom.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >What about the multiple addresses per interface especially multicast? >Thats where I see some pain? Probably can do something better with the >buffers too the addresses are rather large now? Avoiding it right >now though? Multiple addresses per interface only requires changes if you desire it, forgetting multicast. Multicast will require some new coding but it should be minimal, whatever that means. The buffer problem may or may not be a problem with some drivers. I guess thats a polite way of saying no real comment on that one. So it looks like some changes may be required but to what extent its unknown. So what in your opinion is the RIGHT thing to do regarding the MTU. I see 4 choices: 1. leave it where it originally is. 2. leave it at 1500 bytes 3. raise it to some value 4. lower it to some value above the original. I voted for 1500 bytes in San Jose and I will stick with it IF it makes technical sense. I am just not 100% sure at this time. What would be nice is a Path-MTU solution that would work for UDP (ie: DNS) such that a request coming in can formulate the Path-MTU used to reach the server. That way the server can formulate a reply accordingly. This, however, seems to potentially open another bag of worms. --rich ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 13:21:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10963; Mon, 19 Dec 94 13:21:31 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10957; Mon, 19 Dec 94 13:21:24 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id NAA08837; Mon, 19 Dec 1994 13:15:52 -0800 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA23193; Mon, 19 Dec 94 13:15:28 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA16728; Mon, 19 Dec 94 13:08:42 -0800 Received: by xirtlu.zk3.dec.com; id AA00542; Mon, 19 Dec 1994 16:08:39 -0500 Message-Id: <9412192108.AA00542@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Mon, 19 Dec 94 12:08:15 PST." <199412192008.MAA21729@netcom7.netcom.com> Date: Mon, 19 Dec 94 16:08:33 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >So it looks like some changes may be required but to what extent its >unknown. So what in your opinion is the RIGHT thing to do regarding >the MTU. I see 4 choices: Well first of all I am in the camp of OK whatever you decide. But putting on my architecture hat for a moment (Steve D - no fair sending this msg back to me someday). >1. leave it where it originally is. It should be big as possible. If the size is constrained who suffers the pain and what would the industry gain? Would the pain only be temporary and for isolated cases? We need to use Steves process of whats the gain for such a change in the core architecture and then I would like to see the performance gain. I believe a performance gain from increasing MTU to something like 1492 would offer significant gains to the industry and the Internet. This may actually also drive manufactures of data comm equipment to change too at a cost supported by IPv6 demand. But that demand right now is ZERO. But all will do some of the work just to be future safe, if we make good technical decisions in the Working Groups for IPng like on MTU, so I think this is a very important crossroad for us in the specs. >2. leave it at 1500 bytes This seems like the correct range value. I doubt we should break Ethernet and go to 2K, which to some is also a nice value. >3. raise it to some value Unless the gain is significant is the work worth it. >4. lower it to some value above the original. Nay. >I voted for 1500 bytes in San Jose and I will stick with it IF it makes >technical sense. I am just not 100% sure at this time. What would be >nice is a Path-MTU solution that would work for UDP (ie: DNS) such >that a request coming in can formulate the Path-MTU used to reach the >server. That way the server can formulate a reply accordingly. This, >however, seems to potentially open another bag of worms. UDP and Path-MTU is doable but the can of worms today is enhancing the application to understand PMTU. IMHO not as employee of my company, I think applications like DNS should bite the bullet and absorb PMTU. Without getting into PMTU wars I completely am a true believer in the deering/mogul PMTU is good for your mental health and real customers networks. So raising it to 1500 seems prudent and we all bite the bullet and sort the worms out from UDP. I think Bills idea of telling DNS to use TCP is a real good one but that would take some time for people to productize such an effort as opposed to prototype to test IPv6. That is a good question to Paul Vixie I will ask him. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 14:14:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11002; Mon, 19 Dec 94 14:14:45 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10996; Mon, 19 Dec 94 14:14:33 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA16106; Mon, 19 Dec 1994 14:09:01 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AB01778; Mon, 19 Dec 94 14:04:51 PST Received: from relay.imsi.com by wintermute.imsi.com id RAA07187; Mon, 19 Dec 1994 17:04:23 -0500 Received: from snark.imsi.com by relay.imsi.com id RAA09957; Mon, 19 Dec 1994 17:04:22 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA09015; Mon, 19 Dec 94 17:04:21 EST Message-Id: <9412192204.AA09015@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Mon, 19 Dec 1994 16:08:33 EST." <9412192108.AA00542@xirtlu.zk3.dec.com> X-Reposting-Policy: redistribute only with permission Date: Mon, 19 Dec 1994 17:04:21 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM bound@zk3.dec.com says: > IMHO not as employee of my company, I > think applications like DNS should bite the bullet and absorb PMTU. The amount of state you would need to maintain in, say, a root nameserver, would be rather prohibitive... Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 14:32:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11042; Mon, 19 Dec 94 14:32:49 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11031; Mon, 19 Dec 94 14:32:35 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA18314; Mon, 19 Dec 1994 14:27:02 -0800 Received: from odin.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA06637; Mon, 19 Dec 94 14:27:02 PST Received: by odin.UU.NET (maildrop) id QQxuzx20104; Mon, 19 Dec 1994 17:23:04 -0500 Date: Mon, 19 Dec 1994 17:23:04 -0500 Message-Id: From: Joseph Malcolm To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: <9412192108.AA00542@xirtlu.zk3.dec.com> References: <199412192008.MAA21729@netcom7.netcom.com> <9412192108.AA00542@xirtlu.zk3.dec.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM bound@zk3.dec.com writes: >UDP and Path-MTU is doable but the can of worms today is enhancing the >application to understand PMTU. IMHO not as employee of my company, I >think applications like DNS should bite the bullet and absorb PMTU. >Without getting into PMTU wars I completely am a true believer in the >deering/mogul PMTU is good for your mental health and real customers >networks. So raising it to 1500 seems prudent and we all bite the bullet >and sort the worms out from UDP. I think Bills idea of telling DNS to >use TCP is a real good one but that would take some time for people to >productize such an effort as opposed to prototype to test IPv6. That is >a good question to Paul Vixie I will ask him. ns.uu.net answers 30 queries a second on average, 24x7. It's not clear to me that the set of machines that query it is small enough to make PMTU discovery feasible, unless it is vastly less expensive than I expect. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 15:29:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11095; Mon, 19 Dec 94 15:29:02 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11089; Mon, 19 Dec 94 15:28:53 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id PAA25636; Mon, 19 Dec 1994 15:23:20 -0800 Received: from ftp.com by Sun.COM (sun-barr.Sun.COM) id AA17460; Mon, 19 Dec 94 15:23:21 PST Received: from ftp.com by ftp.com ; Mon, 19 Dec 1994 18:23:20 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 19 Dec 1994 18:23:20 -0500 Received: from solensky.fenway.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA19429; Mon, 19 Dec 94 18:22:33 EST Date: Mon, 19 Dec 94 18:22:33 EST Message-Id: <9412192322.AA19429@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) re: Minimum link MTU of 1500 From: solensky@ftp.com (Frank T Solensky) Repository: mailserv-D.ftp.com, [message accepted at Mon Dec 19 18:22:26 1994] Originating-Client: fenway.ftp.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Bob.Gilligan@Eng.Sun.COM (Bob Gilligan) >..one quick and dirty way to do [link level fragmentation] would be to use > IPv6-in-IPv4 encapsulation. Point-to-point tunnels could be configured > between pairs of IPv6 nodes that span a small MTU link. IPv6 packets > that need to cross those links could first be encapsulated in IPv4. > Then IPv4 fragmentation and reassembly could take care of delivering > the IPv6 packets intact across the link. This may be obvious to everyone else but me -- if we do pursue this approach, we should probably recommend using IPv4 addresses out of either 'this net' (network zero) or those used in RFC-1597 so that the eventual depletion of IPv4 space doesn't become a constraint.. -- Frank ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 15:44:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11107; Mon, 19 Dec 94 15:44:23 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11101; Mon, 19 Dec 94 15:44:12 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id PAA27209; Mon, 19 Dec 1994 15:38:39 -0800 Received: from odin.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA20145; Mon, 19 Dec 94 15:38:39 PST Received: by odin.UU.NET (maildrop) id QQxvac24024; Mon, 19 Dec 1994 18:38:34 -0500 Date: Mon, 19 Dec 1994 18:38:34 -0500 Message-Id: From: Joseph Malcolm To: "William Allen Simpson" Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: <3574.bill.simpson@um.cc.umich.edu> References: <3574.bill.simpson@um.cc.umich.edu> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM William Allen Simpson writes: >> From: Robert Elz >> A major concern here is >> handling DNS packets. With 16 byte addresses, and potentially >> on average many more addresses/node than IPv4 allocates, plus >> DNS security signatures, etc, the DNS really needs to be able to >> count on sending the biggest possible UDP packet we can reasonably >> give it. I don't know about you, but I don't think I want my >> DNS server attempting MTU discovery on every answer it sends. >> Further, if the answers don't fit across your low MTU link, what >> you're likely to get is a truncated response, which should get >> your client to attempt the query again with TCP. > >I agree that it is a concern. We should eliminate UDP for IPv6 DNS. I see. And you would like to replace it with TCP? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 16:45:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11120; Mon, 19 Dec 94 16:45:49 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11114; Mon, 19 Dec 94 16:45:42 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id QAA04476; Mon, 19 Dec 1994 16:40:09 -0800 Received: from netcom19.netcom.com by Sun.COM (sun-barr.Sun.COM) id AA02240; Mon, 19 Dec 94 16:40:08 PST Received: by netcom19.netcom.com (8.6.9/Netcom) id QAA26434; Mon, 19 Dec 1994 16:39:59 -0800 Date: Mon, 19 Dec 1994 16:39:59 -0800 From: kck@netcom.com (Richard Fox) Message-Id: <199412200039.QAA26434@netcom19.netcom.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >ns.uu.net answers 30 queries a second on average, 24x7. It's not clear >to me that the set of machines that query it is small enough to make >PMTU discovery feasible, unless it is vastly less expensive than I >expect. If the PMTU is calculated on the query to the server and the value is stored (ie: like the arp cache, or in the arp cache) or if the value is passed up the interface (if known otherwise the value is 0 or something), then the cost of doing PMTU is free. Some of the can of worms is: 1) return path is the same as the path request travelled. 2) Changes PMTU slightly. 3) Requires packets to be changed on the fly 4) New code, possibly new API on DNS server 5) requires packets to be changed on the fly. Notice that 3) and 5) are the same. I would assume this would be the big sticklier. Of course if there is a way around this one particular defect then we would be in business. --rich ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 19:25:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11179; Mon, 19 Dec 94 19:25:33 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11173; Mon, 19 Dec 94 19:25:26 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id TAA18775; Mon, 19 Dec 1994 19:19:54 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA21881; Mon, 19 Dec 94 19:19:54 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA13533; Mon, 19 Dec 94 19:18:23 -0800 Received: by xirtlu.zk3.dec.com; id AA06160; Mon, 19 Dec 1994 22:17:27 -0500 Message-Id: <9412200317.AA06160@xirtlu.zk3.dec.com> To: perry@imsi.com Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Mon, 19 Dec 94 17:04:21 EST." <9412192204.AA09015@snark.imsi.com> Date: Mon, 19 Dec 94 22:17:21 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM <9412192108.AA00542@xirtlu.zk3.dec.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 19 Dec 1994 17:04:21 -0500 From: "Perry E. Metzger" bound@zk3.dec.com says: > IMHO not as employee of my company, I > think applications like DNS should bite the bullet and absorb PMTU. >The amount of state you would need to maintain in, say, a root >nameserver, would be rather prohibitive... Not when the Root Server is a dedicated system to only that task. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 19:44:06 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11203; Mon, 19 Dec 94 19:44:06 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11197; Mon, 19 Dec 94 19:43:59 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id TAA20114; Mon, 19 Dec 1994 19:38:27 -0800 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA23384; Mon, 19 Dec 94 19:38:28 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA13103; Mon, 19 Dec 94 19:33:15 -0800 Received: by xirtlu.zk3.dec.com; id AA06295; Mon, 19 Dec 1994 22:33:12 -0500 Message-Id: <9412200333.AA06295@xirtlu.zk3.dec.com> To: Joseph Malcolm Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Mon, 19 Dec 94 17:23:04 EST." Date: Mon, 19 Dec 94 22:33:06 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >ns.uu.net answers 30 queries a second on average, 24x7. It's not clear >to me that the set of machines that query it is small enough to make >PMTU discovery feasible, unless it is vastly less expensive than I >expect. Queries for what? Is this a DNS server I don't use uunet as much as I should so educate me more? Is it a TCP app issue or UDP app issue? One thing that needs more experimentation is use of PMTU by UDP and there are thresholds you can use as your MTU default I would presume as today. This way you just only send that MTU unless it must be smaller of course. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 20:53:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11224; Mon, 19 Dec 94 20:53:00 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11218; Mon, 19 Dec 94 20:52:52 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id UAA24098; Mon, 19 Dec 1994 20:47:20 -0800 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA28896; Mon, 19 Dec 94 20:47:21 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA17321; Mon, 19 Dec 94 20:41:13 -0800 Received: by xirtlu.zk3.dec.com; id AA07283; Mon, 19 Dec 1994 23:41:08 -0500 Message-Id: <9412200441.AA07283@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: (IPng) PMTU TCP for DNS Date: Mon, 19 Dec 94 23:41:02 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi, Paul Vixie asked me to forward this message to the list. thanks /jim Return-Path: vixie@gw.home.vix.com Received: from decvax.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Sep94-0829AM) id AA01695; Mon, 19 Dec 1994 22:58:45 -0500 Received: from gw.home.vix.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA07402; Mon, 19 Dec 1994 22:58:42 -0500 Received: by gw.home.vix.com id AA10604; Mon, 19 Dec 94 19:54:54 -0800 Message-Id: <9412200354.AA10604@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: bound@zk3.dec.com Cc: dee@lkg.dec.com, set@thumper.bellcore.com, yakov@watson.ibm.com Subject: Re: DNS to TCP In-Reply-To: Your message of "Mon, 19 Dec 1994 22:38:40 EST." <9412200338.AA06364@xirtlu.zk3.dec.com> Date: Mon, 19 Dec 1994 19:54:53 -0800 From: Paul A Vixie Jim, > What are your thoughts? > > If you want to respond to ipng directly i can send you the address. I would like you to forward my comments to IPng. > Some discussion on IPng mail list about Path MTU Discovery. Its creates > some of a problem for UDP. In IPv6 its required. The discussion asks > should we require DNS to use TCP in IPv6? These questions, as you've stated them, aren't related. DNS datagrams are limited to 512 payload octets, whether carried by IPv4 or IPv6. Until we extend DNS to permit clients and servers to advertise or otherwise negotiate the size of the requestor's receive buffer, path MTU doesn't matter. And when we do, IP fragmentation will cover those cases where a response is larger than that MTU. Where the IP fragmentation is not supported (or, if we want to set the DF (don't fragment) option to force it off), DNSv2 clients which detect such lossage will have to retry with TCP. This may require that the server detect the inability to fragment and send back an intentionally truncated response so that the clients will know to retry; in this narrow corner of the problem space, it could be appropriate for the server to use path MTUD to maximize the client's advertized receive buffer and just tell the client to use TCP without trying UDP at all. Using TCP at all times would create an instantaneous crisis in network bandwidth and name server load. Consider a root server which answers 50 queries per second. Can it do that with TCP? Can its T1 (or whatever) link handle that? The net is growing in capacity, as are host resources, but I predict that the DNS load will always stay in the "can be done by UDP, can't be done by TCP" range. Thanks for asking, Paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 22:35:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11315; Mon, 19 Dec 94 22:35:07 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11286; Mon, 19 Dec 94 21:49:52 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id VAA26421; Mon, 19 Dec 1994 21:44:19 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA02968; Mon, 19 Dec 94 21:44:16 PST Received: from wcc.oz by munnari.oz.au with SunIII (5.83--+1.3.1+0.50) id AA05461; Tue, 20 Dec 1994 16:44:11 +1100 (from tom@wcc.oz.au) Message-Id: <9412200544.5461@munnari.oz.au> Date: 20 Dec 94 16:33:14 +1100 (Tue) From: tom@wcc.oz.au (Tom Evans) To: anf-disc%cisco.com@munnari.OZ.AU Subject: (IPng) Re: Minimum link MTU of 1500 Cc: ipng@sunroof.eng.sun.com@munnari.OZ.AU Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Sat, 17 Dec 1994 23:34:20 -0500 > From: "Perry E. Metzger" > Reply-To: ipng@sunroof.eng.sun.com > > Localtalk will be gone in five years. > ... I'd say that we > aren't so much building fragmentation into the model as recognising > that there is no point in keeping the MTU low for the benefit of a few > dying platforms. > OK, folks: There's your ultimatum! Last week, I asked that you send your comments to ipng, and haven't seen anything yet. If you want AppleTalk to be supportable into the future, "speak now, or forever hold your peace". It isn't just "LocalTalk". AppleTalk has a maximum packet size of 600 bytes on ANY media, and you can run IP-through-EtherTalk and TokenTalk as well as you can over LocalTalk. TCP-IP-over-AppleTalk-via-Apple-Remote-Access is very popular. Then there'all those Apple Ethernet cards with the inaccurate crystals that can't actually send any packet much over 600 bytes... :-) ======================== Tom Evans tom@wcc.oz.au Webster Computer Corp P/L, 11 Glenvale Crescent Mulgrave, Melbourne 3170 Victoria, Australia 61-3-561-9999 FAX ...560-0067 A.C.N. 004 818 455 From anf-disc-request%cisco.com@munnari.oz Tue Dec 20 10:50:36 1994 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14947; Tue, 20 Dec 1994 07:08:09 +1100 (from anf-disc-request@cisco.com) Received: (daemon@localhost) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) id LAA22923 for outbound-anf-disc; Mon, 19 Dec 1994 11:55:14 -0800 Received: from merit.edu (merit.edu [35.1.1.42]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id LAA22917 for ; Mon, 19 Dec 1994 11:55:11 -0800 Received: from Bill.Simpson.DialUp.Mich.Net (pm036-16.dialip.mich.net [141.211.7.58]) by merit.edu (8.6.9/merit-2.0) with SMTP id OAA04904 for ; Mon, 19 Dec 1994 14:55:05 -0500 Date: Mon, 19 Dec 94 19:45:07 GMT From: "William Allen Simpson" Message-Id: <3577.bill.simpson@um.cc.umich.edu> To: anf-disc@cisco.com Reply-To: bsimpson@morningstar.com X-Deleted-Errors-To: anf-disc-request@cisco.com X-Comment: List additions/deletions to: anf-disc-request@cisco.com X-Disclaimer: The use of cisco machines does not mean that X-Disclaimer: postings made to this mailing list are the X-Disclaimer: official opinions of cisco Systems, Inc. Precedence: bulk > Date: Sat, 17 Dec 1994 23:34:20 -0500 > From: "Perry E. Metzger" > Reply-To: ipng@sunroof.eng.sun.com > > Localtalk will be gone in five years. Ran Atkinson's famous satelites > are of concern only to some people in the military. I'd say that we > aren't so much building fragmentation into the model as recognising > that there is no point in keeping the MTU low for the benefit of a few > dying platforms. > OK, folks: There's your ultimatum! Last week, I asked that you send your comments to ipng, and haven't seen anything yet. If you want AppleTalk to be supportable into the future, "speak now, or forever hold your peace". Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 19 23:04:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11336; Mon, 19 Dec 94 23:04:25 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11330; Mon, 19 Dec 94 23:04:17 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id WAA29649; Mon, 19 Dec 1994 22:58:44 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA08206; Mon, 19 Dec 94 22:58:44 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08663; Tue, 20 Dec 1994 17:58:32 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Cc: Paul A Vixie Subject: Re: (IPng) PMTU TCP for DNS In-Reply-To: Your message of "Mon, 19 Dec 1994 23:41:02 CDT." <9412200441.AA07283@xirtlu.zk3.dec.com> Date: Tue, 20 Dec 1994 17:58:30 +1100 Message-Id: <3115.787906710@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 19 Dec 1994 19:54:53 -0800 From: Paul A Vixie DNS datagrams are limited to 512 payload octets, whether carried by IPv4 or IPv6. I think an assumption was missed here - that is, that if the minimum MTU for IPv6 were raised to somewhere around 1500, then the DNS spec would be quickly ammended to permit sending DNS datagrams over IPv6 of a size approaching that (subtract away some space for headers). That is, while even for IPv6 this might be useful ... Until we extend DNS to permit clients and servers to advertise or otherwise negotiate the size of the requestor's receive buffer, It wouldn't be a barrier to sending larger IPv6 DNS packets, or needn't be. And when we do, IP fragmentation will cover those cases where a response is larger than that MTU. Except that for IPv6 only the sender can request fragmentation, its never done gratuitously by routers along the path. If you ever want to send packets larger than the guaranteed minimum MTU, the source has to insert a fragmentation header, and do the fragmentation itself. That means it has to use PMTU Disc to figure out how large the fragments should be. That or just allow the response to be dropped, and then hope the client will figure out the problem and try again woth TCP. (Or of course, send a smaller packet, marked truncated, as a hint.) Using TCP at all times would create an instantaneous crisis This I agree with. I'm not sure that load itself is the real issue here, DNS traffic isn't so huge that changing from a 2 packet model, to a 3 packet (transaction tcp) type for average queries (or more for big ones, but fragmented UDP is more too) is going to be a disaster. Nor need the server load be that much greater, a nice API to transaction TCP that looked just like the current UDP would cause a lot of that to go away. What bothers me is the prospect of all of those TCP connection status blocks hanging about in TIME_WAIT state for minutes after every DNS query. That would truly be something to contemplate! Paul, let me ask a different question - do you think the DNS would benefit, and if so by how much, by being able to send larger packets (without negotiation) with IPv6? Forget IPv4 here, its not relevant. Do take into account 16 byte addresses, DNS security, and the liklihood that interfaces with one address now could have several with IPv6. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 20 11:55:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11756; Tue, 20 Dec 94 11:55:19 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11726; Tue, 20 Dec 94 11:17:54 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA15070; Tue, 20 Dec 1994 11:12:22 -0800 Received: from guest.apple.com by Sun.COM (sun-barr.Sun.COM) id AA09720; Tue, 20 Dec 94 11:12:22 PST Received: from seeding.apple.com by guest.apple.com with SMTP (5.64/8-Feb-1993-eef) id AA23699; Tue, 20 Dec 94 11:11:56 PST for ipng@sunroof.eng.sun.com Date: Tue, 20 Dec 94 11:19:41 PDT From: Garry Hornbuckle Subject: (IPng) Re: Minimum link MTU of 1500 To: bsimpson@morningstar.com, ipng@sunroof.Eng.Sun.COM Cc: hornbuckle1@applelink.apple.com X-Mailer: LeeMail 2.0.1 Message-Id: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> Date: Sat, 17 Dec 1994 23:34:20 -0500 >> From: "Perry E. Metzger" >> Reply-To: ipng@sunroof.eng.sun.com >> >> Localtalk will be gone in five years. Ran Atkinson's famous satelites >> are of concern only to some people in the military. I'd say that we >> aren't so much building fragmentation into the model as recognising >> that there is no point in keeping the MTU low for the benefit of a few >> dying platforms. >> >OK, folks: There's your ultimatum! > >Last week, I asked that you send your comments to ipng, and haven't seen >anything yet. If you want AppleTalk to be supportable into the future, >"speak now, or forever hold your peace". > I disagree with and object to the conclusions above in the most strenuous terms. Apple has no plans to drop LocalTalk support from the Macintosh platform. There is an installed based of well over 15 million Macintosh nodes supporting this datalink, and Apple is currently shipping CPUs on a 4M+/yr run rate - with LocalTalk support. AND THESE NUMBERS ARE JUST ONE PLATFORM FROM ONE VENDOR. LocalTalk is also supported in almost every PostScript printer in the marketplace (hundreds of different devices from dozens of vendors), in many of the new Personal Digital Assistants (PDAs), and in a very wide variety of embedded communications interface applications (such as theater scenary and lighting controllers, point of sales devices, and data collection interfaces for things like slot machines). EVEN IF ONE WAS SO UNCONCERNED WITH CUSTOMER SATISFACTION AS TO IGNORE THE INSTALLED BASE ISSUES, LOCALTALK IS NOT A DYING PLATFORM. At least as I recall from reading the IPng requirments, _ease of migration_ was designated as a primary acceptance and success criteria. IMHO, there is no possibility of remaining true to this principle while disregarding the LocalTalk MTU issue. ----------------------------------------------------------------------- Garry Hornbuckle Product Manager, Communications & Collaboration ----------------------------------------------------------------------- "If I told you that I | email garryh@seeding.apple.com spoke only for myself | applelink HORNBUCKLE1 would you believe me?" | fax (408) 974-1211 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 20 12:23:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11793; Tue, 20 Dec 94 12:23:35 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11787; Tue, 20 Dec 94 12:23:23 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id MAA21721; Tue, 20 Dec 1994 12:17:50 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA22873; Tue, 20 Dec 94 12:17:48 PST Received: from relay.imsi.com by wintermute.imsi.com id PAA10072 for ; Tue, 20 Dec 1994 15:17:40 -0500 Received: from snark.imsi.com by relay.imsi.com id PAA18516 for ; Tue, 20 Dec 1994 15:17:39 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA10837; Tue, 20 Dec 94 15:17:39 EST Message-Id: <9412202017.AA10837@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: Minimum link MTU of 1500 In-Reply-To: Your message of "Tue, 20 Dec 1994 11:19:41 PDT." X-Reposting-Policy: redistribute only with permission Date: Tue, 20 Dec 1994 15:17:38 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Garry Hornbuckle says: [lots about why Localtalk will be in use for seventy thousand years.] Fine. I'll grant you that Apple will be selling Localtalk for the next century (even though it isn't true). Given that you already handle fragmentation (at the network layer for IPv4), why is it that you can't handle fragmentation at the link layer for IPv6? I still see no reason that we should support small MTUs so that Apple IPv6 authors can avoid writing code. There is no reason to believe that link level fragmentation for Appletalk would be difficult. The comments by the LocalTalk partisans have only served to confirm the earlier opinion that I formed on this subject. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 20 15:40:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11928; Tue, 20 Dec 94 15:40:30 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11922; Tue, 20 Dec 94 15:40:18 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id PAA12690; Tue, 20 Dec 1994 15:34:43 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA28430; Tue, 20 Dec 94 15:34:44 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-25.dialip.mich.net [35.1.48.106]) by merit.edu (8.6.9/merit-2.0) with SMTP id SAA21940; Tue, 20 Dec 1994 18:34:36 -0500 Date: Tue, 20 Dec 94 23:07:43 GMT From: "William Allen Simpson" Message-Id: <3587.bill.simpson@um.cc.umich.edu> To: anf-disc@cisco.com Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Long Ethernet frames Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Mick Seaman > My apologies for just entering this discussion, It just started. Now is the time. However, much of your argument makes no sense to me. You can't possibly "bridge/switch" a long FDDI frame onto a 10base-x link. Likewise, you can't "bridge/switch" a long 100base-x frame onto a 10base-x link. The electrical specifications won't allow it. And of course, these are the hated "multi-media bridges", which many would like to make impossible. > I'm not sure whose > opinions I am replying to here, however there seems to be a dangerous > piece of short sightedness going on below. I refer to the notion > that V2.0 DIX encoding is the only necessary encoding of IP on > `ethernet', IPv4 or IPv6. > > The fact that there is no existing IPv6 using an 802.2 (actually an > 802 'SNAP SAP' with OUI 00-00-00) header should not preclude this in > the future. If anyone wishes to make this restriction a serious > proposal I suggest they study all the bridging/switching > configurations including those of the form network type A - type B - > type A (e.g. Ethernet - FDDI - Ethernet) and of the form A - B - C > (looking for natural reversibility of transformations). Having been > involved in the cleanup of the Appletalk Phase I/Phase II bridging > debacle which was very largely caused (in my view) by inadequate > analysis behind rfc1042, I am particularly sensitive to the > deficiencies of just considering packet formats without looking at > service mappings and translations. No switch/bridge/router vendor > wants to have to do another 802.1H. > > It seems likely that 100 Mb/s Ethernet (802.3) will be used with 4500 > byte frames in the future. Some early (non-standard) products have > this capability. With these long frames it is no longer possible to > distinguish between DIX EtherTypes and 802 length fields by saying > that all EtherTypes are greater than any posible length (take for > example IP). There seem to be four options available: (a) invent yet > another frame format, (b) declare that all frames with physical > lengths in excess of 1518 are encoded using 802/802.2 formats, (c) > declare that all frames with physical lengths in excess of 1518 are > encoded using DIX EtherTypes, (d) make a mess of it by special casing > IP, all others as (b), (e) mandate that all switches/bridges/stations > attached to a `long' 100 Mb/s Ethernet treat it differently from > `short/normal' Ethernet. > Option (a) is the only possible option. It is often not possible to know when the frame is "in excess" until after you have received the frame. Either all 100base-x links have to support the longer length, or none of them can send it. Finally, (e) is certainly true already when using 802.4 and 802.5, so why wouldn't it be for 100base-x? > Option (e) just isn't an option. Personally I favor option (b). It > allows for the full 802 range of protocol identifiers, including SNAP > PIDs, and minimises the work on bridging/switching translation between > FDDI and `long' Ethernet, as well as between `long' Ethernet and some > other fast transmission media. The downside is that it implies both > DIX and `1042' (1143) framings of IP on Ethernet physical media, > possibly within a single conversation. > > However the important point is not my particular preference, but the > fact that this choice is currently possible. A lot of thought needs to > go into this subject before this is ruled out, otherwise we will be > overconstrained into agreeing on some further ghastly hack. No > answer in this space is so obvious it doesn't need explict public > airing. > > Mick > > ------------------- > > Date: Tue, 20 Dec 1994 17:18:39 +1100 > From: Robert Elz > Date: Mon, 19 Dec 94 13:37:18 PST > From: "David S.A. Stine" > Message-ID: <199412192139.NAA14674@feta.cisco.com> > > Some people seem to want to just say "all we do is ARPA V2 > on ethernet-style media, end of story." > > The idea is that IPv6 uses exactly the same encapsulation, > where possible, as IPv4, that's why it has a "6" in the first > 4 bits of the packet, where IPv4 has a "4". On ethernet, IPv4 > is sent as "ARPA" (aka DIX) encapsulated packets, with 0x800 > in thge "type" (aka "length") field (the last 2 butes of the 14 > byte ethernet header). On IPv6 the same will happen, this > question was never really discussed because the answer was so > obvious. > > The only reason IPv4 even permits (in hosts requirements) that > 802.2 framing be used over ethernet, is that some vendors had > actually managed to implement it that way, somehow, and a > mechanism had to be allowed that would permit their old equipment > to interoperate with new (compliant) stuff. DIX encapsulation > is required, 802.2 is permitted as an option (default off). > > Since there are no existing commercial IPv6 implementations > using 802.2 wrapping, there's absolutely no reason to allow it > at all (it doesn't gain anything useful, the "length" is in the > IP header, that's the only thing missing from the SAP/SNAP > encoding when using DIX). It could only possibly be one more > thing for local end-users to be able to misconfigure (the fact > that they'd need to configure it at all goes against all the > autoconfig work being done for IPv6 - we don't want anything > that users have to config before they can use the net). > > This 1492 vs 1500 distinction is a total red herring, and isn't > worth wasting time on. > > - Satellite links with an MTU of ~1K are being brushed aside with the > same ease with which they dismiss LocalTalk. > > Well, not exactly - with more ease, there are just a few of > those things, they affect only the US Military (breaking US > Military uses may have some useful propoganda value), and without > doubt ways to work around that can be found. > > There's MUCH more localtalk around (and its really not going > to go away), and it is the hardest of the (so far known) > media with a problem to overcome - but its certainly not very > difficult (I have written IP over appletalk code, it's not > exactly a complex process, and what of it is complex isn't > the encapsulation, its the NBP ARP nonsense). > > - They haven't considered Frame Relay or X.25 switches with > 1K datagrams > > IPv4 has worked over X.25 with 128 byte datagrams without > fragmenting to that absurdly low value. X.25 (incl F.R.) is > a circuit service, you can send pseudo-packets of however long > you like very easily, they don't have to map 1:1 with the > circuit service's idea of a packet. (Consider ATM...) > > - AX.25 seems to not have been thought of at all. > > I know much less about this one, however I would expect that > much the same would be true of it. > > So, given all these issues that the IPng WG is willing to blithely bush > aside or happily ignore, I doubt that the ANF's injection of a few > salient facts into the discussion will change their previously decided > minds. > > We would have to see the ANF's "salient facts" first. For a > long time, appletalk was indeed keeping the magic number at > 576 (or perhaps 586, just so no-one would confuse it with the > IPv4 576 number which is totally unrelated to any of this). > The problems there were taken quite seriously, it was only > after a lot of discussions that a tentative decision was taken > to increase the limit. > > There's no question that encoding IPv6 in Appletalk (and truly > here "localtalk" is not what you mean, Appletalk has a 586 > byte limit over ethernets too) will be more difficult if the > MTU is required to be > 587, it certainly won't be impossible. > If we could rely on Appletalk keeping RTMP routing, it could be > made very simple, its only the prospect of there one day > perhaps being a real routing protocol that makes it more > difficult (the problem is purely packets being delivered out > of order, handling that is what causes appletalk's extra work > over the others). > > The question really is whether the benefits of a bigger > guaranteed MTU (and there are many - eg: the ability to know > I can send a certain size packet safely, very useful to the DNS, > and that anything connected to an ethernet wouldn't really need > to bother with PMTU discovery, as the minimum would always be the > local leg) is worth the cost of the extra work needed in IP over > Appletalk implementations, and the IP over other things, though > I believe all the other things are rather easier to solve. > > kre > Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 20 18:43:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12030; Tue, 20 Dec 94 18:43:47 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12024; Tue, 20 Dec 94 18:43:35 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id SAA27188; Tue, 20 Dec 1994 18:38:02 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA22136; Tue, 20 Dec 94 18:38:00 PST Received: by rodan.UU.NET id QQxveg27508; Tue, 20 Dec 1994 21:37:59 -0500 From: stripes@uunet.uu.net (Josh Osborne) Message-Id: Subject: Re: (IPng) Long Ethernet frames To: ipng@sunroof.Eng.Sun.COM Date: Tue, 20 Dec 1994 21:37:59 -0500 (EST) In-Reply-To: <3587.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Dec 20, 94 11:07:43 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [...] >> The question really is whether the benefits of a bigger >> guaranteed MTU (and there are many - eg: the ability to know >> I can send a certain size packet safely, very useful to the DNS, >> and that anything connected to an ethernet wouldn't really need >> to bother with PMTU discovery, as the minimum would always be the >> local leg) [...] I actually think the "ethernet doesn't need to PMTU" is a disadvantage. It will encurage people not to do PMTU (other more pressing issues will get their time), and that will increse the hardships felt when going to a media that handles larger packets. Not that this outweighs making the MTU bigger (even to 1500), I just wouldn't list it as an advantage. -- Not speaking for UUNET Technologies ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 20 23:59:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12112; Tue, 20 Dec 94 23:59:11 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12104; Tue, 20 Dec 94 23:59:01 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id XAA07782; Tue, 20 Dec 1994 23:53:26 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA14441; Tue, 20 Dec 94 23:53:26 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA08865; Wed, 21 Dec 1994 08:53:24 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA13228; Wed, 21 Dec 1994 08:53:22 +0100 Message-Id: <9412210753.AA13228@dxcoms.cern.ch> Subject: (IPng) NOSI BOF FYI To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Date: Wed, 21 Dec 1994 08:53:20 +0100 (MET) From: "Brian Carpenter CERN-CN" X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [This is sent FYI only to the ipng-wg list. If you want to flame, please join the NOSI list to do so - instructions are included below. Please do not reply on the IPNG list.] Minutes of Next Generation and OSI BOF (NOSI) held 8 December 1994 ------------------------------------------------------------------ About 35 people attended this BOF, chaired by Brian Carpenter. In the IPv6 base document, and in discussions in the Toronto IETF, it was suggested that it would be useful to be able to map NSAP addresses into IPv6 addresses. This appears to be related to CLNP to IPv6 transition. However, there is no consensus on whether IETF needs to do anything in this space (for example, work might be done in ISO instead). We need to understand the requirements first, then consider work items, and where (what group) they should be done. Thus, the agenda for this BOF: - Agree on general OSI to IPv6 conversion requirements - Agree on major network layer scenarios - Identify useful mechanisms and hear from their proponents SC6 (ISO/IEC JTC1/SC6) presumably has an issue, regarding whether to continue work on CLNP. We might want to consider (as individuals) giving some ideas to them. Note that Jack Houldsworth was present in the BOF as ISO Liaison. DEC is also planning support for customers using DECNET Phase V (using CLNP) to use DECnet over IP -- we would like to understand from the DEC folks how this is being done. Question from the floor: What is the forum for experimental work on OSI applications over the Internet? Nobody had an answer. Brian Carpenter presented Conversion Requirements r1. existing CLNP networks want to migrate to TP4 over IPv6 r2. existing CLNP network wants to migrate to Internet aplications over IPv6 r3. planned CLNP net changes plan to instead go to TP4 over IPv6 r4. planned CLNP network change their plan to instead to internet application over IPv6 r5. TP0/CONS net wants to migrate to TP0 over IPv6 r6. (are there others?) It was pointed out that the "TP4" and "TP0" in above requirements should really say "OSI applications". Customers don't care which transport layer protocol is being used. The API over the transport layer may need to stay the same. It was also pointed out that the above requirements are not mutually exclusive; they just show the range of possibilities. Brian then gave four possible secnarios for the network layer: Proposal 1: The final goal is a pure IPv6 network with pure IPv6 addresses, with no trace of CLNP nor NSAPs. + simple end scenario - CLNP investment lost (This last point is controversial; some knowledge may be maintained, and the knowledge that is maintained may be the bulk of the retrievable investment) Proposal 2: Final goal is an IPv6 network in which some hosts have NSAP addresses + (?) NSAP addressing plans preserved (this alleged advantage was vigorously debated, with some folks feeling that there is no significant advantage either way, in that the bulk of the effort can be used even if the exact 20 byte addresses aren't). - extra complexity in hosts and routers - two address plans connected only by IDRP (it was politely pointed out that this is bogus) - no CLNP service despite having OSI addresses Proposal 3: Final goal is a pure IPv6 network with a pure IPv6 addressing and routing, but NSAP addresses are transported end-to-end as an option. + preserves NSAP plans as pseudo-EID + complexity limited to participating hosts - two independent addressing schemes - still no CLNP service Proposal 4: Tunnel CLNP over IPv6 + no modification to IPv6 + preserves CLNP investment - CLNP hosts only see each other There was no discussion about the viablility of scenarios 1 and 4. However, #3 found little support and #2 is controversial (see later discussion on address mapping). Mechanisms: M0: the Null mechanism: Tell CLNP users to run IPv6. M1: develop a CLNP to IPv6 transition plan ("Avoid Brutal User Transition" (ABUT)) + stepwise transition like SIT/TUBA - some folks think that this might be expensive (not clear what they mean by "expensive", or what is the alternative) M2: Squeeze NSAPs into 16 bytes - does not appear to explain all of the transition steps that are necessary M3: Map IPv6 addresses within the NSAP format + useful for stepwise transition - this also is not complete plan (may be part of M1, for example). M4: Carry full NSAPs in IPv6 extension headers + preserve rull NSAP space - complicates routing (how, details uncertain) - implementation complexity M5: Carry NSAPs as end-to-end option M6: Encapsulation of CLNP over IPv6: nextheader=CLNP (this is easy given current standards and software) M7: Update RFC 1006 (TP0 or TP4 over TCP over IP) (seems to be simple) M8: Support TP4 directly over IPv6 (this is easy given current standards and software) M9: Map NSAPs to IPv6 addresses via DNS. Ross Callon gave an overview of ABUT (TUBA backwards) which he will summarise for the mailing list. Essentially it is a dual stack transition as proposed for TUBA and IPv4 to IPv6. Jim Bound gave a description of a mechanism for mapping NSAPs into 16 byte IPv6 addresses. - Split CLNP address into a high part and low part - Map the high part and recombine with the low part For details see draft-carpenter-ip6-nsap-map-00.txt. This draft is alleged to cover all known *deployed* CLNP addressing schemes (ICD and DCC formats with unused and reserved bytes deleted). Proponents of other schemes need to show why this is insufficient. Ross pointed out that the ABUT transition scheme does not require any particular relationship between CLNP and IPv6 addresses. Each organisation can use whatever means it wants (assuming that the addresses are topologically reasonable). It is permitted and reasonable to use the Jim/Brian address mapping, buty ABUT does *not* require that all organisations coordinate their means of mapping NSAPs into IPv6 addresses. Jack Houldsworth gave an overview of NSAPs. He pointed out the flexibility of NSAPs (for example, the ability to encode X.121, F.69, E.163 and E.164, etc). One question came up regarding which of these formats are actually used? Clearly E.164, DCC, and ICD are being used. Perhaps the biggest difference between NSAPs and IPv6 addresses is that NSAPs explicitly allows embedding of many different other address families, whereas IPv6 addresses are expected to be assigned for IPv6 in a topological / well packed manner. Jack also proposed a scheme where the IPv6 address field would be the "top" of an NSAP, with the leftover part in an IPv6 option. For details see draft-houldsworth-ip6-nsap-use-00.txt. A transition mechanism for ABUT was proposed by Ross Callon here.If what comes back from DNS is an IPv6-type NSAP address, then use simple IPv6. Otherwise, do another DNS lookup to map the "real" NSAP into IPv6, and then encapsulate the full NSAP address. We could first migrate the CLNP world towards trivially IPv6-mappable addresses. Alan Lloyd discussed options for sorting out addressing. His goals are: To provide "harmonisation" betwen ISO NSAPs and IPv6 addresses; To permit ISO to administer some of the IP address blocks; To provide a network design approach that enables address convergence to IPv6. He stated a requirement: to have compatible address forms for NSAPs and IPv6. IPv6 in NSAPS are easy. For NSAPs in IPv6, propose to assign first bytes of IPv6 addresses to be compatible with some NSAP AFIs. These need to use assigned NSAPs which fit into 16 bytes. This thereby allows "bi-lingual" addresses. For details see draft-lloyd-ip6-iso-itu-reg-00.txt. The view that IPv6 addresses and NSAP addresses (such as those for ATM) should be harmonised, i.e. part of the same global address space, was strongly defended by Alan Lloyd. [However it seems to be at odds with the architectural view of IP as "one protocol to bind them all" with an over-riding address space. This architectural issue was not clearly identified during the BOF, but has since been raised on the mailing list. Further debate on this is required.] Multiple people were concerned about the implications of splittng the NSAP address between two parts of the header -- the first "n" bits in the IPv6 address, and the rest in an extension. Keith Sklower was concerned about embedding the NSAP length as the high order part of the address, since this causes an explosion in the number of routing entries in forwarding tables. Jim Bound and Ross Callon expressed support for the notion of providing a graceful migration from CLNP to IPv6, but also expressed strong concern with specific technical aspects of Alan's proposal, stating that the proposal had to work well and be implementable, reasonable efficient, and manageable. Dan Harrington, DEC presented an alternative proposal. The "top" of an NSAP (actually the part useful for routing) is in the IPv6 address, and the entire NSAP is carried in a header extension. This is similar to the Houldsworth/Lloyd proposals but perhaps slightly cleaner. It appears that all of these proposals are compatible with the ABUT transition scheme, in which either CLNP or IPv6 is used end to end for any particular datagram. Work Items: - description of the ABUT plan (Ross Callon) - address mapping needs to be worked on (all, combined proposal needed) - tunneling (simple, but volunteer needed) - TP4 over IPv6 (new work, volunteer needed) - RFC1006+ (fairly simple, Scott Bradner was heard to volunteer) action items: proposers will write up their own proposals if not done. We expect to meet again in Danvers. The objective would be to decide whether ABUT and/or a combined address mapping proposal should be followed up (WG chair and activists needed for that). The architectural issue about address space harmonisation also needs to be resolved. To subscribe to the NOSI mailing list, use majordomo@sunroof.eng.sun.com, and say "subscribe nosi" in the text. At present this is not an archived list. (Notes taken by Ross Callon and edited by Brian Carpenter) -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 21 04:53:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12312; Wed, 21 Dec 94 04:53:18 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12306; Wed, 21 Dec 94 04:53:05 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id EAA19228; Wed, 21 Dec 1994 04:47:31 -0800 Received: from pamir.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA08745; Wed, 21 Dec 94 04:47:30 PST X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 21 Dec 94 13:47:29+0100 X400-Received: by /PRMD=cnet/ADMD=atlas/C=FR/; Relayed; 19 Dec 94 18:27:40+0100 Date: 19 Dec 94 18:27:40+0100 From: William Allen Simpson Message-Id: <3574.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I'm just back, and trying to catch up on 1.7 MB of email (since IETF). The following comment (together with Perry's) caused me to go through the roof. > From: Robert Elz > Just a comment on one other issue - whether its more or less > effecient to do link level fragmentation/reassembly for those > links that can't handle 1500. They're almost always slow (all > that I have heard about are), so the compute burden shouldn't > be much. Folks, I am tired of hearing that anything less than ethernet speeds are "slow". By usual terminology, a low speed link is <= 2400 bps. A medium speed link is <= 28.8 Kbps. Anything greater (57.6 Kbps) is high speed. T1 is very high, T3 is ultra high, and both are way beyond the budget of most people or businesses. The bad assumption here is that there is any more compute power leftover. We are talking 186s or worse here. They can barely keep up with simple framing over medium speed links. Macs achieve 115 Kbps by doing a tight loop which hangs the entire system. There is no power available for special link layer fragmentation. Indeed, we had to eliminate IP layer fragmentation for cellular (IS-99). Also, we are talking _current_ hardware, not some old leftover junk. These devices are being made in the 10s of millions, far more than those silly workstation and router vendors can dream of shipping. We had these same kind of arguments in PPP -- high speed, big ticket vendors versus the rest of us. On a vote, they always win, since the rest of us can't afford to send people to IETF. Not everyone is willing to spend 1/4 of their income each year going to damn meetings. I've been doing it for love, but .... And no, Phil Karn was not in the room. I was looking to him for support. > A major concern here is > handling DNS packets. With 16 byte addresses, and potentially > on average many more addresses/node than IPv4 allocates, plus > DNS security signatures, etc, the DNS really needs to be able to > count on sending the biggest possible UDP packet we can reasonably > give it. I don't know about you, but I don't think I want my > DNS server attempting MTU discovery on every answer it sends. > Further, if the answers don't fit across your low MTU link, what > you're likely to get is a truncated response, which should get > your client to attempt the query again with TCP. I agree that it is a concern. We should eliminate UDP for IPv6 DNS. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 21 06:23:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12412; Wed, 21 Dec 94 06:23:53 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12406; Wed, 21 Dec 94 06:23:46 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA22102; Wed, 21 Dec 1994 06:18:11 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA16169; Wed, 21 Dec 94 06:18:06 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17547; Wed, 21 Dec 1994 23:49:13 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Mon, 19 Dec 1994 16:26:28 GMT." <3574.bill.simpson@um.cc.umich.edu> Date: Wed, 21 Dec 1994 23:49:12 +1100 Message-Id: <3268.788014152@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 19 Dec 94 16:26:28 GMT From: "William Allen Simpson" Message-ID: <3574.bill.simpson@um.cc.umich.edu> Folks, I am tired of hearing that anything less than ethernet speeds are "slow". By usual terminology, a low speed link is <= 2400 bps. A medium speed link is <= 28.8 Kbps. Anything greater (57.6 Kbps) is high speed. Bill, you need to change with the times ... Go back a while, and a man walking was slow, a man riding a horse was medium, and a man galloping a horse was fast. Today, any kind of horse is slow, let alone men walking. Planes are medium, rockets are fast. Tomorrow I'm sure it will all change again. The networking world has undergone the same kind of transformations. <=2400bps isn't slow, its pathetic. I'd put below T1 as slow, T1 -> ethernet as medium, and > ethernet (T3 and above) as fast at the minute. In another few years I'm sure this definition will be as outdated as yours. kre ps: I am typing this over what is definitely a "slow" link (28.8 compressed). The fact that I can't afford a medium or fast link doesn't mean that what I have is fast, or even medium. I can't afford a plane or rocket either (to own anyway - in both the net and transport cases I occasionally get to use someone else's, though I am still waiting for my rocket ride...) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 21 06:37:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12424; Wed, 21 Dec 94 06:37:40 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12418; Wed, 21 Dec 94 06:37:33 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA22642; Wed, 21 Dec 1994 06:31:58 -0800 From: bmanning@ISI.EDU Received: from venera.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA17754; Wed, 21 Dec 94 06:31:59 PST Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 21 Dec 1994 06:31:58 -0800 Posted-Date: Wed, 21 Dec 1994 06:31:49 -0800 (PST) Message-Id: <199412211431.AA02690@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 21 Dec 1994 06:31:49 -0800 Subject: Re: (IPng) Minimum link MTU of 1500 To: ipng@sunroof.Eng.Sun.COM Date: Wed, 21 Dec 1994 06:31:49 -0800 (PST) In-Reply-To: <3268.788014152@munnari.OZ.AU> from "Robert Elz" at Dec 21, 94 11:49:12 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM kre, you have to change w/ the times! fast is the 600Mbps lan at work, medium is the OC3c link and slow is 45Mbps. Anything less is ... "Historic" :) > The networking world has undergone the same kind of transformations. > <=2400bps isn't slow, its pathetic. I'd put below T1 as slow, > T1 -> ethernet as medium, and > ethernet (T3 and above) as fast > at the minute. In another few years I'm sure this definition will > be as outdated as yours. > > kre --bill Differently clued ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 21 07:20:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12441; Wed, 21 Dec 94 07:20:39 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12435; Wed, 21 Dec 94 07:20:32 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id HAA24771; Wed, 21 Dec 1994 07:14:57 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA23084; Wed, 21 Dec 94 07:14:58 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA03732; Wed, 21 Dec 94 07:13:21 -0800 Received: by xirtlu.zk3.dec.com; id AA26253; Wed, 21 Dec 1994 10:12:22 -0500 Message-Id: <9412211512.AA26253@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "19 Dec 94 18:27:40 +0100." <3574.bill.simpson@um.cc.umich.edu> Date: Wed, 21 Dec 94 10:12:16 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, I found your mail very convincing as a big computer vendor and wearing my "individual" hat as an IETF member I think your concerns need to be seriously addresses as I consider you in this area our expert since SIP (with one P). What do you think the MTU should be? Are there trade-offs we can make to satisfy all parties from the on-slaught of mail in your opinion? We need to heed Bill's message folks. The small business entrepreneur must have our support and technical thoughts so to speak. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 21 08:27:06 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12471; Wed, 21 Dec 94 08:27:06 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12465; Wed, 21 Dec 94 08:26:59 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id IAA29796; Wed, 21 Dec 1994 08:21:23 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA03666; Wed, 21 Dec 94 08:21:24 PST Received: by rodan.UU.NET id QQxvgj09955; Wed, 21 Dec 1994 11:21:21 -0500 Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 - get urself moderne... In-Reply-To: Your message of "Wed, 21 Dec 1994 23:49:12 +1100." <3268.788014152@munnari.OZ.AU> Date: Wed, 21 Dec 1994 11:21:21 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM KRE, I *strongly* believe that one of the reasons that IP won is because the demands it made on the underlying wires were pretty simple, and that IP is incredibly forgiving of even the grossest treatment. One problem that happens with Intra-link fragmentation is that we become much less tolerant of links with (relatively) high error rates. It's just like ATM losing a cell out of a packet and then the rest of the net works hard to deliver trash. Unless the intra-link fragmentation machinery does retransmissions we have the same problem. This can be a real problem for radio links which are running successfully now on pretty minimal hardware. Saying "you gotta dramatically change the deployed hardware" ain't gonna win fans for IPv6, if that's the case. Another real problem (politically, at least) is that the argument of "if you gotta do link-reliability protocols, why do you need such a heavyweight end-to-end protocol" will rise like the swapgas over northern New Jersey. We'll have to beat it down again, and it'll just be that much harder. So while I strongly believe in making link-access protocols do enough work to give IP what it really needs, what IPv6 is asking for is a LOT more than was needed with IPv4, and it is nowhere near trivial to accomodate these requests. They have very real costs, and I think they are being underestimated. Resident Crank and RF Emitter -Mike O'Dell ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 21 08:37:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12483; Wed, 21 Dec 94 08:37:23 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12477; Wed, 21 Dec 94 08:37:16 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id IAA00516; Wed, 21 Dec 1994 08:31:41 -0800 Received: from ftp.com (wd40.ftp.com) by Sun.COM (sun-barr.Sun.COM) id AA05957; Wed, 21 Dec 94 08:31:42 PST Received: from ftp.com by ftp.com ; Wed, 21 Dec 1994 11:31:41 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 21 Dec 1994 11:31:41 -0500 Received: from solensky.fenway.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA12095; Wed, 21 Dec 94 11:30:51 EST Date: Wed, 21 Dec 94 11:30:51 EST Message-Id: <9412211630.AA12095@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 From: solensky@ftp.com (Frank T Solensky) Repository: mailserv-D.ftp.com, [message accepted at Wed Dec 21 11:30:39 1994] Originating-Client: fenway.ftp.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > We need to heed Bill's message folks. The small business entrepreneur > must have our support and technical thoughts so to speak. I'll agree for different reasons -- the way I read Bill's message had to do more with interoperability: if we make Ether-like MTUs a hard and fast end-to-end requirement, then we wind up losing on the interoperability front. If it really is throughly and completly impossible for some media to come up with link-level fragmentation, are there any significant problems with the encapsulation scheme Bob suggested? -- Frank ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 21 09:12:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12495; Wed, 21 Dec 94 09:12:07 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12489; Wed, 21 Dec 94 09:12:00 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id JAA03504; Wed, 21 Dec 1994 09:06:24 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA11949; Wed, 21 Dec 94 09:06:26 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA13280; Wed, 21 Dec 94 09:03:42 -0800 Received: by xirtlu.zk3.dec.com; id AA00608; Wed, 21 Dec 1994 12:02:43 -0500 Message-Id: <9412211702.AA00608@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Minimum link MTU of 1500 - get urself moderne... In-Reply-To: Your message of "Wed, 21 Dec 94 11:21:21 EST." Date: Wed, 21 Dec 94 12:02:37 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >One problem that happens with Intra-link fragmentation is that we >become much less tolerant of links with (relatively) high error rates. >It's just like ATM losing a cell out of a packet and then the rest >of the net works hard to deliver trash. Unless the intra-link >fragmentation machinery does retransmissions we have the same problem. >This can be a real problem for radio links which are running successfully >now on pretty minimal hardware. Saying "you gotta dramatically change >the deployed hardware" ain't gonna win fans for IPv6, if that's the >case. This from Mike has to be part of our decision criteria. We need fans for IPv6 big time to make it worthwhile for customers to use it. I suggest this be a logic check in our engineering trade off decision in the Working Group. >They have very real costs, and I think they are being underestimated. Same as above comment. For those of you who were at the Amsterdam IPng BOF lead by Brian Carpenter I want to recant as best I can Vint Cerfs message to us. Do not build IPng without considering costs. I also would like to see consistency in our cost trade offs so far I think I see a pattern so this is positive. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 21 09:20:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12520; Wed, 21 Dec 94 09:20:18 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12514; Wed, 21 Dec 94 09:20:11 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id JAA04249; Wed, 21 Dec 1994 09:14:36 -0800 Received: from amdext.amd.com by Sun.COM (sun-barr.Sun.COM) id AA13343; Wed, 21 Dec 94 09:14:36 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA08665 (5.67a/IDA-1.5+AMD for ); Wed, 21 Dec 1994 09:14:35 -0800 Received: from brahms.amd.com by amdint.amd.com with SMTP id AA13304 (5.67a/IDA-1.5+AMD for ); Wed, 21 Dec 1994 09:14:34 -0800 Received: from angelo.amd.com by brahms.amd.com (4.1/AMDSN-1.18) id AA10495; Wed, 21 Dec 94 09:13:56 PST Received: by angelo.amd.com (4.1/AMDC-1.18) id AA00136; Wed, 21 Dec 94 09:14:32 PST From: David.Roberts@amd.com (Dave Roberts) Message-Id: <9412211714.AA00136@angelo.amd.com> Subject: Re: (IPng) Minimum link MTU of 1500 To: ipng@sunroof.Eng.Sun.COM Date: Wed, 21 Dec 1994 09:14:31 -0800 (PST) In-Reply-To: <9412152101.AA01379@snark.imsi.com> from "Perry E. Metzger" at Dec 15, 94 04:01:33 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The questioni then arose of how high to raise the minimum MTU; > ethernet was thought to possess the lowest packet size for a widely > deployed medium so 1500 bytes was chosen. I don't think anyone really > considered the 802.3 issue, though. Myself, I'd say cut the gordion > knot and lose the 8 bytes; you still get all of the same benefits by > specifying a minimum MTU of 1492 bytes. Sorry to bring up the past (I was out for a few days--did anybody ever tell you guys you're very prolific? :-) ). Anyway, I agree with Perry, above. I don't buy the, "We should only choose one Ethernet physical layer--either 802.3 of vanilla Ethernet," argument. IP isn't in the business of specifying which physical layer should be used. IP currently runs over both Ethernet and 802.3. Why make a further restriction? As Perry states above, the benefit is really just the increased MTU size, not the exact size specified. Ignoring the Appletalk issue, which I think has some merit, why not lose the 8 bytes and create as few problems as we can? Dave Roberts Advanced Micro Devices, Inc. I/O and Network Products Division david.roberts@amd.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 21 09:41:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12563; Wed, 21 Dec 94 09:41:22 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12557; Wed, 21 Dec 94 09:41:11 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id JAA06369; Wed, 21 Dec 1994 09:35:36 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA17316; Wed, 21 Dec 94 09:35:36 PST Received: from relay.imsi.com by wintermute.imsi.com id MAA12904 for ; Wed, 21 Dec 1994 12:35:34 -0500 Received: from webster.imsi.com by relay.imsi.com id MAA26907 for ; Wed, 21 Dec 1994 12:35:33 -0500 Received: from snark.imsi.com by webster.imsi.com (4.1/SMI-4.1) id AA10220; Wed, 21 Dec 94 12:35:28 EST Date: Wed, 21 Dec 94 12:35:28 EST From: perry@imsi.com (Perry E. Metzger) Message-Id: <9412211735.AA10220@webster.imsi.com> Received: by snark.imsi.com (4.1/SMI-4.1) id AA12144; Wed, 21 Dec 94 12:35:28 EST To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) minimum MTU X-Reposting-Policy: redistribute only with permission Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Back in the mists of time, IPv4 was defined. It had a built-in fragmentation facility. However, its designers, in their wisdom, decided that there should be a minimum MTU specified, which was 576 octets. This MTU was specified, not because it was the lowest common denominator (and indeed there are a LOT of "popular" "international standard" networks that have smaller MTUs), but because it was the lowest important MTU on the internet at that time. Today, we are defining a new networking protocol. We have a similar decision to make -- what should the MTU be? 576 was a good idea in its time, but it was picked to accommodate a packet-switched network that doesn't even exist any more. The time has come to pick a new MTU. Now there is only one popular LAN that has an MTU below 1500 (well, 1496) bytes, specifically Localtalk. Lots of people thought it would be a good idea to jack the MTU up to the lowest "important" MTU on our network, specifically Ethernet's. As has been noted by people doing real statistical analysis, a miniscule fraction of the links on our existing network have smaller than a 1500 byte MTU. As has been noted, serial links using PPP already have a way to deal with link fragmentation if they want to, and in any case can handle a 1500 byte MTU. As has been noted, the only real impact of this decision is going to be to force a single networking technology of dimming popularity, Localtalk, to use link-level fragmentation. All the other effects should be strongly beneficial. Remember, if we leave the MTU at 576 we are accommodating a network that NO LONGER EXISTS -- even Localtalk has a slightly larger MTU. However, it seems that so many people oppose this increase in MTU on the basis that we aren't accommodating the lowest common denominator that we should really move to the truly lowest common denominator. I'll point out that many popular protocols with X and digits in their names take only 128 octets. Perhaps we should have moved the MTU down to 128. Existing transport of IPv4 over this network is forced to use link level fragmentation, which is discriminatory against international standards organizations. Indeed, perhaps even this isn't enough. I propose that we change our MTU down to 40 bytes or so to permit us to transfer ATM packets down the line without having to fragment them. After all, the arguments being made thus far all seem to be that we should go for lowest common denominator rather than lowest rational and meaningful value, so I say lets go whole hog. Or perhaps we can back away and conduct this discussion with the assumption that, as with the 576 byte MTU, we are going to have to accept the fact that some links will need link-level fragmentation, and pick a number that is good from a real-world perspective, not good on the basis that it will help us return to a mythical day in which we didn't have to deal with link-layer fragmentation on any medium. I think that forcing a *single* vendor to go for link level fragmentation in exchange for a near 300% increase in the MTU is a good trade. Does anyone here OTHER than a Localtalk partisan have a good reason for blocking this change? I will point out that even if we decided that Apple was too incompetent to write a link-level fragmentation system for Localtalk and that we had to accommodate them, I will point out that we can at the very least move the MTU up to the Localtalk MTU instead of leaving it at the current arbitrary magic number. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 21 11:09:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12629; Wed, 21 Dec 94 11:09:14 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12623; Wed, 21 Dec 94 11:09:06 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA16725; Wed, 21 Dec 1994 11:03:32 -0800 Received: from netcom5.netcom.com by Sun.COM (sun-barr.Sun.COM) id AA03698; Wed, 21 Dec 94 11:03:30 PST Received: by netcom5.netcom.com (8.6.9/Netcom) id LAA03631; Wed, 21 Dec 1994 11:03:26 -0800 Date: Wed, 21 Dec 1994 11:03:26 -0800 From: kck@netcom.com (Richard Fox) Message-Id: <199412211903.LAA03631@netcom5.netcom.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >............................................................why not >lose the 8 bytes and create as few problems as we can? > >Dave Roberts Then we might consider making the MTU some how based on a standard page boundary. Since page boundarys are normalyy 1K, 4K, 8K we may want to key off 1K. Even with this decision it would seem there are winners and there are losers. -rich ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 21 11:59:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12642; Wed, 21 Dec 94 11:59:13 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12636; Wed, 21 Dec 94 11:59:05 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA22526; Wed, 21 Dec 1994 11:53:31 -0800 Received: from amdext.amd.com by Sun.COM (sun-barr.Sun.COM) id AA13370; Wed, 21 Dec 94 11:53:31 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA24058 (5.67a/IDA-1.5+AMD for ); Wed, 21 Dec 1994 11:53:26 -0800 Received: from brahms.amd.com by amdint.amd.com with SMTP id AA28929 (5.67a/IDA-1.5+AMD for ); Wed, 21 Dec 1994 11:53:25 -0800 Received: from angelo.amd.com by brahms.amd.com (4.1/AMDSN-1.18) id AA22200; Wed, 21 Dec 94 11:52:47 PST Received: by angelo.amd.com (4.1/AMDC-1.18) id AA09167; Wed, 21 Dec 94 11:53:23 PST From: David.Roberts@amd.com (Dave Roberts) Message-Id: <9412211953.AA09167@angelo.amd.com> Subject: Re: (IPng) Minimum link MTU of 1500 To: ipng@sunroof.Eng.Sun.COM Date: Wed, 21 Dec 1994 11:53:23 -0800 (PST) In-Reply-To: <199412211903.LAA03631@netcom5.netcom.com> from "Richard Fox" at Dec 21, 94 11:03:26 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >............................................................why not > >lose the 8 bytes and create as few problems as we can? > > > >Dave Roberts > > Then we might consider making the MTU some how based on a standard > page boundary. Since page boundarys are normalyy 1K, 4K, 8K we may > want to key off 1K. Even with this decision it would seem there are > winners and there are losers. > > -rich I don't think you want to key off a 1K page size or anything. Applications and implementations might do that anyway, and it makes no sense to try to encourage this for no real reason. *All I was reacting to was the difference between 1500 and 1492, 1500 eliminating 802.3 encapsulation, for no real gain in the things that a larger MTU seeks.* Now people concerned with Appletalk encapsulation argue that even 1492 is too big, and I think they might even have a point. Again, anything we choose that is different than 576 will cause somebody, somewhere, a problem. The question is, how many people will be effected and do we care? We care if those people are large enough to slow or stop adoption of IPv6 because of the issues they face. Although I agree with Perry on the 1500-vs-1492 issue, I don't agree that Appletalk will die a violent death in 2 years and be utterly replaced. Networks have a habit of hanging around for a long time because upgrading one node has the horrible side effect of forcing the upgrade of all the nodes. So, to summarize my opinion. I don't have an opinion about the 600-byte Appletalk requirements vs ~1500 byte sizes. If we choose something like ~1500, however, I'd argue for 1492 rather than a hard 1500. It just seems foolish to remove functionality that currently exists (802.3 encapsulation) for 8 bytes. People may argue, rightfully, that the functionality is currently optional and that most people don't use it, but I'd like to spend more time understanding what we're gaining with the extra 8 bytes before we throw away the functionality. Dave Roberts Advanced Micro Devices, Inc. I/O and Network Products Division david.roberts@amd.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 21 12:18:06 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12655; Wed, 21 Dec 94 12:18:06 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12649; Wed, 21 Dec 94 12:17:54 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id MAA24836; Wed, 21 Dec 1994 12:12:19 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA16946; Wed, 21 Dec 94 12:12:20 PST Received: from relay.imsi.com by wintermute.imsi.com id PAA13953 for ; Wed, 21 Dec 1994 15:12:13 -0500 Received: from snark.imsi.com by relay.imsi.com id PAA28864 for ; Wed, 21 Dec 1994 15:12:12 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA12522; Wed, 21 Dec 94 15:12:12 EST Message-Id: <9412212012.AA12522@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Wed, 21 Dec 1994 11:53:23 PST." <9412211953.AA09167@angelo.amd.com> X-Reposting-Policy: redistribute only with permission Date: Wed, 21 Dec 1994 15:12:11 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dave Roberts says: > Although I agree with Perry on the 1500-vs-1492 issue, I don't agree > that Appletalk will die a violent death in 2 years and be utterly > replaced. Networks have a habit of hanging around for a long time > because upgrading one node has the horrible side effect of forcing the > upgrade of all the nodes. No one has proposed "breaking" Localtalk. It has merely been noted that forcing link level fragmentation on one (count them, one) low speed LAN is not a horrible thing. Localtalk networks could still have IPv6 implementations, they would just need link level fragmentation. IP implementations for Localtalk already have fragmentation, its just not link level right now. The point that Localtalk is hardly on the leading edge of its life cycle is only to note that optimizing for Localtalk at the expense of all that comes in the future isn't a good idea; it is not to say that this move will make IPv6 for Localtalk unimplementable. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 21 12:45:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12748; Wed, 21 Dec 94 12:45:21 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12742; Wed, 21 Dec 94 12:45:13 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id MAA27492; Wed, 21 Dec 1994 12:39:38 -0800 Received: from alink-gw.apple.com by Sun.COM (sun-barr.Sun.COM) id AA21938; Wed, 21 Dec 94 12:39:31 PST Received: from federal-excess.apple.com by alink-gw.apple.com with SMTP (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA15918; Wed, 21 Dec 94 12:39:28 -0800 for ipng@sunroof.eng.sun.com Received: from lilith.lansys.apple.com by federal-excess.apple.com (5.0/1-Nov-1994-eef) id AA26848; Wed, 21 Dec 1994 12:38:12 +0800 for ipng@sunroof.eng.sun.com Received: (justin@localhost) by lilith.lansys.apple.com (8.6.9/A/UX 3.1) id MAA09231; Wed, 21 Dec 1994 12:39:49 -0800 Date: Wed, 21 Dec 1994 12:39:49 -0800 From: "Justin C. Walker" Message-Id: <199412212039.MAA09231@lilith.lansys.apple.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Perry E. Metzger"'s message of Wed, 21 Dec 1994 15:12:11 -0500 <9412212012.AA12522@snark.imsi.com> Subject: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry sez: >> No one has proposed "breaking" Localtalk. It has merely been noted >> that forcing link level fragmentation on one (count them, one) low >> speed LAN is not a horrible thing. Localtalk networks could still have >> IPv6 implementations, they would just need link level >> fragmentation. IP implementations for Localtalk already have >> fragmentation, its just not link level right now. Lest we lose sight of the real issue, LocalTalk itself is not it. AppleTalk is currently widely deployed, with LocalTalk being one (and for some, and important one) of its media. The spec for DDP (the "network layer" for AppleTalk) sez that a datagram can carry a max payload of 586 bytes. Therefore, we're talking about a lot more than reving a datalink driver for one medium. Because there's a booming business in carrying IP over AppleTalk (e.g., for those guys with MacTCP on their powerbooks), there's a real need to make sure that there's a good answer to the question of how to carry IPv6 over AppleTalk. Regards, Justin Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | They sentenced me to 20 years Apple Business Systems | of boredom Apple Computer, Inc. | For trying to change the system 10500 North De Anza Blvd | from within Cupertino, CA 95014 | LC *---------------------------------------*------------------------------------* ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 21 13:28:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12772; Wed, 21 Dec 94 13:28:41 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12766; Wed, 21 Dec 94 13:28:34 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id NAA01220; Wed, 21 Dec 1994 13:22:59 -0800 Received: from amdext.amd.com by Sun.COM (sun-barr.Sun.COM) id AA28758; Wed, 21 Dec 94 13:22:30 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA02868 (5.67a/IDA-1.5+AMD for ); Wed, 21 Dec 1994 13:22:29 -0800 Received: from brahms.amd.com by amdint.amd.com with SMTP id AA08507 (5.67a/IDA-1.5+AMD for ); Wed, 21 Dec 1994 13:22:28 -0800 Received: from angelo.amd.com by brahms.amd.com (4.1/AMDSN-1.18) id AA27569; Wed, 21 Dec 94 13:21:49 PST Received: by angelo.amd.com (4.1/AMDC-1.18) id AA12692; Wed, 21 Dec 94 13:22:25 PST From: David.Roberts@amd.com (Dave Roberts) Message-Id: <9412212122.AA12692@angelo.amd.com> Subject: Re: (IPng) Minimum link MTU of 1500 To: ipng@sunroof.Eng.Sun.COM Date: Wed, 21 Dec 1994 13:22:25 -0800 (PST) In-Reply-To: <9412212012.AA12522@snark.imsi.com> from "Perry E. Metzger" at Dec 21, 94 03:12:11 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > No one has proposed "breaking" Localtalk. It has merely been noted > that forcing link level fragmentation on one (count them, one) low > speed LAN is not a horrible thing. Localtalk networks could still have > IPv6 implementations, they would just need link level > fragmentation. IP implementations for Localtalk already have > fragmentation, its just not link level right now. > > The point that Localtalk is hardly on the leading edge of its life > cycle is only to note that optimizing for Localtalk at the expense of > all that comes in the future isn't a good idea; it is not to say that > this move will make IPv6 for Localtalk unimplementable. Agreed on all points. It's just a matter of how many people you want to force to do extra work and whether that contingent is significant enough to slow or halt IPv6 adoption if they are not satisfied with the word you would require. Be careful what you respond to that with because, as I said of network upgrades in general, when you upgrade one node, you tend to have to upgrade them all. That means that an organization with an otherwise sizeable percentage of nodes that could easily run IPv6 might be stymied because of a lack of support for a non-zero Macintosh contingent. My sense of Macintosh demographics is not such that I can tell you what percentage are using Localtalk or IP-over-Appletalk and thus quantify whether this contingent "matters" as far a adoption goes. Note that although organizations *could* try to isolate those nodes and try to upgrade portions of the org using the IPv4-IPv6 transition mechansims, I doubt this will be popular. The transition mechansims seem more aimed at allowing individual organizations to upgrade all of themselves without having to wait for all other organizations to upgrade at once. In other words, the transition mechansims seem to be aimed mostly at the boundaries of organizations. Anyway, I agree that it can be done, but I'm being a little more cautious about foisting additional work on people who we'd like to count among our supporters. Dave Roberts Advanced Micro Devices, Inc. I/O and Network Products Division david.roberts@amd.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 21 15:36:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12898; Wed, 21 Dec 94 15:36:52 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12892; Wed, 21 Dec 94 15:36:45 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id PAA14811; Wed, 21 Dec 1994 15:31:08 -0800 Received: from nic.ott.hookup.net by Sun.COM (sun-barr.Sun.COM) id AA19536; Wed, 21 Dec 94 15:29:29 PST Received: from [165.154.16.159] (kgk.ott.hookup.net [165.154.16.159]) by nic.ott.hookup.net (8.6.9/1.73) with SMTP id SAA13065; Wed, 21 Dec 1994 18:29:14 -0500 Message-Id: <199412212329.SAA13065@nic.ott.hookup.net> X-Sender: kgk@nic.ott.hookup.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Dec 1994 18:30:02 -0500 To: ipng@sunroof.Eng.Sun.COM From: kgk@hookup.net (Keith G Knightson) Subject: Re: (IPng) minimum MTU Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 12:35 PM 12/21/94 -0500, Perry E. Metzger wrote: >However, it seems that so many people oppose this increase in MTU on >the basis that we aren't accommodating the lowest common denominator >that we should really move to the truly lowest common denominator. >I'll point out that many popular protocols with X and digits in their >names take only 128 octets. Perhaps we should have moved the MTU down >to 128. Existing transport of IPv4 over this network is forced to use >link level fragmentation, which is discriminatory against >international standards organizations. > Since X.25 already has a fragmentation mechanism in its packet layer. Multiple packets using an M-bit sequence ( M=not last....M=last) should be used to convey an MTU greater than 128 octets. To use a data link protocol with fragmentation over the packet protocol which already has fragmentation AND which is itself already running over a data link protocol (LAPB) would be extremely stupid. Keith ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 21 16:16:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12926; Wed, 21 Dec 94 16:16:53 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12920; Wed, 21 Dec 94 16:16:45 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id QAA19179; Wed, 21 Dec 1994 16:11:09 -0800 Received: from ftp.com (wd40.ftp.com) by Sun.COM (sun-barr.Sun.COM) id AA25798; Wed, 21 Dec 94 16:11:10 PST Received: from ftp.com by ftp.com ; Wed, 21 Dec 1994 19:11:09 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 21 Dec 1994 19:11:09 -0500 Received: from solensky.fenway.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA19394; Wed, 21 Dec 94 19:10:20 EST Date: Wed, 21 Dec 94 19:10:20 EST Message-Id: <9412220010.AA19394@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 From: solensky@ftp.com (Frank T Solensky) Repository: mailserv-D.ftp.com, [message accepted at Wed Dec 21 19:10:07 1994] Originating-Client: fenway.ftp.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Well, it's late; whaddaheck, here's an admittedly half-baked thought: There seems to be an underlying assumption in this discussion that the default packet size and the MTU have to be the same value. What problems might occur if that isn't the case -- that is, one starts off with a default that is larger then the minimum MTU? The scenerio that immediately comes to mind is that a packet reaches a router that would forward the packet into a small-MTU media. Since the packet now exceeds the MTU of that link, an ICMP 'too big' message is generated and sent back the source node. The source node receives the ICMP message that includes most (but not all) of the packet that generated the error and utilize an MTU discovery sort of algorithm to trim down the default MTU for that socket. The IPv6 layer might also be allowed to take the ICMPv6 header off that frame and send back, say, half of the original frame back to the destination. I'm assuming that media with small MTU values are also going to be relatively slow, therefore the delay this introduces isn't going to be unacceptable for that link. Also: ATM provides something along the lines of link-level fragmentation in the convergence sublayer rather than its 53-byte cell length being a classic MTU and thus wouldn't be impacted by this approach. Totally brain dead? -- Frank ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 21 20:34:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13516; Wed, 21 Dec 94 20:34:35 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13510; Wed, 21 Dec 94 20:34:27 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id UAA11559; Wed, 21 Dec 1994 20:28:51 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA22271; Wed, 21 Dec 94 20:28:47 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21497; Thu, 22 Dec 1994 15:23:17 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) minimum MTU In-Reply-To: Your message of "Wed, 21 Dec 1994 12:35:28 EST." <9412211735.AA10220@webster.imsi.com> Date: Thu, 22 Dec 1994 15:23:10 +1100 Message-Id: <3498.788070190@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Wed, 21 Dec 94 12:35:28 EST From: perry@imsi.com (Perry E. Metzger) Message-ID: <9412211735.AA10220@webster.imsi.com> Back in the mists of time, IPv4 was defined. It had a built-in fragmentation facility. However, its designers, in their wisdom, decided that there should be a minimum MTU specified, which was 576 octets Perry, this seems to be a widely held view, but it is simply wrong. The minimum MTU in IPv4 is 68 octets. MTUs are rarely seen that low, but have been. On the other hand, a lot of slow serial interfaces are configured with an MTU of 296. The 576 number is the minimum reassembly size - that is, it indicates how large a datagram all implementations must be able to receive (possibly in fragments) and process. The minimum resassembly size for IPv6 has already, and I believe with no controversy at all, been increased to 1500. All IPv6 implementations will be required to be able to receive and process datagrams up to at least 1500 bytes. The question is by how much should the 68 be increased, if at all. I believe that the theoretical minimum for this value for IPv6 is actually 56 (40 bytes IPv6 header, 8 bytes frag header, and at least some other data, minimum would be 8 bytes). I don't see any rational way to guarantee that the transport header will fit in the first fragment with IPv6, so that can be ignored. The initial proposal was to increase it to 576 or 586, which would more or less keep the status quo... That is, applications would be able to send datagrams that large without thinking, which is what they do now. With IPv4 they may be relying on fragmentation/reassembly to get the data through with a datagram that size, but they can expect (assuming no dropped packets, etc) that the whole thing will be received. Since IPv6 does no automatic fragmentation, raising the minimum MTU to this level is required for that to continue to work. If an application desires to send a datagram larger than the minimum guaranteed MTU then it must either fragment the datagram to that (MTU) size, and send fragments, or it must be prepared to receive ICMP "too big" responses, associate them with the datagram that caused the response, and then fragment and resend, and possibly repeat that if the path passes through links of gradually decreasing MTU. Its the burden of that on applications like the DNS, where a server tends to send large numbers of responses, and immediately want to forget them, that gives cause to the desire to raise the minimum MTU to the largest reasonable value. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 21 21:10:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13528; Wed, 21 Dec 94 21:10:27 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13522; Wed, 21 Dec 94 21:10:20 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id VAA12945; Wed, 21 Dec 1994 21:04:44 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA24380; Wed, 21 Dec 94 21:04:39 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA08171; Wed, 21 Dec 94 21:02:49 -0800 Received: by xirtlu.zk3.dec.com; id AA20011; Thu, 22 Dec 1994 00:01:49 -0500 Message-Id: <9412220501.AA20011@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) minimum MTU In-Reply-To: Your message of "Thu, 22 Dec 94 15:23:10 +1100." <3498.788070190@munnari.OZ.AU> Date: Thu, 22 Dec 94 00:01:43 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Kre, Well put and thank you. It seems to me that we must go from 68 at least to 576 for sure. Do we take it higher is the question. I don't recall consensus anywhere on 1500 octet reassembly though? Not that I disagree, but when and where did this get agreed to by the working group? I was not at all moments of every meeting. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 22 00:04:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13572; Thu, 22 Dec 94 00:04:31 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13566; Thu, 22 Dec 94 00:04:24 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id XAA18270; Wed, 21 Dec 1994 23:58:47 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA04924; Wed, 21 Dec 94 23:58:41 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29322; Thu, 22 Dec 1994 18:58:33 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) minimum MTU In-Reply-To: Your message of "Thu, 22 Dec 1994 00:01:43 CDT." <9412220501.AA20011@xirtlu.zk3.dec.com> Date: Thu, 22 Dec 1994 18:58:30 +1100 Message-Id: <3557.788083110@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Thu, 22 Dec 94 00:01:43 -0500 From: bound@zk3.dec.com Message-ID: <9412220501.AA20011@xirtlu.zk3.dec.com> I don't recall consensus anywhere on 1500 octet reassembly though? Not that I disagree, but when and where did this get agreed to by the working group? You'd do better to ask SteveD. As I recall it was about 20 seconds of hand waving, followed by 5 seconds of silence in the "any objections" period. It was probably in Toronto. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 22 04:29:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13670; Thu, 22 Dec 94 04:29:29 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13664; Thu, 22 Dec 94 04:29:16 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id EAA28955; Thu, 22 Dec 1994 04:23:41 -0800 From: smb@research.att.com Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AA28228; Thu, 22 Dec 94 04:23:41 PST Message-Id: <9412221223.AA28228@Sun.COM> Received: by gryphon; Thu Dec 22 07:19:42 EST 1994 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) minimum MTU Date: Thu, 22 Dec 94 07:19:41 EST Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Thu, 22 Dec 94 00:01:43 -0500 From: bound@zk3.dec.com Message-ID: <9412220501.AA20011@xirtlu.zk3.dec.com> I don't recall consensus anywhere on 1500 octet reassembly though? Not that I disagree, but when and where did this get agreed to by the working group? You'd do better to ask SteveD. As I recall it was about 20 seconds of hand waving, followed by 5 seconds of silence in the "any objections" period. It was probably in Toronto. But this is almost begging the real question. The real issue is larger DNS packets -- the DNS is the application that (a) really needs to use larger packets than it does today, notably if authentication and/or key distribution is to be added, and (b) is ill-suited to path MTU discovery. The choices seem to be: a) increase the minimum fragment size b) swallow hard and don't enhance the DNS c) add some sort of ``forward path MTU'' to IPv6, so that DNS queries can contain enough information that the receiver knows whether or not to tack on a fragmentation header. d) always use a fragmentation header for IPv6 DNS. I could add (e) don't add security stuff to the DNS, but I reject that; any replacement key distribution mechanism will be almost identical to the DNS operationally, so we'd have another identical learning and implementation curve to climb. --Steve Bellovin ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 22 05:39:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13700; Thu, 22 Dec 94 05:39:24 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13694; Thu, 22 Dec 94 05:39:17 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id FAA00854; Thu, 22 Dec 1994 05:33:42 -0800 From: yakov@watson.ibm.com Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA03027; Thu, 22 Dec 94 05:33:42 PST Message-Id: <9412221333.AA03027@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6519; Thu, 22 Dec 94 08:33:37 EST Date: Thu, 22 Dec 94 08:32:39 EST To: ipng@sunroof.Eng.Sun.COM, smb@research.att.com Subject: (IPng) minimum MTU Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Thu, 22 Dec 94 07:19:41 EST Steve, >c) add some sort of ``forward path MTU'' to IPv6, so that DNS queries >can contain enough information that the receiver knows whether or not >to tack on a fragmentation header. That wouldn't work in presence of asymmetric routes. Yakov Rekhter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 22 06:44:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13726; Thu, 22 Dec 94 06:44:36 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13720; Thu, 22 Dec 94 06:44:24 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA03004; Thu, 22 Dec 1994 06:38:49 -0800 Received: from nero.dcrc.com ([131.226.3.20]) by Sun.COM (sun-barr.Sun.COM) id AA09468; Thu, 22 Dec 94 06:38:46 PST Received: by nero.dcrc.com (4.1/1.34) id AA22979; Thu, 22 Dec 94 09:38:32 EST Date: Thu, 22 Dec 94 09:38:32 EST From: mad@nero.dcrc.com (Mike Davis) Message-Id: <9412221438.AA22979@nero.dcrc.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9412220501.AA20011@xirtlu.zk3.dec.com> (bound@zk3.dec.com) Subject: Re: (IPng) minimum MTU Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, I don't recall consensus anywhere on 1500 octet reassembly though? Not that I disagree, but when and where did this get agreed to by the working group? I was not at all moments of every meeting. My recollection is that we "recommended" it at the October implementor's meeting, then we sort of let it stand at the first session of the San Jose WG meeting. /jim -mad - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + Mike Davis + Do not use the return address + + Penril Datability Networks + Use mike@dss.com + + 190 North Main Street +- -- -- -- -- -- -- -- -- -- -- -+ + Natick, MA 01760 + assume the smiley + - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 22 08:51:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13799; Thu, 22 Dec 94 08:51:26 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13793; Thu, 22 Dec 94 08:51:19 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id IAA10930; Thu, 22 Dec 1994 08:45:42 -0800 Received: from nic.ott.hookup.net by Sun.COM (sun-barr.Sun.COM) id AA27250; Thu, 22 Dec 94 08:45:34 PST Received: from [165.154.16.159] (kgk.ott.hookup.net [165.154.16.159]) by nic.ott.hookup.net (8.6.9/1.73) with SMTP id LAA09396; Thu, 22 Dec 1994 11:45:25 -0500 Message-Id: <199412221645.LAA09396@nic.ott.hookup.net> X-Sender: kgk@nic.ott.hookup.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Dec 1994 11:46:12 -0500 To: ipng@sunroof.Eng.Sun.COM From: kgk@hookup.net (Keith G Knightson) Subject: (IPng) MTU size issues Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Surely IPNG should be as accommodating as possible - the universal highway of the present and future, no impediments to connection and all that. I don't think the installed base of Local Talk, or any underlying transport with a smaller MTU size should be penalized with the introduction of IPNG. [ATM is definitely a different case since it was expressly designed to have adaption layers and should not be muddled up in the same argument.] Academic arguments about efficiencies are one thing, but serving the installed base, with (heaven forbid) "users" who just want things to work without constant churn and perturbation is another. Most real users (and don't ask me for names and numbers) don't want revamp their systems at the drop of an intellectual hat. If, in some cases it serves the users interest to have a smaller size then why not? Presumably it would only actually occur when absolutely necessary. Why not say that the preferred size or default size is 1500 and must by used the transmitting end user wherever possible? I am not proposing reassembly at intermediate points, which by the way, seems to be the (dangerous?) reassembly implication of the other suggested solutions which treat the "delinquent" link separately, given that some links would support 1500 and others would not). Finally, If IPNG replaces IPv4, why it is it being suggested that under some circumstances, or indeed under any circumstances, that IPNG will actually require IPv4 in order to be able to operate correctly? There (at least) two problems with this, apart from the logic and optics. One - IP4 will take longer to go away. Two - new (I mean addtional through growth rather than newly designed/developed) systems may require it and may find no new IPv4 address space available. If it is considered that IPv4 will never go away anyway so it might as well be used, why should it be considered that Local Talk should go away? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 22 10:41:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13913; Thu, 22 Dec 94 10:41:51 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13907; Thu, 22 Dec 94 10:41:38 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id KAA21680; Thu, 22 Dec 1994 10:36:02 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA17168; Thu, 22 Dec 94 10:36:02 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14581(7)>; Thu, 22 Dec 1994 10:35:06 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12172>; Thu, 22 Dec 1994 10:34:52 -0800 To: kgk@hookup.net (Keith G Knightson) Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) MTU size issues In-Reply-To: kgk's message of Thu, 22 Dec 94 08:46:12 -0800. <199412221645.LAA09396@nic.ott.hookup.net> Date: Thu, 22 Dec 1994 10:34:50 PST From: Steve Deering Message-Id: <94Dec22.103452pst.12172@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Keith, > Surely IPNG should be as accommodating as possible - the universal highway > of the present and future, no impediments to connection and all that. Yes, IPv6 shares IPv4's goal of being able to run over "anything". Nothing that has been proposed is counter to that goal. IPv6 will run over Appletalk and over slow point-to-point links and even over ATM. We are are not debating whether or not to support those kinds of links, but rather how best to do it. > I don't think the installed base of Local Talk, or any underlying transport > with a smaller MTU size should be penalized with the introduction of IPNG. It is not at all clear to me that adding a shim layer between IPv6 and small-MTU link layers to provide intra-link fragmentation and reassembly is "penalizing" those layers. In fact, it makes more efficient use of the bandwidth of those links (*assuming low packet loss*) than does IP-layer or transport-layer fragmentation, since each fragment does not have to incur the significant overhead of IP-layer or IP+transport layer headers. > [ATM is definitely a different case since it was expressly designed to have > adaption layers and should not be muddled up in the same argument.] I disagree. ATM is simply an extreme case of precisely the issues under discussion. > Academic arguments about efficiencies are one thing, but serving the > installed base, with (heaven forbid) "users" who just want things to work > without constant churn and perturbation is another. Most real users (and > don't ask me for names and numbers) don't want revamp their systems at the > drop of an intellectual hat. It wouldn't hurt you to use a little more intellectual honesty in your arguments. No one is proposing anything that would result in "constant churn and perturbation" for users. To run IPv6 on a machine, a user will, necessarily, have to install an IPv6 stack on that machine. That stack will either include an intra-link fragmentation module for the specific link(s) attached to that machine or it will not, depending on what the IETF decides is the standard for encapsulating IPv6 on those specific link(s). End of story. > If, in some cases it serves the users interest to have a smaller size then > why not? Because it would harm the interests of other users. > I am not proposing reassembly at intermediate points, which by the way, > seems to be the (dangerous?) reassembly implication of the other suggested > solutions which treat the "delinquent" link separately, given that some > links would support 1500 and others would not). Please explain which dangers you are concerned about, arising from intra- link fragmentation and reassembly. And please resist the urge to use such loaded language -- the fact that a link or subnetwork technology imposes a small maximum packet size does not make it "delinquent". > Finally, If IPNG replaces IPv4, why it is it being suggested that under > some circumstances, or indeed under any circumstances, that IPNG will > actually require IPv4 in order to be able to operate correctly? There (at > least) two problems with this, apart from the logic and optics. One - IP4 > will take longer to go away. Two - new (I mean addtional through growth > rather than newly designed/developed) systems may require it and may find > no new IPv4 address space available. The suggestion was just that -- a suggestion. Since IPv4 implementations already exist over the media under discussion, IPv4 *could* be used as the shim layer to fragment and reassemble IPv6 packets over those media. This would be a degenerate, *local* use of IPv4, having *nothing at all* to do with the continued existence of an IPv4 Internet or with the availability of IPv4 address space (being a local use of IPv4, it need not employ globally-unique IPv4 addresses). Nonetheless, I think using IPv4 for that purpose is overkill, and in my next message I will suggest a simpler link-specific fragmentation protocol with a one- or two-byte header, rather than IPv4's 20 bytes. > If it is considered that IPv4 will never go away anyway so it might as well > be used, why should it be considered that Local Talk should go away? NOBODY (except maybe Perry) CONSIDERS THAT LOCALTALK SHOULD GO AWAY, OR REQUIRES THAT LOCALTALK GO AWAY FOR IPv6'S SAKE. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 22 11:20:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13929; Thu, 22 Dec 94 11:20:35 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13923; Thu, 22 Dec 94 11:20:16 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA00448; Thu, 22 Dec 1994 11:14:40 -0800 Received: from amdext.amd.com by Sun.COM (sun-barr.Sun.COM) id AA24568; Thu, 22 Dec 94 11:14:39 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA29865 (5.67a/IDA-1.5+AMD for ); Thu, 22 Dec 1994 11:14:33 -0800 Received: from brahms.amd.com by amdint.amd.com with SMTP id AA29031 (5.67a/IDA-1.5+AMD for ); Thu, 22 Dec 1994 11:14:32 -0800 Received: from angelo.amd.com by brahms.amd.com (4.1/AMDSN-1.18) id AB11741; Thu, 22 Dec 94 11:13:51 PST Received: by angelo.amd.com (4.1/AMDC-1.18) id AA22431; Thu, 22 Dec 94 11:14:30 PST From: David.Roberts@amd.com (Dave Roberts) Message-Id: <9412221914.AA22431@angelo.amd.com> Subject: Re: (IPng) MTU size issues To: ipng@sunroof.Eng.Sun.COM Date: Thu, 22 Dec 1994 11:14:30 -0800 (PST) In-Reply-To: <94Dec22.103452pst.12172@skylark.parc.xerox.com> from "Steve Deering" at Dec 22, 94 10:34:50 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, > > I don't think the installed base of Local Talk, or any underlying transport > > with a smaller MTU size should be penalized with the introduction of IPNG. > > It is not at all clear to me that adding a shim layer between IPv6 and > small-MTU link layers to provide intra-link fragmentation and reassembly > is "penalizing" those layers. In fact, it makes more efficient use of > the bandwidth of those links (*assuming low packet loss*) than does IP-layer > or transport-layer fragmentation, since each fragment does not have to > incur the significant overhead of IP-layer or IP+transport layer headers. It only penalizes users if someone doesn't specify the exact method of doing the fragmentation and reassembly. If suppliers are left to spec this themselves, then it could become a problem for users and this would be punative. > > [ATM is definitely a different case since it was expressly designed to have > > adaption layers and should not be muddled up in the same argument.] > > I disagree. ATM is simply an extreme case of precisely the issues under > discussion. Yes. The reason this is not an issue for ATM is that with ATM's small cell size, they have to do the segmentation and reassembly for just about every "normal" protocol (basically anything accept "raw" ATM) and so it's "built-in" and interoperable. > It wouldn't hurt you to use a little more intellectual honesty in your > arguments. No one is proposing anything that would result in "constant > churn and perturbation" for users. To run IPv6 on a machine, a user will, > necessarily, have to install an IPv6 stack on that machine. That stack will > either include an intra-link fragmentation module for the specific link(s) > attached to that machine or it will not, depending on what the IETF decides > is the standard for encapsulating IPv6 on those specific link(s). End of > story. Right. The question is, how many of those documents do we want to write and how long will they take to standardize? > Please explain which dangers you are concerned about, arising from intra- > link fragmentation and reassembly. And please resist the urge to use > such loaded language -- the fact that a link or subnetwork technology > imposes a small maximum packet size does not make it "delinquent". Correct. I'd note that 802.11 (wireless LAN) includes a fragmentation function because of the widely vary frame sizes that can be used on different physical layers (e.g., frequency hopping spread spectrum in the 2.4 GHz band vs. IR). 802.11 accepts a 2K+change frames at the top of the MAC but can use fragments as small as 256 bytes on "wire". > Nonetheless, I think using IPv4 for that purpose is overkill, and in my > next message I will suggest a simpler link-specific fragmentation protocol > with a one- or two-byte header, rather than IPv4's 20 bytes. Great! The important thing is that we (or at least somebody) specify this such that it doesn't become an interoperability nightmare. It would also be nice if such a protocol were universal to a variety of data links, thus allowing IPng to say, "This is how you do intralink fragmentation for IPv6 when the data link doesn't support a 1500-byte MTU," and perhaps even protocols (I suggested at 802.11 that such a protocol would be beneficial to the industry to deal with the general issue of, "This datalink frame size and this protocol's MTU are incompatible."). Dave Roberts Advanced Micro Devices, Inc. I/O and Network Products Division david.roberts@amd.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 22 13:07:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14038; Thu, 22 Dec 94 13:07:53 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14032; Thu, 22 Dec 94 13:07:46 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id NAA11044; Thu, 22 Dec 1994 13:02:09 -0800 Received: from ftp.com by Sun.COM (sun-barr.Sun.COM) id AA12271; Thu, 22 Dec 94 13:02:07 PST Received: from ftp.com by ftp.com ; Thu, 22 Dec 1994 16:02:06 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 22 Dec 1994 16:02:06 -0500 Received: from solensky.fenway.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA00380; Thu, 22 Dec 94 16:01:16 EST Date: Thu, 22 Dec 94 16:01:16 EST Message-Id: <9412222101.AA00380@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 From: solensky@ftp.com (Frank T Solensky) Repository: mailserv-D.ftp.com, [message accepted at Thu Dec 22 16:01:10 1994] Originating-Client: fenway.ftp.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: solensky@ftp.com (Frank T Solensky) > > Well, it's late; whaddaheck, here's an admittedly half-baked thought: > ... > The IPv6 layer might also be allowed to take the ICMPv6 header off that > frame and send back, say, half of the original frame back to the > destination. I was right: it was late.. A problem occurs when the transport layer protocol uses a checksum: since the retransmitted data is shortened, the checksum would no longer be correct. Further, one can't be sure that the ICMPv6 message includes the entire original IPv6 packet -- data at the end of the original packet is probably lost for good when running UDP. -- Frank ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 22 15:58:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14295; Thu, 22 Dec 94 15:58:33 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14289; Thu, 22 Dec 94 15:58:22 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id PAA23345; Thu, 22 Dec 1994 15:52:49 -0800 Date: Thu, 22 Dec 1994 15:52:49 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199412222352.PAA23345@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9412220501.AA20011@xirtlu.zk3.dec.com> Subject: Re: (IPng) minimum MTU Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, > I don't recall consensus anywhere on 1500 octet reassembly though? Not > that I disagree, but when and where did this get agreed to by the > working group? I was not at all moments of every meeting. As recorded in the minutes of the October implementors meeting: MTU Size -------- Two issues were discussed. 1) The Required MTU that links have to carry, and 2) The minimum overall packet size that host has to be able to reassemble. The group agreed that the minimum reassembly buffer size should be raised to 1500 bytes so as to avoid a number of problems associated with DNS and shorter packets. The minimum MTU remains at 576 bytes. This [ 2) ] was reviewed at the working group meeting at the Dec. IETF and ageed to. 1) is still being discussed. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 23 07:14:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14613; Fri, 23 Dec 94 07:14:41 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14607; Fri, 23 Dec 94 07:14:31 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id HAA22586; Fri, 23 Dec 1994 07:08:53 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA11538; Fri, 23 Dec 94 07:08:42 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14546(1)>; Fri, 23 Dec 1994 07:08:32 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Fri, 23 Dec 1994 07:08:26 -0800 To: ipng@sunroof.Eng.Sun.COM, ngtrans@sunroof.Eng.Sun.COM, addrconf@cisco.com Subject: (IPng) Re: interim IPng WG meeting In-Reply-To: deering's message of Mon, 12 Dec 94 13:37:12 -0800. <94Dec12.133724pst.12173@skylark.parc.xerox.com> Date: Fri, 23 Dec 1994 07:08:18 PST From: Steve Deering Message-Id: <94Dec23.070826pst.12174@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM This message is to confirm that the interim meetings of the IPng, addrconf, and ngtrans WGs will be held on Thursday and Friday, Feb 9 and 10, at Xerox PARC in Palo Alto, CA. We will meet for two full days, so please do not plan on an early (before 5 pm) get-away on Friday afternoon, if you can avoid it. All three groups will meet together on Thursday, with the option of breaking out into separate rooms on Friday if that appears to be worthwhile. I will plan to multicast the meeting on the MBone (only the IPng WG meeting on the second day, if the other groups break out into separate meetings). I'll send out hotel info and directions to PARC later. If you want to make your flight arrangements now, note that Palo Alto is roughly equidistant from San Franscisco and San Jose airports, so either one will work. San Jose is a little closer and usually less crowded/hectic, but you can often get better flights into San Francisco. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 26 14:08:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00457; Mon, 26 Dec 94 14:08:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00363; Mon, 26 Dec 94 07:28:36 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08455; Mon, 26 Dec 94 07:22:49 PST Received: from mail02.mail.aol.com by Sun.COM (sun-barr.Sun.COM) id AA25960; Mon, 26 Dec 94 07:22:55 PST Received: by mail02.mail.aol.com (1.38.193.5/16.2) id AA03917; Mon, 26 Dec 1994 10:23:29 -0500 Date: Mon, 26 Dec 1994 10:23:29 -0500 From: Telford001@aol.com Message-Id: <941226102321_7334531@aol.com> To: ipng@sunroof.Eng.Sun.COM Cc: Telford001@aol.com, Bob.Hinden@Eng(bobhinden) Subject: Re: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Date: Fri, Dec 16, 1994 9:44 AM EDT >X-From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) >> I know that some boxes only talk 802.3. In order to interoperate with those >> boxes, a slightly smaller MTU size is needed. >Then they are not compliant with IPv4 host requirements. All IPv4 >implementations MUST support the Ethernet format. They may also support >802.3. >Having two ways to do exactly the same thing does not enhance >interoperability. A multiplicity of ways to do the same thing is an aspect of the problems associated with PPP, MPI/FR (RFC 1490) and MPI/X.25 (RFC 1356). In point of fact, Saul Agronoff (of H&J) and I actually made use of the multiplicity of encapsulations provided by MPI/X.25 to deal with some rather nasty allignment problems. The bigger problem with PPP lay in the need for devices which used the PPP negotiation capability to be psychic. It was relatively easy for one peer in a PPP connection to tell the remote peer not to use the IPX network encapsulation for IPX network traffic. But there was no way to tell the remote peer to use the MAC bridging encapsulation for IPX traffic. In general, I am not sure that having two ways to do something is equivalent to a major limitation on interoperability. After all, the major reason for building homogeneous virtual networks at the network layer which conceal the details of the underlying catenet is precisely the multiplicity of link layers. Routers are supposed to solve the problem of interoperation when one host uses an Ethernet link layer and another device uses a Token ring link layer. Hinden could argue that we should have one global technology and thereby avoid having more than one way to network computers, but such an argument would be a waste of breath. > Given that IPv6 is a new version of IP, and that IPv4 >requires Ethernet encapsulation, I think IPv6 should also require >Ethernet encapsulation. >Bob Joachim Carlo Santos Martillo Ajami ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 26 16:10:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00526; Mon, 26 Dec 94 16:10:55 PST Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00520; Mon, 26 Dec 94 16:10:43 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id QAA01564; Mon, 26 Dec 1994 16:05:05 -0800 Date: Mon, 26 Dec 1994 16:05:05 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199412270005.QAA01564@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <941226102321_7334531@aol.com> Subject: Re: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Telford001@aol.com writes: > >X-From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) > > >Having two ways to do exactly the same thing does not enhance > >interoperability. > In general, I am not sure that having two ways to do something > is equivalent to a major limitation on interoperability. After > all, the major reason for building homogeneous virtual networks > at the network layer which conceal the details of the underlying > catenet is precisely the multiplicity of link layers. I think the key word here is "exactly". Multiple ways of doing encapsulation on a particular LAN is not useful. Having a few differnet transport protocols which provide different services is useful. > Routers are supposed to solve the problem of interoperation when > one host uses an Ethernet link layer and another device uses a > Token ring link layer. Hinden could argue that we should have > one global technology and thereby avoid having more than one > way to network computers, but such an argument would be a waste > of breath. This is pretty far from the point I was attemping to make and I would not argue that we should have one global technology. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 26 19:30:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00580; Mon, 26 Dec 94 19:30:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00574; Mon, 26 Dec 94 19:30:11 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07809; Mon, 26 Dec 94 19:24:22 PST Received: from mail02.mail.aol.com by Sun.COM (sun-barr.Sun.COM) id AA17795; Mon, 26 Dec 94 19:24:29 PST Received: by mail02.mail.aol.com (1.38.193.5/16.2) id AA06227; Mon, 26 Dec 1994 22:25:04 -0500 Date: Mon, 26 Dec 1994 22:25:04 -0500 From: Telford001@aol.com Message-Id: <941226222502_7776197@aol.com> To: ipng@sunroof.Eng.Sun.COM Cc: Telford001@aol.com, Bob.Hinden@Eng(bobhinden) Subject: Re: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >>Date: Fri, Dec 16, 1994 9:44 AM EDT >>X-From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) >>> I know that some boxes only talk 802.3. In order to interoperate with those >>> boxes, a slightly smaller MTU size is needed. >>Then they are not compliant with IPv4 host requirements. All IPv4 >>implementations MUST support the Ethernet format. They may also support >>802.3. >>Having two ways to do exactly the same thing does not enhance >>interoperability. >A multiplicity of ways to do the same thing is an aspect of the >problems associated with PPP, MPI/FR (RFC 1490) and MPI/X.25 >(RFC 1356). In point of fact, Saul Agronoff (of H&J) and I actually >made use of the multiplicity of encapsulations provided by >MPI/X.25 to deal with some rather nasty allignment problems. From owner-ipng Mon Dec 26 19:49:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00596; Mon, 26 Dec 94 19:49:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00590; Mon, 26 Dec 94 19:49:16 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08059; Mon, 26 Dec 94 19:43:28 PST Received: from mail02.mail.aol.com by Sun.COM (sun-barr.Sun.COM) id AA18640; Mon, 26 Dec 94 19:42:05 PST Received: by mail02.mail.aol.com (1.38.193.5/16.2) id AA08980; Mon, 26 Dec 1994 22:41:10 -0500 Date: Mon, 26 Dec 1994 22:41:10 -0500 From: Telford001@aol.com Message-Id: <941226224109_7788500@aol.com> To: Telford001@aol.com Cc: ipng@sunroof.Eng.Sun.COM, Bob.Hinden@Eng(bobhinden) Subject: Re: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >>Date: Fri, Dec 16, 1994 9:44 AM EDT >>X-From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) >>> I know that some boxes only talk 802.3. In order to interoperate with those >>> boxes, a slightly smaller MTU size is needed. >>Then they are not compliant with IPv4 host requirements. All IPv4 >>implementations MUST support the Ethernet format. They may also support >>802.3. >>Having two ways to do exactly the same thing does not enhance >>interoperability. >A multiplicity of ways to do the same thing is an aspect of the >problems associated with PPP, MPI/FR (RFC 1490) and MPI/X.25 >(RFC 1356). In point of fact, Saul Agronoff (of H&J) and I actually >made use of the multiplicity of encapsulations provided by >MPI/X.25 to deal with some rather nasty allignment problems. >In general, I am not sure that having two ways to do something >is equivalent to a major limitation on interoperability. After >all, the major reason for building homogeneous virtual networks >at the network layer which conceal the details of the underlying >catenet is precisely the multiplicity of link layers. >> Given that IPv6 is a new version of IP, and that IPv4 >>requires Ethernet encapsulation, I think IPv6 should also require >>Ethernet encapsulation. If I am not mistaken, the IEEE encapsulation also supports a transparent MAC layer security envelope. If a network is to make use of this security envelope, whether IPv4 or IPv6 is used, the IEEE encapsulation would be required in lieu of Ethernet 2.0 formats. >Bob >Joachim Carlo Santos Martillo Ajami Probably, defining how to encapsulate IPv6 in either IEEE MAC frames or Ethernet 2.0 frames is a more appropriate task for the IETF than specifying which are the allowed link layer frame formats. An analogue to requiring Ethernet 2.0 frames for IP on Ethernets would be to require that IP over X.25 only use 1976 X.25 link and packet layers. Joachim Carlo Santos Martillo Ajami ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 29 07:26:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01396; Thu, 29 Dec 94 07:26:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01390; Thu, 29 Dec 94 07:26:29 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19636; Thu, 29 Dec 94 07:20:37 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA00148; Thu, 29 Dec 94 07:19:28 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm012-21.dialip.mich.net [35.1.48.222]) by merit.edu (8.6.9/merit-2.0) with SMTP id KAA25439 for ; Thu, 29 Dec 1994 10:19:25 -0500 Date: Thu, 29 Dec 94 14:08:13 GMT From: "William Allen Simpson" Message-Id: <3597.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: bound@zk3.dec.com > Bill, > > I found your mail very convincing as a big computer vendor and wearing > my "individual" hat as an IETF member I think your concerns need to be > seriously addresses as I consider you in this area our expert since SIP > (with one P). > Thank you for your support. As seems to be my mantra for the past 4-5 years in the PPP WG, if you design for optimality in a low-bandwidth environment, you can always scale to a high-bandwidth environment (add CPU or variable size fields). You cannot scale from a high-bandwidth environment to low-bandwidth. > What do you think the MTU should be? > I think the Minimum MTU should be based on the realities of the datagram format, just as it was for IPv4. The IPv6 header is always 40 bytes. Note: There was an assertion that IPv4 requires enough space for the transport header. That is not correct. RFC-791 specifies (page 25) that the entire IPv4 header can be no longer than 60 bytes (IHL 15), when the options field is at its largest. We need to include the largest of the intervening extensions (the routing header), as it can be duplicated in each datagram. Add 256 bytes. This is the first significant difference from IPv4, but uses the same design considerations as IPv4 options. Note: Some persons have argued that the size of the routing header is not constrained except by the number of entries. This could lead to truly horrendous lengths -- 16 byte entries would be as much as 2K plus header. This is not acceptable, as the MMTU is incalculable and unconstrained. We need space for the hop-by-hop options, which are also duplicated in each datagram. That would be another 256 bytes. Note: We could limit this to something reasonable, since no hop-by-hop options are actually defined. Therefore, I propose that the Routing Header plus the Hop-by-Hop options be limited to 256 bytes. All other extensions are not examined on a hop-by-hop basis, and can be fragmented. The fragmentation extension itself is 8 bytes. IPv4 requires 8 bytes as a minimum amount of payload, based on the size of its fragments. IPv6 fragments are also 8 bytes. The larger total (40+256+256+8+8) is 568. The smaller total is 312. Either is acceptable to me, although I have a strong preference for the smaller 312. > Are there trade-offs we can make to satisfy all parties from the > on-slaught of mail in your opinion? > I support the previous suggestions: 1) The first packets sent SHOULD always be at the sender's link MTU. 2) A peer's MRU (from Neighbor Discovery) overrides the link MTU. 3) UDP (or any datagram transport) packets larger than 312 MUST always include the fragmentation header. 4) TCP (or any reliable transport) SHOULD NOT include the fragmentation header, until required by MTU Discovery. 5) All IPv6 nodes MUST support MTU Discovery. In addition, I recommend that the Maximum Reassembly Size be raised to something larger than 1500, such as 2048, but not more than 4096. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 30 06:15:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01664; Fri, 30 Dec 94 06:15:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01658; Fri, 30 Dec 94 06:15:23 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23635; Fri, 30 Dec 94 06:09:30 PST Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA18246; Fri, 30 Dec 94 06:09:36 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Minimum link MTU of 1500 To: ipng@sunroof.Eng.Sun.COM Date: Fri, 30 Dec 1994 14:12:11 +0000 (GMT) In-Reply-To: <199412192008.MAA21729@netcom7.netcom.com> from "Richard Fox" at Dec 19, 94 12:08:15 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 591 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > So it looks like some changes may be required but to what extent its > unknown. So what in your opinion is the RIGHT thing to do regarding > the MTU. I see 4 choices: > 1. leave it where it originally is. > 2. leave it at 1500 bytes > 3. raise it to some value > 4. lower it to some value above the original. Also consider a secondary point with the set it to a fixed value (eg 1492) which is that in TCP you can drop a subtle hint that you want a low packet size used please (TCP MSS). UDP currently lacks this and there is no API in most systems to ask for an MTU estimate. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 30 06:56:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01677; Fri, 30 Dec 94 06:56:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01671; Fri, 30 Dec 94 06:56:29 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24419; Fri, 30 Dec 94 06:50:35 PST Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA20365; Fri, 30 Dec 94 06:50:42 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Minimum link MTU of 1500 To: ipng@sunroof.Eng.Sun.COM Date: Fri, 30 Dec 1994 14:53:18 +0000 (GMT) In-Reply-To: <9412220010.AA19394@mailserv-D.ftp.com> from "Frank T Solensky" at Dec 21, 94 07:10:20 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 439 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I'm assuming that media with small MTU values are also going to be > relatively slow, therefore the delay this introduces isn't going > to be unacceptable for that link. Also: ATM provides something Slow links need to be efficient. Its not the delay of the bounced frame its the bandwidth it uses. Amateur radio especially because your time is keyup-time + length/bitrate and keyup-time is frequently a good 20% of the time. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 30 07:16:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01693; Fri, 30 Dec 94 07:16:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01687; Fri, 30 Dec 94 07:16:22 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24975; Fri, 30 Dec 94 07:10:29 PST Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA21426; Fri, 30 Dec 94 07:10:31 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA22498; Fri, 30 Dec 94 07:08:27 -0800 Received: by xirtlu.zk3.dec.com; id AA27265; Fri, 30 Dec 1994 10:08:21 -0500 Message-Id: <9412301508.AA27265@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) minimum MTU In-Reply-To: Your message of "Thu, 22 Dec 94 15:52:49 PST." <199412222352.PAA23345@jurassic.Eng.Sun.COM> Date: Fri, 30 Dec 94 10:08:15 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Thanks Bob H. Reassembly. Just needed to get hit with the paper trail which is getting large. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 30 07:51:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01709; Fri, 30 Dec 94 07:51:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01703; Fri, 30 Dec 94 07:51:25 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AB25929; Fri, 30 Dec 94 07:45:31 PST Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA23849; Fri, 30 Dec 94 07:45:26 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA25046; Fri, 30 Dec 94 07:43:56 -0800 Received: by xirtlu.zk3.dec.com; id AA01014; Fri, 30 Dec 1994 10:43:53 -0500 Message-Id: <9412301543.AA01014@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Minimum link MTU of 1500 In-Reply-To: Your message of "Thu, 29 Dec 94 14:08:13 GMT." <3597.bill.simpson@um.cc.umich.edu> Date: Fri, 30 Dec 94 10:43:47 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Thanks Bill and I appreciate your response and very good educational response on high-bandwidth vs low-bandwidth. Your mantra seems like a good one to have IMHO. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 30 11:10:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01769; Fri, 30 Dec 94 11:10:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01763; Fri, 30 Dec 94 11:10:51 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02591; Fri, 30 Dec 94 11:04:57 PST Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA10480; Fri, 30 Dec 94 11:05:05 PST Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA20822; Fri, 30 Dec 94 13:55:16 EST Received: from cabernet.wellfleet by wellfleet (4.1/SMI-4.1) id AA06052; Fri, 30 Dec 94 13:56:26 EST Date: Fri, 30 Dec 94 13:56:26 EST From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9412301856.AA06052@wellfleet> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) MTU size issues Cc: rcallon@pobox.wellfleet.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > It is not at all clear to me that adding a shim layer between IPv6 and > > small-MTU link layers to provide intra-link fragmentation and reassembly > > is "penalizing" those layers. In fact, it makes more efficient use of > > the bandwidth of those links (*assuming low packet loss*) than does IP-layer > > or transport-layer fragmentation, since each fragment does not have to > > incur the significant overhead of IP-layer or IP+transport layer headers. > > It only penalizes users if someone doesn't specify the exact method of > doing the fragmentation and reassembly. If suppliers are left to spec > this themselves, then it could become a problem for users and this > would be punative. If we agree on an MTU which is too large for any common data link, then clearly this is correct and we will need to also define a protocol for local F&R over each "small MTU" data link. Given that we are talking about "datagrams" here, and a very low but greater than zero probability of packet loss is acceptable, the F&R shim protocol should be very simple. I think that it would help the discussion if someone with appropriate experience could take a look at how hard it would be to implement a local F&R protocol to run over Localtalk networks (and PPP links), and what sort of impact this will have on the efficiency of link utilization. I agree with Steve's observation that this is likely to actually improve link utilization. Ross ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 30 11:15:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01781; Fri, 30 Dec 94 11:15:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01775; Fri, 30 Dec 94 11:15:27 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02708; Fri, 30 Dec 94 11:09:34 PST Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA10741; Fri, 30 Dec 94 11:09:41 PST Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA20871; Fri, 30 Dec 94 13:59:54 EST Received: from cabernet.wellfleet by wellfleet (4.1/SMI-4.1) id AA06133; Fri, 30 Dec 94 14:01:05 EST Date: Fri, 30 Dec 94 14:01:05 EST From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9412301901.AA06133@wellfleet> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Minimum link MTU of 1500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Well, it's late; whaddaheck, here's an admittedly half-baked thought: > > There seems to be an underlying assumption in this discussion that > the default packet size and the MTU have to be the same value. > What problems might occur if that isn't the case -- that is, one > starts off with a default that is larger then the minimum MTU? > > The scenerio that immediately comes to mind is that a packet > reaches a router that would forward the packet into a small-MTU media. > Since the packet now exceeds the MTU of that link, an ICMP 'too big' > message is generated and sent back the source node. > The source node receives the ICMP message that includes most (but not > all) of the packet that generated the error and utilize an MTU > discovery sort of algorithm to trim down the default MTU for that socket. > The IPv6 layer might also be allowed to take the ICMPv6 header off that > frame and send back, say, half of the original frame back to the > destination. > > I'm assuming that media with small MTU values are also going to be > relatively slow, therefore the delay this introduces isn't going > to be unacceptable for that link. Also: ATM provides something > along the lines of link-level fragmentation in the convergence > sublayer rather than its 53-byte cell length being a classic MTU > and thus wouldn't be impacted by this approach. > > Totally brain dead? Not unless I drank too much eggnog over Christmas :-). I think that this is a reasonable alternative to a larger MTU plus a defined shim layer for "small MTU" links. Ross ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Dec 31 03:38:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01888; Sat, 31 Dec 94 03:38:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01882; Sat, 31 Dec 94 03:37:59 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22623; Sat, 31 Dec 94 03:32:04 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA24413; Sat, 31 Dec 94 03:32:11 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-25.dialip.mich.net [35.1.48.106]) by merit.edu (8.6.9/merit-2.0) with SMTP id GAA05612 for ; Sat, 31 Dec 1994 06:32:09 -0500 Date: Sat, 31 Dec 94 11:05:30 GMT From: "William Allen Simpson" Message-Id: <3615.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) MTU size issues Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: rcallon@pobox.wellfleet.com (Ross Callon) > > > It is not at all clear to me that adding a shim layer between IPv6 and > > > small-MTU link layers to provide intra-link fragmentation and reassembly > > > is "penalizing" those layers. In fact, it makes more efficient use of > > > the bandwidth of those links (*assuming low packet loss*) than does IP-layer > > > or transport-layer fragmentation, since each fragment does not have to > > > incur the significant overhead of IP-layer or IP+transport layer headers. > > > I agree with Steve's observation that this is likely to > actually improve link utilization. > Actually, that show Steve's lack of actual implementation experience. It assumes that the mechanism would only apply to big packets, with no affect on other packets. Take for example an IP header compressed link. The TCP/IP header has been compressed to 3 or 4 bytes. Say that the link layer has another 4 bytes of overhead (RFC-1661, 1662). Say that it takes 6 bytes of overhead for the fragmentation (RFC-1717). We now have a decrease in throughput of 50%! ---- Say that the fragmentation method is encapsulating IPv6 inside IPv4 (as proposed for Ran's satellites). Now, VJ compression won't work at all! And the overhead per packet is another 20 bytes. We now have a decrease in throughput of 2,000%! ---- You say that you don't need the fragmentation and sequencing in every packet? How do you tell the difference between packet types? How do you keep the VJ packets ordered within the non-VJ packets, as required? Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com