From owner-ipng Mon May 1 08:12:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28333; Mon, 1 May 95 08:12:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28327; Mon, 1 May 95 08:12:02 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21113; Mon, 1 May 1995 08:03:23 -0700 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA05281; Mon, 1 May 95 08:03:23 PDT Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Tue, 2 May 1995 00:01:00 +0900 From: Masataka Ohta Message-Id: <199505011501.AAA00455@necom830.cc.titech.ac.jp> Subject: (IPng 23) Re: Re: Re: Neighbor Discovery and ATM To: mo@uunet.uu.net (Mike O'Dell) Date: Tue, 2 May 95 0:00:59 JST Cc: jork@nestvx.enet.dec.com, ipng@sunroof.Eng.Sun.COM In-Reply-To: ; from "Mike O'Dell" at Apr 29, 95 9:41 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > The fact that neighbor discover doesn't work unless the underlying > fabric can do some kind of broadast or multicast is neither surprising > nor particularly troubling. All this means is that some types of > fabric are not well-suited to some uses without significant assistance > in the form of "ARP servers" or some such. It is certainly NOT an > indictment of "neighbor discover" in general. The problem is that, some ATM people, including Joel, insists on the current badly architected ATM model of NHRP and say that IP architecture should change because ATM is the network of the future. So, we should ignore them or, a little more constructively, tell them that, because IPv6 is the network of the future, NHRP ATM has no future. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 1 21:37:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29480; Mon, 1 May 95 21:37:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29474; Mon, 1 May 95 21:36:52 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21490; Mon, 1 May 1995 21:28:11 -0700 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA19857; Mon, 1 May 95 21:28:09 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Tue, 2 May 1995 14:24:15 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Tue, 2 May 1995 14:26:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Tue, 2 May 1995 14:26:18 +1000 Date: Tue, 2 May 1995 14:26:18 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof2.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL May 02 14:26:18 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 172614020595 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <172614020595*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof2.Eng.Sun.COM (Non Receipt Notification Requested) Subject: (IPng 24) Re: Re: Re: Re: Neighbor Discovery and ATM X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >The problem is that, some ATM people, including Joel, insists on >the current badly architected ATM model of NHRP and say that IP >architecture should change because ATM is the network of the future. >So, we should ignore them or, a little more constructively, >tell them that, because IPv6 is the network of the future, NHRP >ATM has no future. I suppose that we can test the market with this issue and see who wins. ATM is on the ground and IP6 is yet to fly. Who can tell how long it would take to straighten out the issues and at what cost. Do we need the discord of badly matching specs just when large bandwidth is needed? Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 2 03:19:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29610; Tue, 2 May 95 03:19:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29604; Tue, 2 May 95 03:19:34 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12110; Tue, 2 May 1995 03:10:55 -0700 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA22356; Tue, 2 May 95 03:10:54 PDT Received: from vbormc.vbo.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA10663; Tue, 2 May 95 03:07:49 -0700 Received: by vbormc.vbo.dec.com; id AA06881; Tue, 2 May 95 11:57:57 +0200 Message-Id: <9505020957.AA06881@vbormc.vbo.dec.com> Received: from nestvx.enet; by vbormc.enet; Tue, 2 May 95 11:57:57 MET DST Date: Tue, 2 May 95 11:57:57 MET DST From: Markus Jork To: ipng@sunroof.Eng.Sun.COM Cc: jork@nestvx.enet.dec.com Apparently-To: ipng@sunroof.eng.sun.com Subject: (IPng 25) Re: Neighbor Discovery and ATM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Joel Halpern writes: >If I understand Mr. Jork's proposal, he suggests using a multicast >server to send out neighbor discovery frames to a "subnet" over ATM. That wasn't a proposal. I was just looking at an existing proposal, the IPv6 Neighbor Discovery spec. >While this is possible, I think it is the wrong model. There are two >approaches which I think work better. > >Approach 1 is to do what RFC 1577 does for IP/ATM. Everyone in a subnet >registers with the ARP server for that subnet. And queries are sent to >the ARP server. Work is underway to generalize this to multiple arp >servers so that redundancy is possible. > >Approach 2, which I like better, is to use the NHRP model. This is very >similar from the point of view of the host. The difference is that the >ATM attached host never learns about a subnet mask. No matter what the >destination, a query is sent to the local server for resolution. This >model works with the general view that subnets on ATM are for restricting >broadcast scopes for useful broadcasts. Address resolution and >"neighborness" should have nothing to do with such restrictions (excepting >of course where the site administrator wants such boundaries). You nicely sum up the existing IPv4 approaches. I'm aware of them. Products conforming to RFC 1577 are shipping, so this is proven to work (with the well known single-point-of-failure problem of the single ATMARP server). But this is the ipng list and I would like to talk about IPv6 over ATM. The IPv6 address resolution mechanism is described in the Neighbor Discovery spec. IPv6 implementations are supposed to use it and it is going to become a standard. On the last IETF, Bill Simpson stated explicitely that Neighbor Discovery has been designed to work over ATM. I like the idea of a general neighbor discovery mechanism, being independent of the type of link layer used. But when I pictured how the existing proposal would work over ATM, my conclusion was: :-( I described this in more detail in my last mail. >Both of these move the neighbor discovery away from using multicast, which >is important when operating over a non-broadcast media. If I understand you correctly, you say: "don't use the IPv6 Neighbor Discovery mechanism for ATM, look into the IPv4 approaches for this problem and adapt them for IPv6". Another mail (IPng 21) by Mike O'Dell seems to say a similar thing. This means we should go on with the IPv4 model of a specific address resolution mechanism for each type of data link? IPv6 Neighbor Discovery is just an updated ARP version for IEEE 802 LANs plus some radio network support? Does everybody agree with this? Markus ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 2 03:51:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29630; Tue, 2 May 95 03:51:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29624; Tue, 2 May 95 03:51:41 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12797; Tue, 2 May 1995 03:43:02 -0700 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA25467; Tue, 2 May 95 03:42:17 PDT Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: (IPng 26) Re: Re: Draft Minutes of IPng Working Group To: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Date: Tue, 2 May 1995 11:44:45 +0100 (BST) Cc: ipng@sunroof2.Eng.Sun.COM In-Reply-To: <530013010595*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> from "Jeff.Latimer@FINANCE.ausgovfinance.telememo.au" at May 1, 95 01:00:54 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > I don't see the problem. Either the law will change or the companies will > produce off shore. You can't build standards based on laws in one country > or another. You are ignoring non US law issues. You can't USE cryptography in much of the third world or france. In some countries you could potentially end up being shot for posessing the tools. > > agreed: From a technical perspective, security including privacy must > > be implemented, and is needed for Internet commerce to work. > > agreed: Some users from outside the US have expressed an interest in > > purchasing systems which include security. > > Surely the international nature of the Internet drives the argument that > the issues for security are the same for the rest of the world as for the > US. Trade is a major target for espionage which even governments engage. Encryption is not appropriate or needed by many systems, from embedded systems to the many open sites in the world. In many parts of the world it is a hazard to its users health. US ITAR rules are the least of problems. Trying to release generally available code world wide runs into far more complexities elsewhere. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 2 05:10:54 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29656; Tue, 2 May 95 05:10:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29650; Tue, 2 May 95 05:10:46 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14573; Tue, 2 May 1995 05:02:07 -0700 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA01325; Tue, 2 May 95 05:02:06 PDT Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Tue, 2 May 1995 21:00:06 +0900 From: Masataka Ohta Message-Id: <199505021200.VAA04408@necom830.cc.titech.ac.jp> Subject: (IPng 27) Re: Draft Minutes of IPng Working Group To: ipng@sunroof.Eng.Sun.COM Date: Tue, 2 May 95 21:00:04 JST In-Reply-To: <9504290004.AB01303@wellfleet>; from "Ross Callon" at Apr 28, 95 8:04 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > We agreed to progress the first two documents (IPv6 base spec, IPv6 addressing > architecture). We therefore started a discussion of the provider based > addressing specifications (the two documents by Yakov Rehkter). There was > considerable discussion pro and con. this was basically based on whether people > like provider based addresses. There seems to be some consistent misunderstanding. At Danvers, I, TWICE, said "I'm for provider based addressing". > The basic opinions ranged from "provider based > addressing is the best that we know how to do" to "provider based addresses are > not ideal in many ways". The continuation of this discussion was postponed to > later. My opinion is "provider based addressing can be good enough, though Yakovs' are not.". Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 2 06:54:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29752; Tue, 2 May 95 06:54:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29746; Tue, 2 May 95 06:54:29 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19203; Tue, 2 May 1995 06:45:49 -0700 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA13177; Tue, 2 May 95 06:45:48 PDT Received: from relay.imsi.com by wintermute.imsi.com id JAA27014; Tue, 2 May 1995 09:45:45 -0400 Received: from snark.imsi.com by relay.imsi.com id JAA29771; Tue, 2 May 1995 09:45:44 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA21676; Tue, 2 May 95 09:45:43 EDT Message-Id: <9505021345.AA21676@snark.imsi.com> To: iialan@iifeak.swan.ac.uk (Alan Cox) Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 28) Re: Re: Re: Draft Minutes of IPng Working Group In-Reply-To: Your message of "Tue, 02 May 1995 11:44:45 BST." Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 02 May 1995 09:45:42 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Alan Cox says: > > I don't see the problem. Either the law will change or the companies will > > produce off shore. You can't build standards based on laws in one country > > or another. > > You are ignoring non US law issues. You can't USE cryptography in much of the > third world or france. France, yes. However, there is work there now to change the laws. Russia also has rules on this subject. I don't know of other countries with significant domestic restrictions, although of course in many third world countries you can be jailed even if you haven't broken any written law. However, even were it illegal in half the world, so what? Even were cryptography legal only in one country, there is no reason to cripple the citizens of that land because of the madness of everyone else on earth. > Encryption is not appropriate or needed by many systems, I cannot think of a system I have worked on for the last five years for which encryption wasn't needed, whether or not we had it. If you run a telnet daemon on your machine, you need cryptography whether you think so or not. End to end cryptography is the only way to stop sesssion stealing attacks, for example. > from embedded systems to the many open sites in the world. Even if your site is open, that doesn't mean that you want it to be easily spoofable. > In many parts of the world it is a hazard to its users health. Anyone who doesn't want to use it is free not to. PErry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 2 07:55:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29773; Tue, 2 May 95 07:55:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29767; Tue, 2 May 95 07:55:26 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24069; Tue, 2 May 1995 07:46:45 -0700 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA23144; Tue, 2 May 95 07:46:43 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22055; Tue, 2 May 1995 16:46:41 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA14693; Tue, 2 May 1995 16:46:39 +0200 Message-Id: <9505021446.AA14693@dxcoms.cern.ch> Subject: (IPng 29) Re: Re: Re: Re: Draft Minutes of IPng Working Group To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Date: Tue, 2 May 1995 16:46:38 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <9505021345.AA21676@snark.imsi.com> from "Perry E. Metzger" at May 2, 95 09:45:42 am 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 Perry, > > In many parts of the world it is a hazard to its users health. > > Anyone who doesn't want to use it is free not to. > I thought that the precise issue we were arguing about so eloquently in Danvers was this: Is it OK to mandate that something claiming conformance to the the IETF IPv6 standard *must* include a full implementation of strong encryption of the payload? Surely nobody is arguing against defining the IPv6 payload encryption mechanism, or against it being an option the user can switch off. The only argument I'm aware of is whether you *must implement it to claim conformance*. Are we all agreed on this much at least? Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 2 09:10:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29820; Tue, 2 May 95 09:10:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29814; Tue, 2 May 95 09:10:26 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02065; Tue, 2 May 1995 09:01:44 -0700 Received: from eagle.ndhm.gtegsc.com by Sun.COM (sun-barr.Sun.COM) id AA08666; Tue, 2 May 95 09:01:43 PDT Received: from mail.ndhm.gtegsc.com by eagle.ndhm.gtegsc.com with SMTP; Tue, 2 May 1995 11:55:09 -0400 (EDT) Message-Id: Date: 2 May 1995 11:57:57 -0500 From: "FreedmanJ" Subject: (IPng 30) RE: Re: Re: Re: Draft Minutes of IPng Working Group To: "ipng" X-Mailer: Mail*Link SMTP-MS 3.0.2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >France, yes. However, there is work there now to change the >laws. Russia also has rules on this subject. I don't know of other >countries with significant domestic restrictions, although of course >in many third world countries you can be jailed even if you haven't >broken any written law. However, even were it illegal in half the >world, so what? Even were cryptography legal only in one country, >there is no reason to cripple the citizens of that land because of the >madness of everyone else on earth. I swear I must be missing some vital point here. If the DES transform implementation is made optional instead of mandatory how are we crippling anything? >I cannot think of a system I have worked on for the last five years >for which encryption wasn't needed, whether or not we had it. If you >run a telnet daemon on your machine, you need cryptography whether >you >think so or not. End to end cryptography is the only way to stop >sesssion stealing attacks, for example. Here we go again. I think end to end cryptography is great and I am not advocating depriving anyone. I fail to see how making the DES ESP optional deprives anyone of cryptography. If someone wants it they can get it. Even if your site is open, that doesn't mean that you want it to be easily spoofable. >Anyone who doesn't want to use it is free not to. All these arguments are in favor of end to end cryptography which I am for also. They are *NOT* arguments for making it mandatory in IPv6. Why do I have the feeling that both sides of this argument are talking beyond each other???? Jerry Freedman,Jr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 2 15:12:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00269; Tue, 2 May 95 15:12:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00262; Tue, 2 May 95 15:11:51 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18311; Tue, 2 May 1995 15:03:10 -0700 Received: from mulga.cs.mu.OZ.AU by Sun.COM (sun-barr.Sun.COM) id AA28169; Tue, 2 May 95 15:03:09 PDT Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA21197 Wed, 3 May 1995 08:01:17 +1000 (from kre@munnari.OZ.AU) To: "FreedmanJ" Cc: "ipng" Subject: (IPng 31) Re: RE: Re: Re: Re: Draft Minutes of IPng Working Group In-Reply-To: Your message of "02 May 1995 11:57:57 EST." Date: Wed, 03 May 1995 07:59:30 +1000 Message-Id: <5264.799451970@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: 2 May 1995 11:57:57 -0500 From: "FreedmanJ" Message-ID: If the DES transform implementation is made optional instead of mandatory how are we crippling anything? If its not required its very easy to opt for the easy way out and not implement it - esp given many export type laws that make actually shipping encryption difficult. For many users a vendor deciding to not implement any feature means that they no longer have a choice (many other issues decide the choice of vendor, not just one networking level feature). This means that users don't have the choice to turn it on or off, its not there to be turned on or off (and note that the rules apparently prohibit shipping systems with a hook allowing encryption to be retro-fitted, so its not even likely users would be able to just go and get the encryption code from elsewhere and install it). Requiring encryption as part of the implementation makes it clear that the implementation is not finished until this is implemented. Everyone will implement it for local consumption, even if they're required to also implement a nobbled version for general export (export under specific licence is possible). I fail to see how making the DES ESP optional deprives anyone of cryptography. If someone wants it they can get it. Are you certain of that? Where would I get it from if its not shipped with my system (and note I'm not talking of generic hardware like PCs for which software is available from a multitude of sources, but of various kinds of embedded systems where the hardware and software are an integrated whole). Where would I get the encryption code from for my routers, if their vendor decides it's an option that they'd rather avoid the hassles with? kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 3 02:35:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00868; Wed, 3 May 95 02:35:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00862; Wed, 3 May 95 02:35:51 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07923; Wed, 3 May 1995 02:27:11 -0700 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA12469; Wed, 3 May 95 02:27:09 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 3 May 1995 19:24:19 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Wed, 3 May 1995 19:26:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 3 May 1995 19:26:08 +1000 Date: Wed, 3 May 1995 19:26:08 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof2.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL May 03 19:26:08 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 082619030595 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <082619030595*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof2.Eng.Sun.COM (Non Receipt Notification Requested) Subject: (IPng 32) Re: RE: Re: Re: Re: Draft Minutes of IPng Work... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >Everyone will implement it for local consumption, even if they're >required to also implement a nobbled version for general export >(export under specific licence is possible). The issue of the nobbled version is a problem for International connections. How does one communicate if different ends have different algorithms? The Lotus Notes case comes to mind. (Does anyone know how an International Notes system communicate encrypted data to a US system give the different key lengths?) On a different point, DES may not be the algorithm used after the next few years, I like to see the algorithm pluggable or at least selectable to allow for change. Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 3 06:16:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00978; Wed, 3 May 95 06:16:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00972; Wed, 3 May 95 06:16:24 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14346; Wed, 3 May 1995 06:07:43 -0700 Received: from ftp.com (wd40.ftp.com) by Sun.COM (sun-barr.Sun.COM) id AA04890; Wed, 3 May 95 06:07:43 PDT Received: from ftp.com by ftp.com ; Wed, 3 May 1995 09:07:42 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 3 May 1995 09:07:42 -0400 Received: from kasten.europa by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA05026; Wed, 3 May 95 09:05:15 EDT Date: Wed, 3 May 95 09:05:15 EDT Message-Id: <9505031305.AA05026@mailserv-D.ftp.com> To: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Subject: (IPng 33) Re: Re: RE: Re: Re: Re: Draft Minutes of IPng Work... From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@sunroof2.Eng.Sun.COM (Non Receipt Notification Requested) Repository: mailserv-D.ftp.com, [message accepted at Wed May 3 09:05:07 1995] Originating-Client: europa Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > >Everyone will implement it for local consumption, even if they're > >required to also implement a nobbled version for general export > >(export under specific licence is possible). > > The issue of the nobbled version is a problem for International > connections. How does one communicate if different ends have > different algorithms? When doing protocol design and one faces the possibility of a multitude of algorithms and protocols, all of which can co-exist, one such algorithm is selected as the 'common' or 'default' or 'guaranteed lowest common denominator' that all (For encryption, modulo various legal and trade restrictions). systems are expected to implement. In the case of encryption we've specified DES as the 'lowest common denominator'. This way, if A wishes to carry on an encrypted conversation with B, is reasonable to assume that DES can be used. As to 'nobbling' the software for export/import/legal reasons, this isn't really an 'issue' since all systems are presumed to also implement _no_ encryption. Now, I hear the cry "But I want to encrypt my traffic to the Republic of East Noseblow!". Tough. If the REN does not allow crypto in or to be used then you can't send encrypted traffic there. If the REN allows only ROT13 for encryption, well, that's not very strong encryption, is it? You won't really be gaining any privacy by sending in this manner so you may as well send the traffic in the clear. The vendors have a slightly different cry... "I am not allowed to ship DES software to the Republic of East Noseblow. This standard is a trade restriction!" My only answer, really, is to beat on the legal system that prevents you from shipping the software. If we set the common encryption algorithm low enough so that there are no trade restrictions on it then A) It will not be very strong encryption so the users will not be getting the level of privacy from the standard that they want and deserve, and B) Add-on "additional" encryption algorithms will be developed to meet the needs of point A. So, if, eg, ftp Software can't export DES code to East Noseblow then someone else who can ship DES to E.N. will start doing so and lock ftp Software out of the E.N. market. > On > a different point, DES may not be the algorithm used after the > next few years, I like to see the algorithm pluggable or at least > selectable to allow for change. ESP allows for different encryption algorithms. The only special attributes of DES are A) a method for using DES with ESP has been defined and B) DES has been specified as the 'guaranteed lowest common denominator' which all systems are expected to implement. Feel free to define others. At some point in the future, when DES is shown to be trivially weak to break (maybe when the hardware to do it costs O($5000US) so that any random weenie can get the computrons) then we can specify another 'lowest common denominator'. -- Frank Kastenholz "The dogmas of the quiet past are inadequate to the stormy present... As our case is new, so we must think anew, and act anew" - A. Lincoln ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 3 06:20:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00990; Wed, 3 May 95 06:20:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00984; Wed, 3 May 95 06:20:08 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14481; Wed, 3 May 1995 06:11:26 -0700 Received: from mail1.digital.com by Sun.COM (sun-barr.Sun.COM) id AA05414; Wed, 3 May 95 06:11:21 PDT Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA23791; Wed, 3 May 1995 06:07:02 -0700 Received: by xirtlu.zk3.dec.com; id AA27767; Wed, 3 May 1995 09:03:45 -0400 Message-Id: <9505031303.AA27767@xirtlu.zk3.dec.com> To: Markus Jork Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 34) Re: Re: Neighbor Discovery and ATM In-Reply-To: Your message of "Tue, 02 May 95 11:57:57 +0700." <9505020957.AA06881@vbormc.vbo.dec.com> Date: Wed, 03 May 95 09:03:39 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Response to Markus PLUS a MAJOR LAST CALL Objection to some wording in System Discovery processing per this discussion I just realized. --------------------------------- >That wasn't a proposal. I was just looking at an existing proposal, the IPv6 >Neighbor Discovery spec. Good point to Joel. This must be discussable. >But this is the ipng list and I would like to talk about IPv6 over ATM. >The IPv6 address resolution mechanism is described in the Neighbor Discovery >spec. IPv6 implementations are supposed to use it and it is going to become a >standard. On the last IETF, Bill Simpson stated explicitely that Neighbor >Discovery has been designed to work over ATM. We need to verify this is true. >I like the idea of a general neighbor discovery mechanism, being independent >of the type of link layer used. But when I pictured how the existing proposal >would work over ATM, my conclusion was: :-( I described this in more detail >in my last mail. >Both of these move the neighbor discovery away from using multicast, which >is important when operating over a non-broadcast media. >If I understand you correctly, you say: "don't use the IPv6 Neighbor Discovery >mechanism for ATM, look into the IPv4 approaches for this problem and adapt >them for IPv6". Another mail (IPng 21) by Mike O'Dell seems to say a similar >thing. >This means we should go on with the IPv4 model of a specific address resolution >mechanism for each type of data link? IPv6 Neighbor Discovery is just an >updated ARP version for IEEE 802 LANs plus some radio network support? >Does everybody agree with this? I think this needs to be discussed by the WG in detail. IPv6 system discovery can evolve past IPv4 in many ways including NBMA technical strategy. Also per this conversation I have an issue with the following text in the present system discovery process specification: >2.7. Outgoing Interface > > For each transmitted packet, the internetwork-layer MUST pass the > following information to the link-layer: > > (1) the datagram itself. > > (2) the length of the datagram. > > (3) the destination physical interface. > > (4) the destination link-layer address, if any. > > In addition, the internetwork-layer SHOULD provide: > > (5) the link-layer priority value. > > The link-layer MUST notify the internetwork-layer if the packet to be > transmitted causes a link-layer precedence-related error. > Wording Change: Number (4) moved to below the statement that "the internetwork-layer SHOULD provide" so its a SHOULD and not a MUST. Rationale: The internetwork-layer may just pass a pointer to a route table entry (moving old ARP cache to BSD 4.4 Radix Tree) to the datalink or a layer above the datalink layer and if there is no link layer address perform system discovery and then send the packet. The way its worded now we have a MUST on implementations to pass a link layer address from the internetwork-layer (which could be ip6_ouput) and that may not be the way all implementors want to implement system discovery in their kernels. It needs to become a SHOULD or even MAY as I feel its not the purpose of any standard to tell an implementor what layer or where to implement a feature in a kernel. Specifically the way its worded now can cause a problem for Multicast ATM. The way it is worded now is OK for Ethernet, FDDI, and maybe Token Ring, but not for NBMA technology. This would be right now a major objection by me during any last call process for system discovery. Just make it a SHOULD or maybe a MAY as it really is an implementation design decision. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 3 12:19:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01221; Wed, 3 May 95 12:19:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01215; Wed, 3 May 95 12:19:29 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16038; Wed, 3 May 1995 12:10:46 -0700 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA02143; Wed, 3 May 95 12:05:06 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19092; Thu, 4 May 1995 05:03:16 +1000 (from kre@munnari.OZ.AU) To: rcallon@pobox.wellfleet.com (Ross Callon) Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 35) Re: Re: RE: Re: Re: Re: Draft Minutes of IPng Working Group In-Reply-To: Your message of "Wed, 03 May 1995 12:48:21 EDT." <9505031648.AA03590@wellfleet> Date: Thu, 04 May 1995 05:02:45 +1000 Message-Id: <5362.799527765@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Wed, 3 May 95 12:48:21 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-ID: <9505031648.AA03590@wellfleet> - At least for the USA, encryption is "export controlled", which is NOT THE SAME THING as "export prohibitted". While I am not an expert on this, my understanding is that there are important cases where export will be permitted. That's as I understood it too. One thing worth noting here is that while (almost) all of us believe the controls are at the very east a little silly, we, I believe, mostly imagine that the best way to remove the controls is to apply pressure to the politicians, say they'll appear as fools if they don't delete the restrictions, that they're hurting local companies, that we'll all vote for them if ... That's a way that sometimes works, but you normally need an issue in which the general public, and press, can get interested, and I doubt that export controls on cryptology quite meet those criteria. I believe there may be another way - that's to wear down the bureaucrats. Apply for licences, apply for lots of licences. Every time an application is denied, appeal. Make the bureaucrats positively sick of the rules, and attempting to apply them. Eventually they'll start to relax their criteria, licences will become easier to get, then even easier, to the point where it gets close to being a rubber stamp. Then, if it still matters, the politicians may be persuaded more easily to delete a rule that is obviously accomplishing nothing. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 3 13:00:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01431; Wed, 3 May 95 13:00:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01425; Wed, 3 May 95 13:00:37 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20119; Wed, 3 May 1995 12:51:56 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA12917; Wed, 3 May 95 09:52:12 PDT Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA27772; Wed, 3 May 95 12:43:40 EDT Received: from cabernet.wellfleet (cabernet.wellfleet.com) by wellfleet (4.1/SMI-4.1) id AA03590; Wed, 3 May 95 12:48:21 EDT Date: Wed, 3 May 95 12:48:21 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9505031648.AA03590@wellfleet> To: kre@munnari.OZ.AU Subject: (IPng 36) Re: Re: RE: Re: Re: Re: Draft Minutes of IPng Working Group Cc: ipng@sunroof2.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > If its not required its very easy to opt for the easy way out > and not implement it - esp given many export type laws that > make actually shipping encryption difficult. For many users > a vendor deciding to not implement any feature means that they > no longer have a choice (many other issues decide the choice of > vendor, not just one networking level feature). This means that > users don't have the choice to turn it on or off, its not there > to be turned on or off (and note that the rules apparently > prohibit shipping systems with a hook allowing encryption to be > retro-fitted, so its not even likely users would be able to just > go and get the encryption code from elsewhere and install it). > > Requiring encryption as part of the implementation makes it > clear that the implementation is not finished until this is > implemented. Everyone will implement it for local consumption, > even if they're required to also implement a nobbled version for > general export (export under specific licence is possible). > > (kre) Yes, I agree completely with kre. There are also three other points which agree with this: - At least for the USA, encryption is "export controlled", which is NOT THE SAME THING as "export prohibitted". While I am not an expert on this, my understanding is that there are important cases where export will be permitted. - There are many anticipated uses of the so called "Global Information Superhighway" and needed enhancements to the Internet protocol suite which REQUIRE either authentication or encryption or both. We don't have the luxury of building stuff which just won't work [an advantage that politicians have over us engineers :-( ]. - There have already been substantial problems with various security leaks / break-ins in the Internet. We have to be able to protect against this. Also, this issue has been discussed multiple times in the IPng working group. I think that I personally have been guilty of beating a dead horse on this issue after the outcome was clear to the vast majority of participants. Every time we come to the conclusion that while folks are not happy about the export controls, we have to have real security to make the standards actually work, and the standards have to be technically sound. The horse is dead, lets accept the outcome (although this is easier to say since I happen to agree with the outcome :-). Ross ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 4 01:59:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02021; Thu, 4 May 95 01:59:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02015; Thu, 4 May 95 01:58:54 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02064; Thu, 4 May 1995 01:50:12 -0700 Received: from thumper.bellcore.com by Sun.COM (sun-barr.Sun.COM) id AA15675; Thu, 4 May 95 01:44:05 PDT Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id SAA05172; Wed, 3 May 1995 18:43:10 -0400 Message-Id: <199505032243.SAA05172@thumper.bellcore.com> To: Markus Jork Cc: ipng@sunroof.Eng.Sun.COM, gja@thumper.bellcore.com Subject: (IPng 37) Re: Neighbor Discovery and ATM In-Reply-To: Your message of Fri, 28 Apr 1995 19:19:50 +0700. <9504281719.AA05933@vbormc.vbo.dec.com> Date: Wed, 03 May 1995 18:43:08 -0400 From: Grenville Armitage Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk [Discussion based on draft-simpson-ipv6-discov-process-02.txt, my apologies for coming in a little late.] Markus, [..] >>The Neighbor Discovery mechanism tries to utilize multicasting whenever >>possible. [..] >>There is still no IP multicasting over ATM but work is in progress. I am >>assuming here that it will at least resemble the mechanism described in >>draft-ietf-ipatm-ipmc-04.txt This is indeed likely. [..description of apparently senseless, redundant messaging that might occur when using IP multicast over ATM for General Solicitations..] >>So does all this make sense? Interesting question. In pure performance terms, probably not. The nature of the ATM service is such that any form of broadcast or multicast facility must essentially be faked. If we think of UNI 3.1 based ATM service, then we must 'fake' things using a mixture of host interface disciplines (emulating multicasting by personally managing their own point to multipoint VCs) and centralised address mapping entities. Your belief that there is something very redundant occuring here is not entirely unfounded. I'm told (although I never followed it) that there were religious wars fought over whether mapping IPv6 next hop addresses should be at the ICMP or 'link layer support' (aka ARP) levels. The redundancy you see wrt IPv6-over-ATM is a consequence of settling for ICMP as the mechanism. Neighbour Discovery currently _assumes_ link layer services that, at least in the case of ATM, require emulation. The emulation service has all the architectural capacity to know the information Neighbour Discovery is trying to find out. Hmmm. [Note that the issue of ATM level resource use will not go away if we hypothesise the use of UNI 4.0 (assuming it contains internal support for multicast ATM group addresses). It will be hidden, becoming an SEP, but it will be just as real. ipmc-04 just allows us in the IETF to realise what sort of games must be played, and under UNI 3.1 we have to play them ourselves.] My gut feel at the moment is that the first IPv6 over ATM drivers will borrow heavily from their IPv4 architecture, and will experiment with the hack of trapping multicasted ICMP General Solicitations and turning them into ATMARP or MARS requests (depending on whether you're using an evolved rfc1577, or experimenting with draft-armitage-ipatm-mars-unicast-00.txt) The ARP Server (or MARS) reply would then be used by the driver to fake the reception of a General Advertisement containing the information needed by the local IPv6 layer. NHRP? Despite Joel's preference for it, I can see even nastier wars being fought here as NHRP is a new, IP encapsulated protocol that broadens the whole definition of 'neighbour'. My final comment would be that Neighbour Discovery as it currently stands would work perfectly well in an IP/ATM environment using the ipmc-04 (or later) multicast support. Sure, it may not be as honed-for-speed-and-effiency as a dedicated ATMARP solution, but it _will_ work. cheers, gja --- Grenville Armitage, Research Scientist, MRE 2P-340, 445 South Street Internetworking Research Group, Bellcore. Morristown, NJ, 07960, USA (email) gja@thumper.bellcore.com (voice) +1 201 829 2635 {.. 2504 (fax)} ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 5 15:49:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00248; Fri, 5 May 95 15:49:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02737; Fri, 5 May 95 03:49:43 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07322; Fri, 5 May 1995 03:40:59 -0700 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA22216; Fri, 5 May 95 03:40:47 PDT Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Fri, 5 May 1995 19:38:22 +0900 From: Masataka Ohta Message-Id: <199505051038.TAA15863@necom830.cc.titech.ac.jp> Subject: (IPng 38) Re: Re: Neighbor Discovery and ATM To: gja@thumper.bellcore.com (Grenville Armitage) Date: Fri, 5 May 95 19:38:20 JST Cc: jork@nestvx.enet.dec.com, ipng@sunroof.Eng.Sun.COM, gja@thumper.bellcore.com In-Reply-To: <199505032243.SAA05172@thumper.bellcore.com>; from "Grenville Armitage" at May 3, 95 6:43 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > [..description of apparently senseless, redundant messaging > that might occur when using IP multicast over ATM for > General Solicitations..] > > >>So does all this make sense? Obviously, no. > The nature of the ATM service is such that any form of broadcast > or multicast facility must essentially be faked. Not necessarily. Broadcst/multicast must be faked by a server only if receivers can't have separate VCs for each sender. It is perfectly possible to have a switch-to-switch and switch-to-nic protocol to automatically configure VCs for broadcast and multicast. Even within the ATM forum's existing standardization effort, there is LAN Emulation protocol which support non-IP broadcast/multicast. With the LAN Emulation protocol, both IPv4 ARP and IPv6 neighbor discovery works as is. Moreover, as the LAN Emulation protocol has the notion of well known ATM address for the broadcast/multicast configuration server, no preconfiguration of individual host is necessary. > NHRP? Despite Joel's preference for it, I can see even nastier > wars being fought here as NHRP is a new, IP encapsulated protocol > that broadens the whole definition of 'neighbour'. Not. It is LIS model of RFC 1577 which broadens the definition of 'neighbor'. With LIS model where 'neighbor' is not physically neighber, the approach with "well know address" can not work and some logical manural configuration becomes necessary. So, I can't see any point to prefer IP-specific LIS model over LAN Emulation. NHRP is broken in a lot nastier way. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun May 7 00:12:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00484; Sun, 7 May 95 00:12:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00478; Sun, 7 May 95 00:10:17 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25166; Sat, 6 May 1995 23:59:41 -0700 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA04565; Sat, 6 May 95 23:59:35 PDT Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Sun, 7 May 1995 15:57:07 +0900 From: Masataka Ohta Message-Id: <199505070657.PAA21719@necom830.cc.titech.ac.jp> Subject: (IPng 39) Re: Re: Neighbor Discovery and ATM To: gja@thumper.bellcore.com (Grenville Armitage) Date: Sun, 7 May 95 15:57:06 JST Cc: gja@thumper.bellcore.com, jork@nestvx.enet.dec.com, ipng@sunroof.Eng.Sun.COM In-Reply-To: <199505051352.JAA17046@thumper.bellcore.com>; from "Grenville Armitage" at May 5, 95 9:52 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Quick question - why do you think LAN emulation is not > faking bcast/multicast using an essentially pt to (m)pt > technology? (let me guess - its a bannana?) Why do you think I said LAN emulation is not faking them? I did'nt. LAN emulation support not-IP-specific broadcast/multicast, over which IPv4 ARP and IPv6 neighbor discovery works as is, which is what I said. Though I also pointed out that faking is avoidable, does that matter? Masataka Ohta PS ATM is A ToMato, not a bannana. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 10 14:38:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00522; Wed, 10 May 95 14:38:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00516; Wed, 10 May 95 14:38:37 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03655; Wed, 10 May 1995 14:29:44 -0700 Received: from servo.ipsilon.com by Sun.COM (sun-barr.Sun.COM) id AA16478; Wed, 10 May 95 14:29:41 PDT Received: from [204.160.240.224] (acacia.Ipsilon.COM [204.160.240.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id OAA09574; Wed, 10 May 1995 14:28:35 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 May 1995 14:29:54 -0700 To: ipng@sunroof.Eng.Sun.COM From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 40) New IPv6 Addressing Arch Draft Cc: hinden@Ipsilon.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk A new IPv6 Addressing architecture draft has been submitted to the internet draft directories. In the mean time it is available for anonymous ftp from: ftp.ipsilon.com as pub/ipng/draft-ietf-ipngwg-addr-arch-02.txt This version of the "IPv6 Addressing Architecture" includes several changes from the previous version dated March 27, 1995. These changes include: o Added definition of Subnet-Router anycast address for use by neighbor discovery and auto-addressing. o Removed Community scop from multicast scop definitions. o Added Local Use Prefixes (Link-Local and Site-Local) to list of predefined prefixes that an implementation is required to know. o Minor clarifications, corrections, and typos fixed. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 12 03:13:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01822; Fri, 12 May 95 03:13:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01816; Fri, 12 May 95 03:13:21 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03413; Fri, 12 May 1995 03:04:15 -0700 Received: from mail04.mail.aol.com by Sun.COM (sun-barr.Sun.COM) id AA07404; Fri, 12 May 95 03:03:37 PDT Received: by mail04.mail.aol.com (1.37.109.11/16.2) id AA284653015; Fri, 12 May 1995 06:03:35 -0400 Date: Fri, 12 May 1995 06:03:35 -0400 From: Telford001@aol.com Message-Id: <950512060334_116096498@aol.com> To: dhaskin@baynetworks.com, IPv6Imp@munnari.oz.au, ipng@sunroof.Eng.Sun.COM Cc: Telford001@aol.com Subject: (IPng 41) Re: [IPv6Imp] Re: Ethernet Pr... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi Dimitry, Couldn't you just give the IPv4 and IPv6 routing functionalities separate MAC addresses? That is how I have typically handled multiprotocol routers. Joachim Martillo Original Message follows. Hi, Since there is no separate EtherType has been assigned for IPv6, de-multiplexing needs to be done off the version field of Internet header. I can't speak for other vendors but for us it would require a *major* surgery to the existent architecture in order to allow IPv6 to share EtherType with IPv4. So, if there is no compelling reasons to have the same EtherType for IPv4 and IPv6, can we get a separate code for IPv6? Thanks, Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 12 09:52:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02083; Fri, 12 May 95 09:52:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02076; Fri, 12 May 95 09:52:21 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05733; Fri, 12 May 1995 09:43:28 -0700 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA06546; Fri, 12 May 95 09:43:27 PDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06510; 12 May 95 11:42 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 42) I-D ACTION:draft-ietf-ipngwg-addr-arch-02.txt Date: Fri, 12 May 95 11:42:04 -0400 Message-Id: <9505121142.aa06510@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Addressing Architecture Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-02.txt Pages : 18 Date : 05/10/1995 This specification defines the addressing architecture of the IP Version 6 protocol. It includes a detailed description of the address formats for IPv6 [IPV6]. The editors would like to acknowledge the contributions of Paul Francis, Jim Bound, Brian Carpenter, Deborah Estrin, Peter Ford, Bob Gilligan, Christian Huitema, Tony Li, Greg Minshall, Erik Nordmark, Yakov Rekhtor, Bill Simpson, and Sue Thomson. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addr-arch-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-addr-arch-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950510135256.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950510135256.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 12 10:08:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02116; Fri, 12 May 95 10:08:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02110; Fri, 12 May 95 10:08:20 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08088; Fri, 12 May 1995 09:59:26 -0700 Received: from servo.ipsilon.com by Sun.COM (sun-barr.Sun.COM) id AA10618; Fri, 12 May 95 09:59:25 PDT Received: from [204.160.240.224] (acacia.Ipsilon.COM [204.160.240.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id JAA01715; Fri, 12 May 1995 09:57:23 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 May 1995 09:58:43 -0700 To: dhaskin@BayNetworks.com (Dimitry Haskin) From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 43) Re: [IPv6Imp] Re: Ethernet Protocol Type for IPv6 Cc: IPv6Imp@munnari.OZ.AU, ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Dimitry, You make an intesting argument. Would this mean we need to do a similar thing for for all other network types? What do other folks think? Bob p.s. I will check into the mailing list problems. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 12 10:20:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02142; Fri, 12 May 95 10:20:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01972; Fri, 12 May 95 08:51:30 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25323; Fri, 12 May 1995 08:42:27 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA22828; Fri, 12 May 95 08:42:14 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA09996; Fri, 12 May 95 11:40:37 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA20633; Fri, 12 May 95 11:45:15 EDT Date: Fri, 12 May 95 11:45:15 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505121545.AA20633@BayNetworks.com> To: hinden@Ipsilon.COM Subject: (IPng 44) Re: [IPv6Imp] Re: Ethernet Protocol Type for IPv6 Cc: IPv6Imp@munnari.OZ.AU, ipng@sunroof.Eng.Sun.COM, dhaskin@BayNetworks.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Bob, > This was discussed at great length in the past. There was a very conscious > decision to continue the same ethertype mappings as IPv4 and use the > version number to demux. One of the reasons was to not have to revisit > what kind of encapsulation to use on every type of meda and especially to > not have to discuss what kind of ethernet mapping to use (Ethernet or 802). > > Bob > I'd probably go along with the decision to use the same EtherType as IPv4, if I didn't see the techinical and implementation implications which I recently got aware off. Besides, an unique EtherType for IPv6 does not mean that media encapsulations need to be revisited -- all encapsulations are as they are for IPv4 except a different EtherType value. A historical lesson is ST2 (IPv5). Initially ST2 shared EtherType with IPv4. But, as the result of the implementation and deployment experience, the separate EtherType for ST2 was used -- 0x5354. Appart from using a different EtherType, ST2 adopted the same media encapsulations as for IPv4. Among the reasons for using an unique EtherType for ST2 were: - improved performance since no extra level of demultiplexing. - there were a number of legacy systems (and I'm confident still are ;\ ) that handled only IPv4 and did not check the version of IP header (e.g. Motorola's security encapsulation device (NES)). Such systems crashed when ST2 packets showed up. IMO, we should pay attention to the ST2 experience. Or should we learn the hard way?! :) > p.s. What problems are you having posting to the IPng list? My messages just don't get posted. I've informed Steve Parker but haven't got any response as yet. Dimitry ----- Begin Included Message ----- Date: Wed, 10 May 95 17:05:36 EDT From: dhaskin (Dimitry Haskin) To: ipng@sunroof.eng.sun.com Subject: Ethernet protocol type for IPv6 Cc: dhaskin Content-Length: 465 Hi, Since there is no separate EtherType has been assigned for IPv6, de-multiplexing needs to be done off the version field of Internet header. I can't speak for other vendors but for us it would require a *major* surgery to the existent architecture in order to allow IPv6 to share EtherType with IPv4. So, if there is no compelling reasons to have the same EtherType for IPv4 and IPv6, can we get a separate code for IPv6? Thanks, Dimitry ----- End Included Message ----- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 12 10:21:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02159; Fri, 12 May 95 10:21:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01982; Fri, 12 May 95 08:58:28 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27083; Fri, 12 May 1995 08:49:31 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA24292; Fri, 12 May 95 08:49:11 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA10202; Fri, 12 May 95 11:47:35 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA20991; Fri, 12 May 95 11:52:21 EDT Date: Fri, 12 May 95 11:52:21 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505121552.AA20991@BayNetworks.com> To: Telford001@aol.com Subject: (IPng 45) Re: [IPv6Imp] Re: Ethernet Pr... Cc: dhaskin@BayNetworks.com, IPv6Imp@munnari.oz.au, ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Date: Fri, 12 May 1995 06:03:35 -0400 > From: Telford001@aol.com > Subject: Re: [IPv6Imp] Re: Ethernet Pr... > > Hi Dimitry, > > Couldn't you just give the IPv4 and IPv6 routing functionalities > separate MAC addresses? That is how I have typically > handled multiprotocol routers. > > Joachim Martillo Joachim, Thanks for advice, but this wouldn't solve my problem. Besides, I don't think we can/should require to use a separate MAC addresses for IPv4 and IPv6. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 12 10:43:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02211; Fri, 12 May 95 10:43:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02205; Fri, 12 May 95 10:43:44 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13427; Fri, 12 May 1995 10:34:51 -0700 Received: from servo.ipsilon.com by Sun.COM (sun-barr.Sun.COM) id AA19015; Fri, 12 May 95 10:34:49 PDT Received: from [204.160.240.224] (acacia.Ipsilon.COM [204.160.240.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id KAA02138; Fri, 12 May 1995 10:33:39 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 May 1995 10:34:59 -0700 To: IPv6Imp@munnari.OZ.AU, ipng@sunroof.Eng.Sun.COM From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 46) Re: [IPv6Imp] Re: Ethernet Protocol Type for IPv6 Cc: dhaskin@baynetworks.com (Dimitry Haskin) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Point of order. Lets keep this on one mailing list, not both. My preference is for the implementors list. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 12 10:52:49 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02237; Fri, 12 May 95 10:52:49 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02231; Fri, 12 May 95 10:52:37 PDT Received: from picadilly.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id KAA08109; Fri, 12 May 1995 10:43:41 -0700 Received: from picadilly by picadilly.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id KAA03127; Fri, 12 May 1995 10:42:32 -0700 Message-Id: <199505121742.KAA03127@picadilly.Eng.Sun.COM> To: dhaskin@BayNetworks.com (Dimitry Haskin) Cc: jrh@jurassic-248, ipng@sunroof Subject: (IPng 47) Mailing list delays, important reminder Date: Fri, 12 May 1995 10:42:28 -0700 From: Steve Parker Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk - .. - My messages just don't get posted. I've informed Steve Parker but - haven't got any response as yet. - - Dimitry I haven't received your message directly yet. The problem is that dhaskin@baynetworks.com does not show up as a subscriber to the ipng list, so it is bounced for hand-processing before it is forwarded to the list. This messages are en route now. (I have also added taken steps to prevent this happening for other members of baynetworks.com.) So to remind everyone on the list: If you post from an address other than the address which the ipng list has for you, it will be delayed. If you do not wish your posts to be delayed, you may add any addresses which you might ever post from to the "autoapprove" list. You do this by sending a message to majordomo@sunroof.eng.sun.com with the message body: subscribe autoapprove The reason the list works this way is that periodically broken X.400 and PC mailers send bounces back to the list. This enables the list keepers to intercept these, preventing mail loops. (You might be suprized how often this happens...) Cheers, ~sparker ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 12 11:33:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02392; Fri, 12 May 95 11:33:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02383; Fri, 12 May 95 11:33:22 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19721; Fri, 12 May 1995 11:24:24 -0700 Received: from lobster.wellfleet.com by venus.Sun.COM (Sun.COM) id LAA00608; Fri, 12 May 1995 11:24:22 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA14631; Fri, 12 May 95 14:21:37 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA27444; Fri, 12 May 95 14:26:23 EDT Date: Fri, 12 May 95 14:26:23 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505121826.AA27444@BayNetworks.com> To: GeertJan.deGroot@ripe.net Subject: (IPng 48) Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.eng., dhaskin@BayNetworks.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > From: Geert Jan de Groot > Subject: Re: Ethernet Protocol Type for IPv6 > Date: Fri, 12 May 1995 12:09:34 +0200 > > On Thu, 11 May 95 17:25:25 EDT Dimitry Haskin wrote: > > Since there is no separate EtherType has been assigned for IPv6, > > de-multiplexing needs to be done off the version field of > > Internet header. I can't speak for other vendors but for us it would > > require a *major* surgery to the existent architecture in order to allow > > IPv6 to share EtherType with IPv4. > > Out of interest, can you elaborate on these problems? > I think that IP=IP, despite version numbers > (things like ntp didn't get new port numbers assigned either > when protocol versions changed) > On the other hand, if this causes problems, then the appropiate > time to speak up is indeed _now_. > > I think that other people on the list are interested too... > > Geert Jan > Geert Jan, Multiprotocol router/bridges route protocols that are configured and bridge otherwise. Normally the link layer needs to make the route/bridge decision without looking in the data portion of the media frame. In this case decision making is quite efficient -- if there is a protocol that explicitly registered for the EtherType of a given frame, the frame is sent to that protocol, otherwise it is bridged. Routed protocols can be added or removed without any changes to the link layer. Now, what if a router/bridge is configured to route IPv4 packets but IPv6 packets need to be bridged? If IPv4 and IPv6 had different EtherTypes, IPv6 packet could be very efficiently bridged since there would be no registration for IPv6 EtherType. If IPv4 and IPv6 use the same EtherType... you see the picture! Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 12 13:07:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02575; Fri, 12 May 95 13:07:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02569; Fri, 12 May 95 13:07:25 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01995; Fri, 12 May 1995 12:58:32 -0700 Received: from thumper.bellcore.com by Sun.COM (sun-barr.Sun.COM) id AA18321; Fri, 12 May 95 12:58:31 PDT Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id PAA02852; Fri, 12 May 1995 15:58:19 -0400 Message-Id: <199505121958.PAA02852@thumper.bellcore.com> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: GeertJan.deGroot@ripe.net, gja@thumper.bellcore.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng 49) Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of Fri, 12 May 1995 14:26:23 -0400. <9505121826.AA27444@BayNetworks.com> Date: Fri, 12 May 1995 15:58:17 -0400 From: Grenville Armitage Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk [..] >>If IPv4 and IPv6 had different >>EtherTypes, IPv6 packet could be very efficiently bridged since >>there would be no registration for IPv6 EtherType. If IPv4 and IPv6 >>use the same EtherType... you see the picture! The picture is that some vendors have assumed that "IP" really meant "IPv4", and have hardcoded the consequential behaviour - thus rendering the 'version' field in the IP packet header meaningless. An interesting problem - but whose? gja ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 12 14:25:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02836; Fri, 12 May 95 14:25:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02830; Fri, 12 May 95 14:25:27 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11712; Fri, 12 May 1995 14:16:33 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA02990; Fri, 12 May 95 14:16:32 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA19460; Fri, 12 May 95 17:15:02 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA06110; Fri, 12 May 95 17:19:48 EDT Date: Fri, 12 May 95 17:19:48 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505122119.AA06110@BayNetworks.com> To: gja@thumper.bellcore.com Subject: (IPng 50) Re: Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM, dhaskin@BayNetworks.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Subject: Re: (IPng 48) Re: Ethernet Protocol Type for IPv6 > Date: Fri, 12 May 1995 15:58:17 -0400 > From: Grenville Armitage > Content-Length: 468 > > > [..] > >>If IPv4 and IPv6 had different > >>EtherTypes, IPv6 packet could be very efficiently bridged since > >>there would be no registration for IPv6 EtherType. If IPv4 and IPv6 > >>use the same EtherType... you see the picture! > > The picture is that some vendors have assumed that "IP" > really meant "IPv4", and have hardcoded the consequential > behaviour - thus rendering the 'version' field in the IP > packet header meaningless. > > An interesting problem - but whose? > > gja > No, Grenville, you did get the picture. I just explained the performance penalty which would need to be paid for bridged traffic in a dual stack (IPv4 and IPv6) environment if EtherType stay the same for both protocols. This is the penalty for all bridge/router vendors (if it isn't so, other bridge/router vendors can correct me). It also can be a problem for a good number of Internet users who have no affiliation to Internet equipment vendors but happen to have legacy systems (not ours) which would go down under when IPv6 packets show up. The ST2 (which, you know, is IP too) deployment experience is a testament for it. Believe me or not, but there can be a lot of unhappy people out there when we'll try to deploy IPv6. This we definitely should try to avoid. Regards, Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 12 15:26:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02943; Fri, 12 May 95 15:26:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02937; Fri, 12 May 95 15:26:43 PDT Received: from jurassic.Eng.Sun.COM (jurassic-248.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19794; Fri, 12 May 1995 15:17:49 -0700 Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id PAA23615; Fri, 12 May 1995 15:17:46 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id PAA09453; Fri, 12 May 1995 15:17:35 -0700 Date: Fri, 12 May 1995 15:17:35 -0700 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199505122217.PAA09453@bobo.Eng.Sun.COM> To: dhaskin@BayNetworks.com Subject: (IPng 51) Re: Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Multiprotocol router/bridges route protocols that are configured and > bridge otherwise. Normally the link layer needs to make the route/bridge > decision without looking in the data portion of the media frame. In this > case decision making is quite efficient -- if there is a protocol that > explicitly registered for the EtherType of a given frame, the frame is > sent to that protocol, otherwise it is bridged. Routed protocols > can be added or removed without any changes to the link layer. > > Now, what if a router/bridge is configured to route IPv4 packets but > IPv6 packets need to be bridged? If IPv4 and IPv6 had different > EtherTypes, IPv6 packet could be very efficiently bridged since > there would be no registration for IPv6 EtherType. If IPv4 and IPv6 > use the same EtherType... you see the picture! I understand your performance concern. How common do you expect it to be for a router/bridge to route IPvX and bridge IPvY? Wouldn't be the common case that either both are routed or both are bridged? (After all they are just different version of the same protocol and not two different protocols.) My concern with "just" adding a separate Ethertype for IPv6 is that that soon we'll get another request for some other link layer (for equally good reasons) and before we know it we end up opening up many/all of the IP-over-X specifications. Even if we open them up just to add the the a new type field for IPv6 we run the risk of opening a can of worms. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 12 16:30:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03151; Fri, 12 May 95 16:30:12 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03145; Fri, 12 May 95 16:30:00 PDT Received: from picadilly.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id QAA28523; Fri, 12 May 1995 16:21:06 -0700 Received: from picadilly by picadilly.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id QAA04076; Fri, 12 May 1995 16:19:59 -0700 Message-Id: <199505122319.QAA04076@picadilly.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng 52) Dropped mail... Date: Fri, 12 May 1995 16:19:54 -0700 From: Steve Parker Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The mail below was bounced due to a broken mail configuration file. Only a small percentage of the list actually received the message. The problem has been corrected. As always, back correspondance can be fetch by sending a message body with 'get ipng ipng.9505' to majordomo@sunroof.eng.sun.com if you have missed any messages. Sorry for the inconvenience... ~sparker Date: Fri, 12 May 95 14:26:23 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505121826.AA27444@BayNetworks.com> To: GeertJan.deGroot@ripe.net Subject: (IPng 48) Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.eng., dhaskin@BayNetworks.com > From: Geert Jan de Groot > Subject: Re: Ethernet Protocol Type for IPv6 > Date: Fri, 12 May 1995 12:09:34 +0200 > > On Thu, 11 May 95 17:25:25 EDT Dimitry Haskin wrote: > > Since there is no separate EtherType has been assigned for IPv6, > > de-multiplexing needs to be done off the version field of > > Internet header. I can't speak for other vendors but for us it would > > require a *major* surgery to the existent architecture in order to allow > > IPv6 to share EtherType with IPv4. > > Out of interest, can you elaborate on these problems? > I think that IP=IP, despite version numbers > (things like ntp didn't get new port numbers assigned either > when protocol versions changed) > On the other hand, if this causes problems, then the appropiate > time to speak up is indeed _now_. > > I think that other people on the list are interested too... > > Geert Jan > Geert Jan, Multiprotocol router/bridges route protocols that are configured and bridge otherwise. Normally the link layer needs to make the route/bridge decision without looking in the data portion of the media frame. In this case decision making is quite efficient -- if there is a protocol that explicitly registered for the EtherType of a given frame, the frame is sent to that protocol, otherwise it is bridged. Routed protocols can be added or removed without any changes to the link layer. Now, what if a router/bridge is configured to route IPv4 packets but IPv6 packets need to be bridged? If IPv4 and IPv6 had different EtherTypes, IPv6 packet could be very efficiently bridged since there would be no registration for IPv6 EtherType. If IPv4 and IPv6 use the same EtherType... you see the picture! Dimitry ------------------------------------------------------------------------------ Message-Id: <199505121958.PAA02852@thumper.bellcore.com> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: GeertJan.deGroot@ripe.net, gja@thumper.bellcore.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng 49) Re: Re: Ethernet Protocol Type for IPv6 Date: Fri, 12 May 1995 15:58:17 -0400 From: Grenville Armitage [..] >>If IPv4 and IPv6 had different >>EtherTypes, IPv6 packet could be very efficiently bridged since >>there would be no registration for IPv6 EtherType. If IPv4 and IPv6 >>use the same EtherType... you see the picture! The picture is that some vendors have assumed that "IP" really meant "IPv4", and have hardcoded the consequential behaviour - thus rendering the 'version' field in the IP packet header meaningless. An interesting problem - but whose? gja ------------------------------------------------------------------------------ Date: Fri, 12 May 95 17:19:48 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505122119.AA06110@BayNetworks.com> To: gja@thumper.bellcore.com Subject: (IPng 50) Re: Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM, dhaskin@BayNetworks.com > Subject: Re: (IPng 48) Re: Ethernet Protocol Type for IPv6 > Date: Fri, 12 May 1995 15:58:17 -0400 > From: Grenville Armitage > Content-Length: 468 > > > [..] > >>If IPv4 and IPv6 had different > >>EtherTypes, IPv6 packet could be very efficiently bridged since > >>there would be no registration for IPv6 EtherType. If IPv4 and IPv6 > >>use the same EtherType... you see the picture! > > The picture is that some vendors have assumed that "IP" > really meant "IPv4", and have hardcoded the consequential > behaviour - thus rendering the 'version' field in the IP > packet header meaningless. > > An interesting problem - but whose? > > gja > No, Grenville, you did get the picture. I just explained the performance penalty which would need to be paid for bridged traffic in a dual stack (IPv4 and IPv6) environment if EtherType stay the same for both protocols. This is the penalty for all bridge/router vendors (if it isn't so, other bridge/router vendors can correct me). It also can be a problem for a good number of Internet users who have no affiliation to Internet equipment vendors but happen to have legacy systems (not ours) which would go down under when IPv6 packets show up. The ST2 (which, you know, is IP too) deployment experience is a testament for it. Believe me or not, but there can be a lot of unhappy people out there when we'll try to deploy IPv6. This we definitely should try to avoid. Regards, Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 12 16:33:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03163; Fri, 12 May 95 16:33:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03157; Fri, 12 May 95 16:32:49 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27965; Fri, 12 May 1995 16:23:56 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA23466; Fri, 12 May 95 16:23:56 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA21363; Fri, 12 May 95 19:22:25 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA09854; Fri, 12 May 95 19:27:11 EDT Date: Fri, 12 May 95 19:27:11 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505122327.AA09854@BayNetworks.com> To: nordmark@jurassic-248.Eng.Sun.COM Subject: (IPng 53) Re: Re: Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM, dhaskin@BayNetworks.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Erik, > How common do you expect it to be for a router/bridge > to route IPvX and bridge IPvY? > Wouldn't be the common case that either both are routed or both > are bridged? (After all they are just different version of the > same protocol and not two different protocols.) > I could be wrong, but I expect that the desire to route IPv4 and bridge IPv6 will be quite common in initial stages of the IPv6 deployment. Since initially IPv6 traffic will be small, it makes sense to deploy only couple IPv6 routers on a large network and bridge IPv6 packets between LAN segments but continue to route massive IPv4 traffic at all segment boundaries. Such a strategy also conforms to rules of graduate deployment. > My concern with "just" adding a separate Ethertype for IPv6 is that > that soon we'll get another request for some other link layer > (for equally good reasons) > and before we know it we end up opening up many/all of the IP-over-X > specifications. Even if we open them up just to add > the the a new type field for IPv6 we run the risk of opening > a can of worms. > I haven't seen a can of worms opened when an unique EtherType was adopted by IPv5 (ST-2). But a can of worms was wide opened when ST-2 was deployed with the same EtherType as for IPv4. The IPng WG was wise enough to change ICMP protocol type for IPv6 for fear breaking legacy implementations. What if we exhibit a similar prudence with EtherType? Regards, Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 12 22:09:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03601; Fri, 12 May 95 22:09:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03595; Fri, 12 May 95 22:09:22 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15765; Fri, 12 May 1995 22:00:12 -0700 Received: from dylan.mindspring.com by Sun.COM (sun-barr.Sun.COM) id AA18939; Fri, 12 May 95 22:00:12 PDT Received: from sthomas.mindspring.com [168.121.37.118] by dylan.mindspring.com with SMTP id BAA01361; Sat, 13 May 1995 01:00:01 -0400 Message-Id: <199505130500.BAA01361@dylan.mindspring.com> X-Sender: sthomas@mindspring.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 13 May 1995 00:56:25 -0400 To: dhaskin@BayNetworks.com (Dimitry Haskin), nordmark@jurassic-248.Eng.Sun.COM From: sthomas@mindspring.com (Stephen Thomas) Subject: (IPng 54) Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM, dhaskin@BayNetworks.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk At 07:27 PM 5/12/95 EDT, Dimitry Haskin wrote: >I could be wrong, but I expect that the desire to route IPv4 and >bridge IPv6 will be quite common in initial stages of the IPv6 deployment. I also expect there to be such a desire, but I suspect that the desire might be misguided. If you truly are transitioning from IPv4 to IPv6, then you're likely to want to use the IPv4-compatible prefixes for your IPv6 addresses. But, of course, if you're routing IPv4, the two segments will have to be different subnets, and if you're bridging IPv6, you'll want them to have the same prefix. Contradiction. On the other hand, as a router implementor, separate Ethernet types do make implementations easier and more flexible. It's a lot easier to hook into Ethernet demultiplexing that IP versioning. In several specific implementations of which I'm aware, adding IPv6 with its own type can be done with absolutely no modifications to the IPv4 software. The same cannot be said if they share the same type. Actually adding the new code to tap off version 6 may not be a big deal, but it does mean a new revision of the code, more complex configuration management, extra regression testing, .... (But, then again, that kind of thing does mean job security to us software engineers ;^) --Stephen ______________________________ Stephen A. Thomas 4397 Windsor Oaks Circle Marietta, GA 30066-2387 E-mail: sthomas@mindspring.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat May 13 06:24:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03763; Sat, 13 May 95 06:24:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03757; Sat, 13 May 95 06:24:28 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29668; Sat, 13 May 1995 06:15:34 -0700 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA10452; Sat, 13 May 95 06:15:35 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/24Feb95) id AA10772; Sat, 13 May 95 06:14:28 -0700 Received: by xirtlu.zk3.dec.com; id AA02978; Sat, 13 May 1995 09:14:16 -0400 Message-Id: <9505131314.AA02978@xirtlu.zk3.dec.com> To: hinden@ipsilon.com (Bob Hinden) Cc: IPv6Imp@munnari.OZ.AU, ipng@sunroof.Eng.Sun.COM Subject: (IPng 55) Re: Re: [IPv6Imp] Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Fri, 12 May 95 10:34:59 PDT." Date: Sat, 13 May 95 09:14:10 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I AGREE WITH BOB DO NOT USE TWO LISTS SO AFTER THIS MESSAGE PICK ONE OK. I suggest we discuss this issue on the implementors list to see if folks implementing have the same demux issue as Dimitry. If we find that we do then we can come back to IPngWG and state the case. If we do not and Dimitry still wants to address it with IPngWG he can do that, but I suggest we have a little bit further discussion on implementation issues and see if its a problem for all or a few. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat May 13 07:30:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03776; Sat, 13 May 95 07:30:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03770; Sat, 13 May 95 07:30:45 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00596; Sat, 13 May 1995 07:21:50 -0700 Received: from mail06.mail.aol.com by Sun.COM (sun-barr.Sun.COM) id AA12309; Sat, 13 May 95 07:21:51 PDT Received: by mail06.mail.aol.com (1.37.109.11/16.2) id AA011364874; Sat, 13 May 1995 10:21:14 -0400 Date: Sat, 13 May 1995 10:21:14 -0400 From: Telford001@aol.com Message-Id: <950513102113_117342785@aol.com> To: sthomas@mindspring.com, dhaskin@baynetworks.com, nordmark@jurassic-248.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM, cisco@spot.colorado.edu, Telford001@aol.com, martillo@thurifer.harvard.edu Subject: (IPng 56) Re: Re: Ethernet Pr... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >At 07:27 PM 5/12/95 EDT, Dimitry Haskin wrote: >>I could be wrong, but I expect that the desire to route IPv4 and >>bridge IPv6 will be quite common in initial stages of the IPv6 deployment. >I also expect there to be such a desire, but I suspect that the desire >might be misguided. If you truly are transitioning from IPv4 to IPv6, then >you're likely to want to use the IPv4-compatible prefixes for your IPv6 >addresses. But, of course, if you're routing IPv4, the two segments will >have to be different subnets, and if you're bridging IPv6, you'll want them >to have the same prefix. Contradiction. I am a little baffled. All the bridge routers which I design have the ability to bridge and to route the same protocol at a given physical interface. They can do simultaneous bridging and routing because the router functionality has no physical ports. Instead the router functionality has logical interfaces onto logical subbridges. The physical interfaces are actually MAC ports on logical subbridges, the assumption being that a subnetwork (or equivalent) is a high bandwidth switching fabric built from LAN segments and LAN switches or fully powered bridges. I call this architechture the Logical Subbridge (LSB) Router Architecture. The next generation architecture is the virtual device architecture which is considerably more flexible. Historically, the Wellfleets and Ciscos corresponded to the deficient parallel router filtering bridge architecture (they bridge what they do not route). I actually though that Cisco had added LSB functionality via bridge groups and that Wellfleet routers had the concept of interface groups which more or less did the same thing. The LSB and virtual device architectures make far tidier multiprotocol router functionalities. Each separate router functionality can have its own logical interface onto a logical subbridge and therefore its own MAC address -- which means that when running protocols like DECNET which require a specific set of MAC addresses, the MAC addresses associated with the other routed protocols do not have to change. >On the other hand, as a router implementor, separate Ethernet types do make >implementations easier and more flexible. It's a lot easier to hook into >Ethernet demultiplexing that IP versioning. In several specific implementations >of which I'm aware, adding IPv6 with its own type can be done with absolutely >no modifications to the IPv4 software. The same cannot be said if they share >the same type. Actually adding the new code to tap off version 6 may not >be a big deal, but it does mean a new revision of the code, more complex >configuration management, extra regression testing, .... (But, then again, >that kind of thing does mean job security to us software engineers ;^) IPv6 and IPv4 are essentially completely distinct protocols. While the protocol specifiers might claim otherwise it makes hardly more sense to give them the same protocol type than to give IPv4 and IPX the same protocol type. (I do believe I could make as good a case to give IPv6 and IPX the same protocol type as I could make to give IPv6 and IPv4 the same protocol type). But because IPv6 and IPv4 are essentially completely distinct protocols, in the case of multiprotocol routers -- any router supporting IPv6 and IPv4 is a multiprotocol router -- giving the different protocol suites the same MAC addresses at the network layer is really a bad approach. I would recommend giving IPv6 its own ethertype because the approach is more consistent with how multiprotocol computer networking is done. I would also recommend that routers in general support separate MAC addresses for each protocol suite. I would not recommend giving IPv6 its own ethertype merely because some router implementations are deficient in handling the issue of simultaneous bridging and routing. It reminds me too much of the old days at Prime where there were sort of interacting deficiencies in the C compiler and the linker as a consequence of which the engineers decide to modify the hardware. One could then ask how should multiprotocol end-hosts be implemented. Today stand alone bridges and routers really no longer make much sense. For this reason I am building EISA LAN switch adapter cards with outboard routing capability (PCI to follow, then maybe VME if it makes market sense). Depending how the bus interface is configured, the host can see a single multiprotocol interface associated with a single MAC address on the LAN switch or multiple single protocol interfaces each associated with its own MAC address on the LAN switch adapter card. > --Stephen Joachim Martillo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat May 13 10:16:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03802; Sat, 13 May 95 10:16:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03796; Sat, 13 May 95 10:16:22 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04233; Sat, 13 May 1995 10:07:27 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA19084; Sat, 13 May 95 10:07:29 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA29258; Sat, 13 May 95 13:05:54 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA27730; Sat, 13 May 95 13:10:28 EDT Date: Sat, 13 May 95 13:10:28 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505131710.AA27730@BayNetworks.com> To: bound@zk3.dec.com Subject: (IPng 57) Re: [IPv6Imp] Re: Re: Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > From owner-IPv6Imp@munnari.OZ.AU Sat May 13 09:58:37 1995 > From: bound@zk3.dec.com > To: hinden@ipsilon.com (Bob Hinden) > Cc: IPv6Imp@munnari.OZ.AU, ipng@sunroof.eng.sun.com > Subject: [IPv6Imp] Re: (IPng 46) Re: Re: Ethernet Protocol Type for IPv6 > Date: Sat, 13 May 95 09:14:10 -0400 > X-Mts: smtp > Content-Length: 490 > > I AGREE WITH BOB DO NOT USE TWO LISTS SO AFTER THIS MESSAGE PICK ONE > OK. > > I suggest we discuss this issue on the implementors list to see if folks > implementing have the same demux issue as Dimitry. If we find that we do > then we can come back to IPngWG and state the case. If we do not and > Dimitry still wants to address it with IPngWG he can do that, but I > suggest we have a little bit further discussion on implementation issues > and see if its a problem for all or a few. > > thanks > /jim > I prefer the ipng list since I feel there is a very important IPv6 deployment issue which needs attention of a larger than implementors audience. If we use the same EtherType for IPv6 and IPv4, we risk to scare away potential users of IPv6 if there is the danger that their legacy systems stop function when IPv6 is indroduced. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat May 13 10:41:54 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03816; Sat, 13 May 95 10:41:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03810; Sat, 13 May 95 10:41:46 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04866; Sat, 13 May 1995 10:32:45 -0700 Received: from dylan.mindspring.com by Sun.COM (sun-barr.Sun.COM) id AA20294; Sat, 13 May 95 10:32:36 PDT Received: from sthomas.mindspring.com [168.121.37.118] by dylan.mindspring.com with SMTP id NAA22805; Sat, 13 May 1995 13:32:24 -0400 Message-Id: <199505131732.NAA22805@dylan.mindspring.com> X-Sender: sthomas@mindspring.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 13 May 1995 13:28:15 -0400 To: Telford001@aol.com, dhaskin@baynetworks.com, nordmark@jurassic-248.Eng.Sun.COM From: sthomas@mindspring.com (Stephen Thomas) Subject: (IPng 58) Re: Re: Re: Ethernet Pr... Cc: ipng@sunroof.Eng.Sun.COM, cisco@spot.colorado.edu, Telford001@aol.com, martillo@thurifer.harvard.edu Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk At 10:21 AM 5/13/95 -0400, Telford001@aol.com wrote: >>>I could be wrong, but I expect that the desire to route IPv4 and >>>bridge IPv6 will be quite common in initial stages of the IPv6 deployment. > >>I also expect there to be such a desire, but I suspect that the desire >>might be misguided. If you truly are transitioning from IPv4 to IPv6, then >>you're likely to want to use the IPv4-compatible prefixes for your IPv6 >>addresses. But, of course, if you're routing IPv4, the two segments will >>have to be different subnets, and if you're bridging IPv6, you'll want them >>to have the same prefix. Contradiction. > >I am a little baffled. All the bridge routers which I design have the >ability >to bridge and to route the same protocol at a given physical interface. It's not a question of any bridge/router's capability. It is a question of how you will assign IPv4 subnet and IPv6 prefix addresses. Start with an all IPv4 internet: +-----------------------+ +------------------+ | IPv4 Router | +------------------+ | Host A 194.3.2.1 | | 194.3.2.2 195.6.5.4 | | Host B 195.6.5.5 | +------------------+ +-----------------------+ +------------------+ \ / \ / ============================= ========================= 194.3.2.0 (0xffffff00) 195.6.5.0 (0xffffff00) Now suppose you upgrade the hosts to IPv6, You'll probably want to assign them IPv6 addresses ::194.3.2.1 and ::195.6.5.5. Now, suppose you give them those assignments and tell the router to bridge IPv6. What network prefix will you use for the bridged IPv6 subnet? BTW, I don't think this is purely an implementation issue, but I will defer to the collective wisdom if we want to move it there. --Stephen ______________________________ Stephen A. Thomas 4397 Windsor Oaks Circle Marietta, GA 30066-2387 E-mail: sthomas@mindspring.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat May 13 10:58:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03828; Sat, 13 May 95 10:58:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03822; Sat, 13 May 95 10:58:01 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05230; Sat, 13 May 1995 10:49:06 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA21013; Sat, 13 May 95 10:49:07 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA29510; Sat, 13 May 95 13:47:38 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA28497; Sat, 13 May 95 13:52:24 EDT Date: Sat, 13 May 95 13:52:24 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505131752.AA28497@BayNetworks.com> To: sthomas@mindspring.com Subject: (IPng 59) Re: Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM, dhaskin@BayNetworks.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > From: sthomas@mindspring.com (Stephen Thomas) > Subject: (IPng 54) Re: Ethernet Protocol Type for IPv6 > Cc: ipng@sunroof.Eng.Sun.COM, dhaskin@BayNetworks.com > Sender: owner-ipv6@marvin > Content-Length: 1718 > > At 07:27 PM 5/12/95 EDT, Dimitry Haskin wrote: > > >I could be wrong, but I expect that the desire to route IPv4 and > >bridge IPv6 will be quite common in initial stages of the IPv6 deployment. > > I also expect there to be such a desire, but I suspect that the desire > might be misguided. If you truly are transitioning from IPv4 to IPv6, then > you're likely to want to use the IPv4-compatible prefixes for your IPv6 > addresses. But, of course, if you're routing IPv4, the two segments will > have to be different subnets, and if you're bridging IPv6, you'll want them > to have the same prefix. Contradiction. Not at all. First, I don't see why an IPv4-compatible prefix needs to be constrained to the same boundaries as the corresponding IPv4 subnet. Then, I don't see why it is so important to use the IPv4-compatible prefixes during transition... unless it is for isolated IPv6 hosts which need to be reached using the auto-tunneling. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat May 13 12:09:46 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03851; Sat, 13 May 95 12:09:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03845; Sat, 13 May 95 12:09:38 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06841; Sat, 13 May 1995 12:00:42 -0700 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA24037; Sat, 13 May 95 12:00:44 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/24Feb95) id AA27334; Sat, 13 May 95 11:55:22 -0700 Received: by xirtlu.zk3.dec.com; id AA05748; Sat, 13 May 1995 14:55:09 -0400 Message-Id: <9505131855.AA05748@xirtlu.zk3.dec.com> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 60) Re: [IPv6Imp] Re: Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Sat, 13 May 95 13:10:28 EDT." <9505131710.AA27730@BayNetworks.com> Date: Sat, 13 May 95 14:55:02 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Dimitry, OK it seems your convinced that it will cause a major implementation heartburn for vendors. So we don't need to discuss this on implist. I am just concerned such a major objection is coming up so late in the game. How did we miss this early on? Its not like we did not have routing folks on the list? You can respond to me privately. I am curious how such a major concern could be missed in the basics, if in fact consensus supports this issue after ipngwg discussion. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat May 13 13:56:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03876; Sat, 13 May 95 13:56:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03870; Sat, 13 May 95 13:55:50 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09519; Sat, 13 May 1995 13:46:56 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA28364; Sat, 13 May 95 13:46:57 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA03439; Sat, 13 May 95 16:45:03 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA02062; Sat, 13 May 95 16:49:48 EDT Date: Sat, 13 May 95 16:49:48 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505132049.AA02062@BayNetworks.com> To: bound@zk3.dec.com Subject: (IPng 61) Re: Re: [IPv6Imp] Re: Re: Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM, dhaskin@BayNetworks.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Subject: (IPng 60) Re: [IPv6Imp] Re: Re: Re: Ethernet Protocol Type for IPv6 > Date: Sat, 13 May 95 14:55:02 -0400 > From: bound@zk3.dec.com > X-Mts: smtp > Sender: owner-ipv6@marvin > Content-Length: 795 > > Dimitry, > > OK it seems your convinced that it will cause a major implementation > heartburn for vendors. So we don't need to discuss this on implist. > I am just concerned such a major objection is coming up so late in the > game. How did we miss this early on? Its not like we did not have > routing folks on the list? You can respond to me privately. I am > curious how such a major concern could be missed in the basics, if in > fact consensus supports this issue after ipngwg discussion. > > thanks > /jim Jim, It wasn't my intention to delay the request for an unique ethertype. I requested it as soon as I realized the need for it and I'm sorry I didn't realize it sooner. On positive side, it is good that the issue is presented well before IPv6 deployment is underway and I don't think it is late to get the unique ethertype now -- I believe the effect to the existing implementation is minimal (if at all) and all is needed a sentance or two in the IPv6 spec which is still a draft. I'd like reiterate that this isn't just an implementation heartburn but more importantly a smooth IPv6 deployment issue. We're all in the same boat and I've no intention to shake the boat more that it needs to. ;) Regards, Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun May 14 04:32:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04006; Sun, 14 May 95 04:32:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04000; Sun, 14 May 95 04:32:00 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01675; Sun, 14 May 1995 04:23:05 -0700 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA04316; Sun, 14 May 95 04:22:49 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21189; Sun, 14 May 1995 21:22:37 +1000 (from kre@munnari.OZ.AU) To: dhaskin@BayNetworks.com (Dimitry Haskin) Cc: GeertJan.deGroot@ripe.net, ipng@sunroof.Eng.Sun.COM Subject: (IPng 62) Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Fri, 12 May 1995 14:26:23 EDT." <9505121826.AA27444@BayNetworks.com> Date: Sun, 14 May 1995 21:22:08 +1000 Message-Id: <6769.800450528@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Fri, 12 May 95 14:26:23 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-ID: <9505121826.AA27444@BayNetworks.com> Now, what if a router/bridge is configured to route IPv4 packets but IPv6 packets need to be bridged? What do you do if a router is configured to route TP4, but TP0 needs to be bridged? (and yes I know the addressing is the same in that case, so its even less likely, but still could happen - or perhaps the opposite). kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun May 14 13:29:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04051; Sun, 14 May 95 13:29:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04045; Sun, 14 May 95 13:29:02 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09549; Sun, 14 May 1995 13:20:06 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA18527; Sun, 14 May 95 13:20:06 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA13788; Sun, 14 May 95 16:18:34 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA23918; Sun, 14 May 95 16:23:21 EDT Date: Sun, 14 May 95 16:23:20 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505142023.AA23918@BayNetworks.com> To: kre@munnari.OZ.AU Subject: (IPng 63) Re: Re: Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > From major@marvin Sun May 14 07:32:49 1995 > To: dhaskin@BayNetworks.com (Dimitry Haskin) > Cc: GeertJan.deGroot@ripe.net, ipng@sunroof.Eng.Sun.COM > Subject: (IPng 62) Re: Re: Ethernet Protocol Type for IPv6 > Date: Sun, 14 May 1995 21:22:08 +1000 > From: Robert Elz > Sender: owner-ipv6@marvin > Content-Length: 791 > > Date: Fri, 12 May 95 14:26:23 EDT > From: dhaskin@BayNetworks.com (Dimitry Haskin) > Message-ID: <9505121826.AA27444@BayNetworks.com> > Now, what if a router/bridge is configured to route IPv4 packets but > IPv6 packets need to be bridged? > > What do you do if a router is configured to route TP4, but TP0 > needs to be bridged? (and yes I know the addressing is the > same in that case, so its even less likely, but still could > happen - or perhaps the opposite). > > kre Come on! I also don't know how to route BGP-3 but to bridge BGP-4 :) It quickly can become ridiculous. Is it about "IPv6 is just a different version of IP"? IMHO, Ipv4 and IPv6 have as much or as little in common as, say, IPX and IPv4. And I respect any contrary opinion. I let philosophers and scientists to resolve that. And I frankly don't care about outcome -- it just beyond the point! My point is that there are real implementation, performance, and, most importantly, deployment problems which can be avoided if an unique ethertype is assigned to IPv6. The deployment concerns are not imaginary. They're based on the actual deployment experience with ST-2 (IPv5). There also may be good technical reasons to keep the IPv6 ethertype the same as for IPv4 so let's hear it. Let's weigh pros and cons and decide on the technical merits. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun May 14 14:13:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04078; Sun, 14 May 95 14:13:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04072; Sun, 14 May 95 14:13:05 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10477; Sun, 14 May 1995 14:04:09 -0700 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA19876; Sun, 14 May 95 14:04:09 PDT Received: from relay.imsi.com by wintermute.imsi.com id RAA01876; Sun, 14 May 1995 17:04:00 -0400 Received: from snark.imsi.com by relay.imsi.com id RAA11239; Sun, 14 May 1995 17:03:59 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA14268; Sun, 14 May 95 17:03:59 EDT Message-Id: <9505142103.AA14268@snark.imsi.com> To: dhaskin@BayNetworks.com (Dimitry Haskin) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 64) Re: Re: Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Sun, 14 May 1995 16:23:20 EDT." <9505142023.AA23918@BayNetworks.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Sun, 14 May 1995 17:03:58 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Dimitry Haskin says: > My point is that there are real implementation, performance, and, most > importantly, deployment problems which can be avoided if an unique ethertype > is assigned to IPv6. The deployment concerns are not imaginary. [...] > There also may be good technical reasons to keep the IPv6 ethertype the same > as for IPv4 so let's hear it. Let's weigh pros and cons and decide on > the technical merits. Okay. I contend that trouble is going to show up down the line if we don't do this via the version field. Implementations are going to have to get good at demultiplexing IPv4 from IPv6 coming down point to point links, odd radio links, ancient crufty network technologies, new crufty network technologies, etc. Ethernet happens to be a nice place where we can separate out the ethertypes if we like, but not all media are like that. I want my kernels and routers to deal with this well early on so that where these luxuries like multiple MAC layer types aren't available everything is debugged and works properly. Incidently, I'll point out that the time to do a compare and a jump in any decent implementation is going to be trivial compared to all the ordinary latencies one has to deal with -- in any decent implementation this should be a non issue. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun May 14 23:38:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04129; Sun, 14 May 95 23:38:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04123; Sun, 14 May 95 23:38:43 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22777; Sun, 14 May 1995 23:29:47 -0700 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA16391; Sun, 14 May 95 23:29:47 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch id AA26947; Mon, 15 May 1995 08:29:43 +0200 Received: by dxcoms.cern.ch id AA01510; Mon, 15 May 1995 08:29:42 +0200 Message-Id: <9505150629.AA01510@dxcoms.cern.ch> Subject: (IPng 65) Re: Ethernet Protocol Type for IPv6 To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Date: Mon, 15 May 1995 08:29:42 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <9505122327.AA09854@BayNetworks.com> from "Dimitry Haskin" at May 12, 95 07:27:11 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 Dimitry, > > I could be wrong, but I expect that the desire to route IPv4 and > bridge IPv6 will be quite common in initial stages of the IPv6 deployment. > Since initially IPv6 traffic will be small, it makes sense to deploy > only couple IPv6 routers on a large network and bridge IPv6 packets > between LAN segments but continue to route massive IPv4 traffic at all > segment boundaries. Possibly also at a late stage in the transition when a site has a few legacy IPv4 systems in a mainly IPv6 network. But Perry said > Okay. I contend that trouble is going to show up down the line if we > don't do this via the version field. and that feels right to me. Do we actually care if the decision to bridge a packet is taken a few instructions later? Bridges are full of kludges anyway. Regards, Brian Carpenter (CERN) (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 15 01:08:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04215; Mon, 15 May 95 01:08:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04209; Mon, 15 May 95 01:08:34 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25324; Mon, 15 May 1995 00:59:37 -0700 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA26786; Mon, 15 May 95 00:59:36 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02687; Mon, 15 May 1995 17:59:02 +1000 (from kre@munnari.OZ.AU) To: dhaskin@BayNetworks.com (Dimitry Haskin) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 66) Re: Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Sun, 14 May 1995 16:23:20 EDT." <9505142023.AA23918@BayNetworks.com> Date: Mon, 15 May 1995 17:58:29 +1000 Message-Id: <7108.800524709@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Sun, 14 May 95 16:23:20 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-ID: <9505142023.AA23918@BayNetworks.com> I also don't know how to route BGP-3 but to bridge BGP-4 :) It quickly can become ridiculous. It was pointed out to me that my previous example (TP4 vs TP0) was really pretty silly, as that's really CLNP vs X.25 (CLNS vs CONS) (which I knew), and that those two use different SAP's, which I may have once known, but had forgotten, so TP0 vs TP4 is really an example of the different ethertypes (but what about TP0 vs TP2 I ask...). As it happens, right now, I can't find an IP level protocol that has ever really evolved without changing its ethernet type field (one way or another). Is it about "IPv6 is just a different version of IP"? IMHO, Ipv4 and IPv6 have as much or as little in common as, say, IPX and IPv4. If you look at them at purely the IP layer, you're right I think, they're pretty different, and certainly need quite different code paths. However, there's much more to it than that - both have UDP & TCP layered on top, which means all that part of a router (or host) that has to deal with access lists (port numbers and such), etc, is going to be treating IP4 and IP6 very much alike. Further, the way we think about IP4 and IP6 will be very much alike. On a real philosophical point, which you may be right isn't really very relevant, this raises the question whether version numbers in protocols are ever any use, or whether any protocol change really does make something new, which should be handled by lower layer de-mux. Your concerns also raise the rather difficult question as to how much we should be concerned about compatability with old code that is clearly broken - how much effort its worth taking to avoid causing such implementations difficulty. If we could find a box that crashed if it ever saw an ethertype other than 0x800 would that mean that all protocols should use that type? There also may be good technical reasons to keep the IPv6 ethertype the same as for IPv4 so let's hear it. The ones I recall (I'm not really on either side of this issue, I can handle either way) were mostly related to stacks that had no direct access to the drivers, and could not easily, or at all, add code to support a new ethertype. On the other hand, they have control of the IP stack, and can switch based upon what they see in the IP headers. Then there's Perry's argument, and the one indicating that bridging one and routing the other is almost certainly not a good idea because of the addressing assumptions in compatability mode. On the other side are your effeciency arguments, and the problems (if those old systems still exist) with hosts seeing an 0x0800 packet not containing an IPv4 header. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 15 07:21:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04334; Mon, 15 May 95 07:21:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04328; Mon, 15 May 95 07:21:07 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06612; Mon, 15 May 1995 07:12:10 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA05819; Mon, 15 May 95 07:12:11 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA22827; Mon, 15 May 95 10:10:41 EDT Received: from eddie.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA15471; Mon, 15 May 95 10:15:27 EDT Date: Mon, 15 May 95 10:15:27 EDT From: mdavis@BayNetworks.com (Mike Davis) Message-Id: <9505151415.AA15471@BayNetworks.com> Received: by eddie.wellfleet (4.1/SMI-4.1) id AA13297; Mon, 15 May 95 10:12:22 EDT To: bound@zk3.dec.com Cc: dhaskin@BayNetworks.com, ipng@sunroof.Eng.Sun.COM In-Reply-To: <9505131855.AA05748@xirtlu.zk3.dec.com> (bound@zk3.dec.com) Subject: (IPng 67) Re: Ethernet Protocol Type for IPv6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >>>>> "jim" == bound writes: jim> Dimitry, jim> OK it seems your convinced that it will cause a major jim> implementation heartburn for vendors. So we don't need to jim> discuss this on implist. I am just concerned such a major jim> objection is coming up so late in the game. How did we miss jim> this early on? Its not like we did not have routing folks on jim> the list? You can respond to me privately. I am curious how jim> such a major concern could be missed in the basics, if in jim> fact consensus supports this issue after ipngwg discussion. At the time I noticed this `feature', it was not a problem for the implementation that I was working on. Silence implied consent, I guess. Now I'm at a different company, and more people are noting the advantages of separate ethertypes. With respect to BayNetworks' implementation, Dimitry's opinion will have to take precedence over mine, but in the abstract, I agree with those who have written that IPv6, while the successor of IPv4, is essentially a distinct protocol. jim> thanks jim> /jim -mad signoff Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 15 08:11:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04355; Mon, 15 May 95 08:11:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04349; Mon, 15 May 95 08:11:12 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10336; Mon, 15 May 1995 08:02:14 -0700 Received: from BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA14676; Mon, 15 May 95 08:02:03 PDT Message-Id: <9505151502.AA14676@Sun.COM> From: "John Day" Subject: (IPng 68) Re: Re: Re: Re: Ethernet Protocol Type for IPv6 To: kre@munnari.oz.au Cc: dhaskin@baynetworks.com, ipng@sunroof.Eng.Sun.COM In-Reply-To: <7108.800524709@munnari.OZ.AU> Date: Mon, 15 May 95 10:47:02 EST Mail-System-Version: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >On a real philosophical point, which you may be right isn't >really very relevant, this raises the question whether version >numbers in protocols are ever any use, or whether any protocol >change really does make something new, which should be handled >by lower layer de-mux. > The general rule on when you need a new version number has been: if the receiver could not process the message without knowing the new version, it was a new version. Now this does not speak to when a new version is really a new protocol. I know of no good rule for such a thing, but intuitively it would seem that if the basic header structure is fundamentally changed (pick a number, 50% or more) then you have a new protocol. While SIP started out being a new version of IP by simply dropping some fields and making the address longer, it would appear that things have evolved way beyond that. The only field that seems to be in the same place is the Version field. The two headers at this point have very little in common. We probably ought to just admit the obvious, IPv6 is a new network protocol, not a new version of IPv4. I guess the normal creeping enhancement behavior of a standards committee is at work on IPng as well. Take care, John ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 15 08:21:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04387; Mon, 15 May 95 08:21:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04380; Mon, 15 May 95 08:21:26 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11206; Mon, 15 May 1995 08:12:29 -0700 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA16663; Mon, 15 May 95 08:12:30 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA28822; Mon, 15 May 95 08:09:48 -0700 Received: by xirtlu.zk3.dec.com; id AA03951; Mon, 15 May 1995 11:09:43 -0400 Message-Id: <9505151509.AA03951@xirtlu.zk3.dec.com> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: kre@munnari.OZ.AU, ipng@sunroof.Eng.Sun.COM Subject: (IPng 69) Re: Re: Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Sun, 14 May 95 16:23:20 EDT." <9505142023.AA23918@BayNetworks.com> Date: Mon, 15 May 95 11:09:37 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The demux is pretty simple for version IPv6 and causes no pain on a Host implementation I am aware of at this time. So that is a "present" data point. I am running a dual network layer too and it works fine. My concern with a new ether-type is three fold: 1. We have not really created a new type its still the Internet protocol. Does IPv5 have its own ether-type? Besides we are running ATM using IPv5 and demux on version now so that link type works (this is AD work not product work). 2. A new ether-type at the datalink will cause more code changes on a host when the present demux works fine. What benefit do I get? I can't see one? The down side is now I need to make sure I use the new ether-type for IPv6 at the datalink. 3. Demux on version number will still be required for non ether-type connections. Can we focus this issue that it is a router implementation issue only? If so can we bring the implementation discussion down from abstraction to a lower focus? Is the issue for a router that they want to bridge at the datalink and not have to enter the Internetwork layer to demux? I am not a router engineer and trying to understand I do know bridges well but will stop here? More questions or ideas after a response. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 15 09:06:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04453; Mon, 15 May 95 09:06:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04447; Mon, 15 May 95 09:06:30 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15815; Mon, 15 May 1995 08:57:32 -0700 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA25297; Mon, 15 May 95 08:57:31 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA02246; Mon, 15 May 95 08:51:59 -0700 Received: by xirtlu.zk3.dec.com; id AA05870; Mon, 15 May 1995 11:51:47 -0400 Message-Id: <9505151551.AA05870@xirtlu.zk3.dec.com> To: "John Day" Cc: kre@munnari.oz.au, dhaskin@baynetworks.com, ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com Subject: (IPng 70) Re: Re: Re: Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Mon, 15 May 95 10:47:02 EST." <9505151502.AA14676@Sun.COM> Date: Mon, 15 May 95 11:51:40 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >While SIP started out being a new version of IP by simply dropping some >fields and making the address longer, it would appear that things have >evolved way beyond that. The only field that seems to be in the same >place is the Version field. The two headers at this point have very >little in common. We probably ought to just admit the obvious, IPv6 is >a new network protocol, not a new version of IPv4. This is a good point and one I think we should consider. It really is a new protocol and as I work on IPv6 this becomes more obvious to me each day. And handling PCBs for transition and using Radix Tree as ndp (neighbor discovery protocol) cache is not easy stuff or simple either. Scratching my head and core dumps are a way of life right now. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 15 09:16:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04465; Mon, 15 May 95 09:16:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04459; Mon, 15 May 95 09:16:05 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16908; Mon, 15 May 1995 09:07:07 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA27418; Mon, 15 May 95 09:07:07 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA26450; Mon, 15 May 95 12:05:35 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA20774; Mon, 15 May 95 12:10:21 EDT Date: Mon, 15 May 95 12:10:21 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505151610.AA20774@BayNetworks.com> To: brian@dxcoms.cern.ch Subject: (IPng 71) Re: Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM, dhaskin@BayNetworks.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > 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-ipv6@marvin > Content-Length: 1197 > > Dimitry, > > > > I could be wrong, but I expect that the desire to route IPv4 and > > bridge IPv6 will be quite common in initial stages of the IPv6 deployment. > > Since initially IPv6 traffic will be small, it makes sense to deploy > > only couple IPv6 routers on a large network and bridge IPv6 packets > > between LAN segments but continue to route massive IPv4 traffic at all > > segment boundaries. > > Possibly also at a late stage in the transition when a site has > a few legacy IPv4 systems in a mainly IPv6 network. > > But Perry said > > > Okay. I contend that trouble is going to show up down the line if we > > don't do this via the version field. > > and that feels right to me. Do we actually care if the decision > to bridge a packet is taken a few instructions later? > Brian, I failed to point it in my previous mail, but it is not just making the decision a few instructions later. If EtherType of IPv6 stays as it is now, popular IPv4 routers will not bridge IPv6 if they're not upgraded to do so -- they just drop IPv6 packets as having an invalid IP version. I contend that our deployment story will be much stronger if no upgrade is required to the already installed IPv4 router/bridges in order for them to bridge IPv6. > Bridges are full of kludges anyway. Nevertheless they are widly used and should be included in our deployment plans. > Regards, > Brian Carpenter (CERN) (brian@dxcoms.cern.ch) > voice +41 22 767 4967, fax +41 22 767 7155 Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 15 10:18:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04578; Mon, 15 May 95 10:18:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04572; Mon, 15 May 95 10:17:58 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26440; Mon, 15 May 1995 10:08:58 -0700 Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA11197; Mon, 15 May 95 10:08:57 PDT Subject: (IPng 72) Re: Re: Re: Re: Ethernet Protocol Type for IPv6 To: IPng Mailing list Date: Mon, 15 May 1995 13:08:42 -0500 (EST) From: Dan McDonald Cc: 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: <9505151808.aa06073@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I'll agree with Jim saying that demuxing off the version bits is absolutely no problem with a primarily host implementation. (Once ip_forwarding is turned on, we have a router, but that's semantics! :) I'll also go so far as to say that it wouldn't be TOO much of a pain to switch off of ethertype, but as Jim said, the gain isn't worth the pain. ALSO, there is the potential for laziness on the part of version checking code. A non-lazy implementation will be checking the version anyway, so additional checking would be required for demuxing off ethertype. A lazy implementation may screw up if it is fed bogus packets. My opinion on all of this is that it seems we had the Ethertype discussion before I even left school (didn't this happen back with SIP, with one P?). Furthermore, demuxing on Ethertype will cause additional cycles, or lazy implementations. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 15 10:23:32 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04596; Mon, 15 May 95 10:23:32 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01982; Fri, 12 May 95 08:58:28 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27083; Fri, 12 May 1995 08:49:31 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA24292; Fri, 12 May 95 08:49:11 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA10202; Fri, 12 May 95 11:47:35 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA20991; Fri, 12 May 95 11:52:21 EDT Date: Fri, 12 May 95 11:52:21 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505121552.AA20991@BayNetworks.com> To: Telford001@aol.com Subject: (IPng 73) Re: [IPv6Imp] Re: Ethernet Pr... Cc: dhaskin@BayNetworks.com, IPv6Imp@munnari.oz.au, ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Date: Fri, 12 May 1995 06:03:35 -0400 > From: Telford001@aol.com > Subject: Re: [IPv6Imp] Re: Ethernet Pr... > > Hi Dimitry, > > Couldn't you just give the IPv4 and IPv6 routing functionalities > separate MAC addresses? That is how I have typically > handled multiprotocol routers. > > Joachim Martillo Joachim, Thanks for advice, but this wouldn't solve my problem. Besides, I don't think we can/should require to use a separate MAC addresses for IPv4 and IPv6. Dimitry From owner-ipng@sunroof.Eng.Sun.COM Sat May 13 11:17:24 1995 Return-Path: Received: from sunroof2.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id LAA15095; Sat, 13 May 1995 11:17:20 -0700 Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03840; Sat, 13 May 95 11:26:08 PDT Date: Sat, 13 May 95 11:26:08 PDT Message-Id: <9505131826.AA03840@sunroof2.Eng.Sun.COM> To: owner-ipng@sunroof.Eng.Sun.COM From: owner-ipng@sunroof.Eng.Sun.COM Subject: BOUNCE ipng@sunroof.eng.sun.com: Non-member submission from [hmartillo@stealth.webo.dg.com (H. Martillo)] Content-Length: 3566 X-Lines: 75 Status: RO From hmartillo@stealth.webo.dg.com Sat May 13 11:25:56 1995 Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03834; Sat, 13 May 95 11:25:56 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05795; Sat, 13 May 1995 11:17:00 -0700 Received: from dg-webo.webo.dg.com (dg-webo.us.dg.com) by Sun.COM (sun-barr.Sun.COM) id AA22184; Sat, 13 May 95 11:16:56 PDT Received: from magellan by dg-webo.webo.dg.com (5.4R2.10/dg-webo-v1) id AA02331; Sat, 13 May 1995 14:15:29 -0400 Received: from stealth by magellan.webo.dg.com (5.4R2.01/dg-s01) id AA05079; Sat, 13 May 1995 14:15:27 -0400 Received: by stealth.webo.dg.com (5.4R3.10/dg-s01) id AA07715; Sat, 13 May 1995 14:15:25 -0400 Date: Sat, 13 May 1995 14:15:25 -0400 From: hmartillo@stealth.webo.dg.com (H. Martillo) Message-Id: <9505131815.AA07715@stealth.webo.dg.com> To: sthomas@mindspring.com (Stephen Thomas) Subject: Re: (IPng 56) Re: Re: Ethernet Pr... Cc: Telford001@aol.com, dhaskin@baynetworks.com, nordmark@jurassic-248.Eng.Sun.COM, ipng@sunroof.Eng.Sun.COM, cisco@spot.colorado.edu, Telford001@aol.com, martillo@thurifer.harvard.edu, hmartillo@stealth Hi Stephen, While I have little doubt that IPv6 should have its own Ethertype when carried over Ethernet, in the case described below as long as the end host puts the destination host MAC addresses in IPv6 frames but puts router functionality MAC address in the IPv4 frames, LSB architecture bridge routers (modulo a few configuration incantations) would simply route the IPv4 packets and bridge the IPv6 frames. Joachim Martillo Telford001@aol.com >At 10:21 AM 5/13/95 -0400, Telford001@aol.com wrote: >>>>I could be wrong, but I expect that the desire to route IPv4 and >>>>bridge IPv6 will be quite common in initial stages of the IPv6 deployment. >>>I also expect there to be such a desire, but I suspect that the desire >>>might be misguided. If you truly are transitioning from IPv4 to IPv6, then >>>you're likely to want to use the IPv4-compatible prefixes for your IPv6 >>>addresses. But, of course, if you're routing IPv4, the two segments will >>>have to be different subnets, and if you're bridging IPv6, you'll want them >>>to have the same prefix. Contradiction. >>I am a little baffled. All the bridge routers which I design have the >>ability >>to bridge and to route the same protocol at a given physical interface. >It's not a question of any bridge/router's capability. It is a question >of how you will assign IPv4 subnet and IPv6 prefix addresses. Start with >an all IPv4 internet: > +-----------------------+ >+------------------+ | IPv4 Router | +------------------+ >| Host A 194.3.2.1 | | 194.3.2.2 195.6.5.4 | | Host B 195.6.5.5 | >+------------------+ +-----------------------+ +------------------+ > \ / \ / > ============================= ========================= > 194.3.2.0 (0xffffff00) 195.6.5.0 (0xffffff00) >Now suppose you upgrade the hosts to IPv6, You'll probably want to assign >them IPv6 addresses ::194.3.2.1 and ::195.6.5.5. Now, suppose you give them >those assignments and tell the router to bridge IPv6. What network prefix >will you use for the bridged IPv6 subnet? >BTW, I don't think this is purely an implementation issue, but I will defer >to the collective wisdom if we want to move it there. >--Stephen ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 15 10:39:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04628; Mon, 15 May 95 10:39:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04622; Mon, 15 May 95 10:39:31 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00150; Mon, 15 May 1995 10:30:31 -0700 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA15745; Mon, 15 May 95 10:30:15 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/24Feb95) id AA06405; Mon, 15 May 95 10:25:35 -0700 Received: by xirtlu.zk3.dec.com; id AA09297; Mon, 15 May 1995 13:25:19 -0400 Message-Id: <9505151725.AA09297@xirtlu.zk3.dec.com> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 74) Re: Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Mon, 15 May 95 12:10:21 EDT." <9505151610.AA20774@BayNetworks.com> Date: Mon, 15 May 95 13:25:12 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Another data point "pro" a new ethertype is that some implementations may not even have an ipv4 stack at some point. But we still need the version field if we go this way. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 15 10:56:26 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04649; Mon, 15 May 95 10:56:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04640; Mon, 15 May 95 10:56:13 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03332; Mon, 15 May 1995 10:47:13 -0700 Received: from lobster.wellfleet.com by venus.Sun.COM (Sun.COM) id KAA06703; Mon, 15 May 1995 10:47:10 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA29157; Mon, 15 May 95 13:44:25 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA24708; Mon, 15 May 95 13:49:11 EDT Date: Mon, 15 May 95 13:49:11 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505151749.AA24708@BayNetworks.com> To: bound@zk3.dec.com Subject: (IPng 75) Re: Re: Re: Re: Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM, dhaskin@BayNetworks.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Subject: (IPng 69) Re: Re: Re: Re: Ethernet Protocol Type for IPv6 > Date: Mon, 15 May 95 11:09:37 -0400 > From: bound@zk3.dec.com > > The demux is pretty simple for version IPv6 and causes no pain on a Host > implementation I am aware of at this time. So that is a "present" data > point. I am running a dual network layer too and it works fine. > > My concern with a new ether-type is three fold: > > 1. We have not really created a new type its still the Internet > protocol. I disagree here. > Does IPv5 have its own ether-type? Besides we are running > ATM using IPv5 and demux on version now so that link type works (this is > AD work not product work). There were an agreement between the IPv5 suppliers (BBN, Wellfleet) to support an unique EtherType (0x5354) for IPv5. The agreement was the result of a bad deployment experience. A number of IPv4 routers (not our) and other network devices failed when ST-2 packets showed up since they didn't check the version of IP header. Some vendors might have fixed the problem since but some might heve not. Besides, it is often quite difficult for some users to upgrade their legacy systems. > > 2. A new ether-type at the datalink will cause more code changes > on a host when the present demux works fine. What benefit do I get? > I can't see one? The down side is now I need to make sure I use the new > ether-type for IPv6 at the datalink. > Well.. pride of being a good citizen and striving for the common good! Yes, of cause, if it doesn't cost you too much :) > 3. Demux on version number will still be required for non ether-type > connections. > No, it will not. The only encapsulation which will need a new protocol type assigment for IPv6 is PPP. All other link encapsulations (including IP-over-ATM and IP-over-FR) that I've come with can demux on the Xerox assigned EtherType using SNAP protocol format. BTW, PPP has already assigned an unique protocol type for IPv5: 0x0033. > Can we focus this issue that it is a router implementation issue only? > It isn't a router implementation issue only. > > /jim Regards, Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 15 11:32:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04770; Mon, 15 May 95 11:32:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04764; Mon, 15 May 95 11:32:18 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10237; Mon, 15 May 1995 11:23:19 -0700 Received: from wintermute.imsi.com by venus.Sun.COM (Sun.COM) id LAA10943; Mon, 15 May 1995 11:23:18 -0700 Received: from relay.imsi.com by wintermute.imsi.com id OAA06309; Mon, 15 May 1995 14:21:58 -0400 Received: from snark.imsi.com by relay.imsi.com id OAA28885; Mon, 15 May 1995 14:21:58 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA15628; Mon, 15 May 95 14:21:57 EDT Message-Id: <9505151821.AA15628@snark.imsi.com> To: dhaskin@BayNetworks.com (Dimitry Haskin) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 76) Re: Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Mon, 15 May 1995 12:10:21 EDT." <9505151610.AA20774@BayNetworks.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 15 May 1995 14:21:56 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Dimitry Haskin says: > I failed to point it in my previous mail, but it is not just making > the decision a few instructions later. If EtherType of IPv6 stays as > it is now, popular IPv4 routers will not bridge IPv6 if they're not upgraded > to do so -- they just drop IPv6 packets as having an invalid IP version. I'll point out that without major software upgrades they won't route IPv6 at all no matter what you do, and if you don't have at least some things that can route it you aren't going to have much use out of IPv6. Moreover, my clients are already quite used to having to upgrade their router software every six months or year -- this will not kill them. Again, I'm quite worried about what dependency on a typing mechanism available only one one lower layer would do to the flexibility of implementations in dealing with a very wide array of lower layers. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 15 11:37:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04794; Mon, 15 May 95 11:37:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04788; Mon, 15 May 95 11:36:56 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10969; Mon, 15 May 1995 11:27:58 -0700 Received: from dxmint.cern.ch by venus.Sun.COM (Sun.COM) id LAA11800; Mon, 15 May 1995 11:27:58 -0700 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA09144; Mon, 15 May 1995 20:26:41 +0200 Received: by dxcoms.cern.ch id AA05518; Mon, 15 May 1995 20:26:39 +0200 Message-Id: <9505151826.AA05518@dxcoms.cern.ch> Subject: (IPng 77) Re: Re: Re: Ethernet Protocol Type for IPv6 To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Date: Mon, 15 May 1995 20:26:39 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <9505151610.AA20774@BayNetworks.com> from "Dimitry Haskin" at May 15, 95 12:10:21 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 Dimitry, > I failed to point it in my previous mail, but it is not just making > the decision a few instructions later. If EtherType of IPv6 stays as > it is now, popular IPv4 routers will not bridge IPv6 if they're not upgraded > to do so -- they just drop IPv6 packets as having an invalid IP version. > I contend that our deployment story will be much stronger if no upgrade > is required to the already installed IPv4 router/bridges in order for them to > bridge IPv6. > That's a key point. IPv6 hosts on a network served by unmodified brouters can communicate if and only if they use a new Ethertype. BTW Ethertype is not only used on Ethernet. With LLC 1, SNAP, OUI=0 it is also used on FDDI (and 802.5 I think) and on ATM under RFC1577. I think we need a new Ethertype as a SHOULD and the old one as a MAY. Thanks Dimitry. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 15 12:21:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04894; Mon, 15 May 95 12:21:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04888; Mon, 15 May 95 12:21:12 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17346; Mon, 15 May 1995 12:12:15 -0700 Received: from nsco.network.com by venus.Sun.COM (Sun.COM) id MAA20058; Mon, 15 May 1995 12:12:08 -0700 Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA21956; Mon, 15 May 95 14:28:41 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA25225; Mon, 15 May 95 14:09:53 CDT Date: Mon, 15 May 95 14:09:53 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9505151909.AA25225@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 78) Re: Re: Re: Re: Ethernet Protocol Type for IPv6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk From the point of view of elegance, I move that the demux be done either at the MAC/LLC layer or at the IP layer, but please let's not do both? The current encapsulation zoo we're suffering with now does not need to be made worse by allowing two different ethertypes for IPv6, and in one case it could be IPv6 or IPv4 but in the other it's only IPv6. Ow, ow, ow. I can think of good arguments for either side, but let's not turn ourselves into ISO and solve the problem by simply hammering all possible answers into a set of giant documents. Pick one and go with it. Andrew not speaking for NSC and so on ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 15 12:46:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04931; Mon, 15 May 95 12:46:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04925; Mon, 15 May 95 12:46:45 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20157; Mon, 15 May 1995 12:37:44 -0700 Received: from venera.isi.edu by venus.Sun.COM (Sun.COM) id MAA24360; Mon, 15 May 1995 12:37:44 -0700 From: bmanning@ISI.EDU Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 12:36:27 -0700 Posted-Date: Mon, 15 May 1995 12:33:19 -0700 (PDT) Message-Id: <199505151933.AA09460@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Mon, 15 May 1995 12:33:20 -0700 Subject: (IPng 79) Re: Re: Re: Re: Ethernet Protocol Type for IPv6 To: perry@imsi.com Date: Mon, 15 May 1995 12:33:19 -0700 (PDT) Cc: dhaskin@baynetworks.com, ipng@sunroof.Eng.Sun.COM In-Reply-To: <9505151821.AA15628@snark.imsi.com> from "Perry E. Metzger" at May 15, 95 02:21:56 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 Would it be appropriate to try and set up an IDRP structure so that we can really test routing of IPv6 packets w/o tunneling? -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 15 13:14:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05016; Mon, 15 May 95 13:14:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05010; Mon, 15 May 95 13:14:14 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23158; Mon, 15 May 1995 13:05:17 -0700 Received: from mail1.digital.com by venus.Sun.COM (Sun.COM) id NAA28629; Mon, 15 May 1995 13:05:16 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA28488; Mon, 15 May 1995 13:02:31 -0700 Received: by xirtlu.zk3.dec.com; id AA13015; Mon, 15 May 1995 15:58:56 -0400 Message-Id: <9505151958.AA13015@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 80) Re: Re: Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Mon, 15 May 95 20:26:39 +0200." <9505151826.AA05518@dxcoms.cern.ch> Date: Mon, 15 May 95 15:58:50 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Can't find to much cost at all to change the datalink code per Dimitrys need of an ethertype. We still need the version number in the packet. But I support Dimitry for a new ethertype. I think Brian's words of SHOULD and MAY are important and a good idea too. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 15 13:21:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05040; Mon, 15 May 95 13:21:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05034; Mon, 15 May 95 13:21:36 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23987; Mon, 15 May 1995 13:12:39 -0700 Received: from mail1.digital.com by venus.Sun.COM (Sun.COM) id NAA29801; Mon, 15 May 1995 13:12:38 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA22948; Mon, 15 May 1995 13:07:50 -0700 Received: by xirtlu.zk3.dec.com; id AA13167; Mon, 15 May 1995 16:04:14 -0400 Message-Id: <9505152004.AA13167@xirtlu.zk3.dec.com> To: bmanning@ISI.EDU Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 81) Re: Re: Re: Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Mon, 15 May 95 12:33:19 PDT." <199505151933.AA09460@zed.isi.edu> Date: Mon, 15 May 95 16:04:08 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >Would it be appropriate to try and set up an IDRP structure so that >we can really test routing of IPv6 packets w/o tunneling? Yes. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 15 13:55:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05124; Mon, 15 May 95 13:55:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05118; Mon, 15 May 95 13:55:04 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28943; Mon, 15 May 1995 13:46:04 -0700 Received: from thumper.bellcore.com by venus.Sun.COM (Sun.COM) id NAA05444; Mon, 15 May 1995 13:46:02 -0700 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id QAA13546; Mon, 15 May 1995 16:42:03 -0400 Message-Id: <199505152042.QAA13546@thumper.bellcore.com> To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, gja@thumper.bellcore.com Subject: (IPng 82) Re: Re: Re: Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of Mon, 15 May 1995 15:58:50 -0400. <9505151958.AA13015@xirtlu.zk3.dec.com> Date: Mon, 15 May 1995 16:41:56 -0400 From: Grenville Armitage Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >>Can't find to much cost at all to change the datalink code per Dimitrys >>need of an ethertype. >> >>We still need the version number in the packet. Why? If we're going to allocate a new link layer codepoint for IPv6, then lets not waste time pretending there's a (de)mux code point in the IP header. Just set the version bits to zero, for IPv6 and any other variants of IP. Basically it boils down to bridge/routers that perform only per-protocol bridging/routing rather than per-protocolversion. If we're going to work around them (rather than call them broken) then lets NOT have two ways of (de)muxing IPv6 and IPv4 traffic on the same wire (new Ethertype or 0x800+version). (Poses an interesting side question - when is a version not a version, but a new protocol?) cheers, gja ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 15 19:28:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05303; Mon, 15 May 95 19:28:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05297; Mon, 15 May 95 19:28:37 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13762; Mon, 15 May 1995 19:19:39 -0700 Received: from dylan.mindspring.com by venus.Sun.COM (Sun.COM) id TAA21170; Mon, 15 May 1995 19:19:36 -0700 Received: from sthomas.mindspring.com [168.121.37.118] by dylan.mindspring.com with SMTP id WAA07115 for ; Mon, 15 May 1995 22:18:15 -0400 Message-Id: <199505160218.WAA07115@dylan.mindspring.com> X-Sender: sthomas@mindspring.com (Unverified) X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 May 1995 22:13:47 -0400 To: ipng@sunroof.Eng.Sun.COM From: sthomas@mindspring.com (Stephen Thomas) Subject: (IPng 83) OSPF for IPv6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Can anyone comment on the status of OSPF for IPv6? I realize it's not on the fast track yet, but I am trying to work out some implementation-level details of the protocol. I could be wrong, but it seems as if there are a few holes in the last draft. (I've tried contacting Fred and Rob, the authors of that draft, but so far without success.) I think they're mostly minor things that a quick update could correct. I'd be happy to help out if it can progress the draft. --Stephen For the curious, here's what seems to be missing from the draft: o support for multicast groups (type 22 LSAs?) o support for the NSSA option (type 23 LSAs?) o many fields that seemingly should expand to 16 bytes are omitted from the list of fields that change: generic header: Router ID hello packet: Designated Router, Backup DR, Neighbor type 18 LSA: Attached Router type 21 LSA: Forwarding Address type 22(?) LSA: Vertex ID type 23(?) LSA: Forwarding Address o the particular bit of the Options field which designates IPv6 support o how to handle the Link Data field of the router LSA (In IPv4, it's sometimes a netmask, sometimes an interface number, and sometimes an IP address.) ______________________________ Stephen A. Thomas 4397 Windsor Oaks Circle Marietta, GA 30066-2387 E-mail: sthomas@mindspring.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 02:05:18 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05509; Tue, 16 May 95 02:05:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05503; Tue, 16 May 95 02:05:10 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00085; Tue, 16 May 1995 01:56:13 -0700 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA06838; Tue, 16 May 95 01:56:11 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04140; Tue, 16 May 1995 18:47:52 +1000 (from kre@munnari.OZ.AU) To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 84) Re: Re: Re: Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Mon, 15 May 1995 15:58:50 -0400." <9505151958.AA13015@xirtlu.zk3.dec.com> Date: Tue, 16 May 1995 18:47:20 +1000 Message-Id: <7245.800614040@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Mon, 15 May 95 15:58:50 -0400 From: bound@zk3.dec.com Message-ID: <9505151958.AA13015@xirtlu.zk3.dec.com> We still need the version number in the packet. Well, maybe, if the ethertype is changed (recognising that IPv6, which would no longer be IPv6 but something entirely different, is not just IPv4 with a few mods) then we should probably reconsider the need for a version field. If it has proved useless for IPv4, is it likely to be any better for IPv6, especially has IPv6 has less fields in its header that are susceptible to minor changes in meaning. It could be that the 4 bits may be better devoted to making the flow id be a full 32 bits. I think Brian's words of SHOULD and MAY are important and a good idea too. Frankly, this is positively insane. Either IPv6 is a variation of IPv4, and shares the same ethernet type, with demux early in the IP processing, or its new, and is demuxed at the ethernet (and other) layers. Having it both ways is just idiocy. If we were to allow this, we'd also need some kind of negotiation or rules to figure out when you might want to send one, and when the other. Really! kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 03:47:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05542; Tue, 16 May 95 03:47:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05536; Tue, 16 May 95 03:47:10 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03896; Tue, 16 May 1995 03:38:12 -0700 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA21852; Tue, 16 May 95 03:38:13 PDT Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14493(1)>; Tue, 16 May 1995 03:38:08 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 16 May 1995 03:38:03 -0700 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: (IPng 85) Re: Re: Re: Re: Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: kre's message of Tue, 16 May 95 01:47:20 -0800. <7245.800614040@munnari.OZ.AU> Date: Tue, 16 May 1995 03:37:51 PDT From: Steve Deering Message-Id: <95May16.033803pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I am typing this over a VERY flaky link from JENC Israel, so can't say much (3 minute character-echo times!). There was an ethertype assigned to original SIP, so no need tfor anyone to get another one. Please hold off on deciding this issue till I get back (May 20). Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 05:00:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05571; Tue, 16 May 95 05:00:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05565; Tue, 16 May 95 05:00:35 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07198; Tue, 16 May 1995 04:51:38 -0700 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA26862; Tue, 16 May 95 04:51:36 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch id AA25190; Tue, 16 May 1995 13:51:32 +0200 Received: by dxcoms.cern.ch id AA06680; Tue, 16 May 1995 13:51:29 +0200 Message-Id: <9505161151.AA06680@dxcoms.cern.ch> Subject: (IPng 86) Re: Ethernet Protocol Type for IPv6 To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Date: Tue, 16 May 1995 13:51:29 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <7245.800614040@munnari.OZ.AU> from "Robert Elz" at May 16, 95 06:47:20 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 Robert, > > I think Brian's words of > SHOULD and MAY are important and a good idea too. > > Frankly, this is positively insane. Either IPv6 is a variation > of IPv4, and shares the same ethernet type, with demux early > in the IP processing, or its new, and is demuxed at the ethernet > (and other) layers. Having it both ways is just idiocy. So how do you respond to this: >> IPv6 hosts on a network served by unmodified >> brouters can communicate if and only if they use a new Ethertype. without destroying the elegance of sharing the Ethertype in the cleaner situation of IPv6-aware routers? > > If we were to allow this, we'd also need some kind of negotiation > or rules to figure out when you might want to send one, and when > the other. Really! Of course. IPv6 nodes on Ethernet or any other link using the Ethertype field MUST set Ethertype = 0800 or Ethertype = . They SHOULD set Ethertype = 0800 but they MAY be configured to set Ethertype = if necessary due to local requirements. IPv6 nodes on Ethernet or any other link using the Ethertype field MUST accept and process incoming IPv6 packets with either Ethertype = 0800 or Ethertype = . Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 05:22:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05591; Tue, 16 May 95 05:22:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05585; Tue, 16 May 95 05:22:06 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08372; Tue, 16 May 1995 05:13:08 -0700 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA28708; Tue, 16 May 95 05:13:08 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11582; Tue, 16 May 1995 22:12:32 +1000 (from kre@munnari.OZ.AU) To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 87) Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Tue, 16 May 1995 13:51:29 +0200." <9505161151.AA06680@dxcoms.cern.ch> Date: Tue, 16 May 1995 22:12:00 +1000 Message-Id: <7309.800626320@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Tue, 16 May 1995 13:51:29 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Message-ID: <9505161151.AA06680@dxcoms.cern.ch> So how do you respond to this: >> IPv6 hosts on a network served by unmodified >> brouters can communicate if and only if they use a new Ethertype. Personally, I believe the arguments relating to addressing integrity (though I can also see potential ways around the problems) and believe that, new ethertype or not, the very last thing that you want to do is have IPv6 being bridged over the same links that you have IPv4 running. I'm afraid that LANs deploying IPv6 are going to need to use the same techniques as are used on WANs etc, and trivial bridging is not going to be the answer. without destroying the elegance of sharing the Ethertype in the cleaner situation of IPv6-aware routers? What elegance? Elegance wass never the reason - if a new ethertype is used, we simply use it. There is no good reason at all to make this an option - its not as if we have some large fraction of the world deployed with IPv6, and we have just discovered this flaw, need to change ethertypes, but want to remain compatible with what is deployed. One way or the other, please! kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 05:22:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05603; Tue, 16 May 95 05:22:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05597; Tue, 16 May 95 05:22:39 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08397; Tue, 16 May 1995 05:13:41 -0700 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA28737; Tue, 16 May 95 05:13:33 PDT Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Tue, 16 May 1995 21:11:03 +0900 From: Masataka Ohta Message-Id: <199505161211.VAA05767@necom830.cc.titech.ac.jp> Subject: (IPng 88) Re: Re: Ethernet Protocol Type for IPv6 To: ipng@sunroof.Eng.Sun.COM Date: Tue, 16 May 95 21:11:02 JST X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk As for the packet format other than the version field, RFC 1190 says: The ST packet header is not constrained to be compatible with the IP packet header, except for the IP Version Number (the first four bits) that is used to distinguish ST packets (IP Version 5) from IP packets (IP Version 4). Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 05:42:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05628; Tue, 16 May 95 05:42:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05621; Tue, 16 May 95 05:42:26 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10414; Tue, 16 May 1995 05:33:26 -0700 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA01728; Tue, 16 May 95 05:33:24 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch id AA21396; Tue, 16 May 1995 14:33:14 +0200 Received: by dxcoms.cern.ch id AA07861; Tue, 16 May 1995 14:33:12 +0200 Message-Id: <9505161233.AA07861@dxcoms.cern.ch> Subject: (IPng 89) Re: Re: Ethernet Protocol Type for IPv6 To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Date: Tue, 16 May 1995 14:33:11 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <7309.800626320@munnari.OZ.AU> from "Robert Elz" at May 16, 95 10:12:00 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 Robert, > > So how do you respond to this: > >> IPv6 hosts on a network served by unmodified > >> brouters can communicate if and only if they use a new Ethertype. > > Personally, I believe the arguments relating to addressing > integrity (though I can also see potential ways around the > problems) and believe that, new ethertype or not, the very > last thing that you want to do is have IPv6 being bridged > over the same links that you have IPv4 running. It may be the last thing you want, but on some sites it will be the first thing you get, I think. > I'm afraid > that LANs deploying IPv6 are going to need to use the same > techniques as are used on WANs etc, and trivial bridging is > not going to be the answer. During initial tests and pilot projects it may well have to be the answer in some places. > > without destroying the elegance of sharing the Ethertype in > the cleaner situation of IPv6-aware routers? > > What elegance? Elegance wass never the reason - if a new > ethertype is used, we simply use it. There is no good reason > at all to make this an option - its not as if we have some > large fraction of the world deployed with IPv6, and we have > just discovered this flaw, need to change ethertypes, but want > to remain compatible with what is deployed. I think it is more elegant to demux using the IP version #. So I chose the word elegance carefully. > > One way or the other, please! > If that is the consensus it will have to be a separate Ethertype. Brian P.S. Majordomo in its new configuration seems to interact with some mailers to create the most ridiculous Xmas trees of Re: (IPng 999) Re: Re: Re..... headers. Is this fixable? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 06:05:32 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05693; Tue, 16 May 95 06:05:32 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05681; Tue, 16 May 95 06:05:22 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11438; Tue, 16 May 1995 05:56:24 -0700 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA04967; Tue, 16 May 95 05:56:16 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13670; Tue, 16 May 1995 22:54:52 +1000 (from kre@munnari.OZ.AU) To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 90) Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Tue, 16 May 1995 14:33:11 +0200." <9505161233.AA07861@dxcoms.cern.ch> Date: Tue, 16 May 1995 22:51:47 +1000 Message-Id: <7334.800628707@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Tue, 16 May 1995 14:33:11 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Message-ID: <9505161233.AA07861@dxcoms.cern.ch> It may be the last thing you want, but on some sites it will be the first thing you get, I think. But I don't think it will, or can, work - or not an interact properly with orderly transition using the compatible IPv4 address space 0::1.2.3.4 - environments with some IPv4 only routers (which will be all of them initially) will need to use tunelling I believe - isn't this what ngtrans is dealing with? (I haven't been following that very closely). I think it is more elegant to demux using the IP version #. Huh? Isn't this presuming the answer to the question of whether IPv6 is a revision of IPv4 or a completely different protocol? Surely if you view IPv6 as a different protocol (as many have said) then it is more elegant to demux based on the ethertype. (Would it be more elegant to demux IPv4 & IPX based on the first 4 bits of the packets?) On the other hand, if you view them as the same protocol, modified, then using the version field seems cleaner. Elegance of itself is no criterion at all. If that is the consensus it will have to be a separate Ethertype. Perhaps - though I would suggest that for now we just wait a week on this, let Steve get back, digest all this mail in some comfort, and give us his throughts. One week shouldn't hurt anyone... P.S. Majordomo in its new configuration seems to interact with some mailers to create the most ridiculous Xmas trees of Re: (IPng 999) Re: Re: Re..... headers. Is this fixable? Perhaps I have said enough about majordomo... I will just say that the IPv6Imp list doesn't have that problem (or not as long as mailers stick to the usual "re:" and don't start using "wrt:" or other unusual strings). For now I will just try to edit away extraneous "Re:"s. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 06:09:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05717; Tue, 16 May 95 06:09:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05711; Tue, 16 May 95 06:09:09 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11587; Tue, 16 May 1995 06:00:11 -0700 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA05355; Tue, 16 May 95 06:00:02 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch id AA08426; Tue, 16 May 1995 14:59:59 +0200 Received: by dxcoms.cern.ch id AA14035; Tue, 16 May 1995 14:59:56 +0200 Message-Id: <9505161259.AA14035@dxcoms.cern.ch> Subject: (IPng 91) Re: Re: Ethernet Protocol Type for IPv6 To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Date: Tue, 16 May 1995 14:59:56 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: from "Louis A. Mamakos" at May 16, 95 08:37:04 am 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 Louis, > Having seen and experienced what happened in the Novell world with (at > the time 2) encapsulations and now 3 on Ethernets, we paid over and > over for this kind of foolishness. Remember Berkeley "trailers" > encapsualtion on Ethernets? It took years to stomp that out, even > after adding negotiation cruft to ARP. and Appletalk over FDDI... horrors, I agree > > Sure, we got really good at diagnosing these problems. We don't need > to relive this, agin. true > > Please do not add gratutitous degrees of freedom to the configuration > of an IPv6 host. It ought to be possible to pick one answer. While > there is a certain elegance in using 0x800, I'd much prefer a > different ethernet type field as an alternative to *two* of them. > I concede and agree. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 06:34:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05745; Tue, 16 May 95 06:34:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05739; Tue, 16 May 95 06:33:52 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12695; Tue, 16 May 1995 06:24:54 -0700 Received: from bastion.sware.com by Sun.COM (sun-barr.Sun.COM) id AA08406; Tue, 16 May 95 06:24:51 PDT Received: from shlep.sware.com (shlep.sware.com [139.131.1.14]) by bastion.sware.com (8.6.5/8.6.5) with SMTP id JAA01929; Tue, 16 May 1995 09:24:14 -0400 Received: by shlep.sware.com (5.65/2.0) from wanda.sware.com id AA02517; Tue, 16 May 95 09:24:28 -0400 Received: by wanda.sware.com.sware.com (1.38.193.4/2.0) id AA24450; Tue, 16 May 1995 09:25:30 -0400 Date: Tue, 16 May 1995 09:25:30 -0400 From: Ed Sale Message-Id: <9505161325.AA24450@wanda.sware.com.sware.com> To: dhaskin@BayNetworks.com Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 92) Re: Ethernet Protocol Type for IPv6 Reply-To: sale@sware.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Dimitry Haskin writes: | Among the reasons for using an unique EtherType for ST2 were: | | - improved performance since no extra level of demultiplexing. | - there were a number of legacy systems (and I'm confident still | are ;\ ) that handled only IPv4 and did not check the version of | IP header (e.g. Motorola's security encapsulation device (NES)). | Such systems crashed when ST2 packets showed up. Dimitry, The sky is not falling. The "legacy systems" that do not check the IP header type that receive an IPv6 packet will *probably* check the IPv4 header checksum, which is almost guaranteed to fail, since IPv6 does not have one -- it has part of the source address where the IPv4 checksum resides. If they do not, let them crash and burn. The "improved performance" is not *that* big a win. in another message: | Now, what if a router/bridge is configured to route IPv4 packets but | IPv6 packets need to be bridged? If IPv4 and IPv6 had different | EtherTypes, IPv6 packet could be very efficiently bridged since | there would be no registration for IPv6 EtherType. If IPv4 and IPv6 | use the same EtherType... you see the picture! As KRE has pointed out, it will not be a good idea to try to bridge IPv6 while routing IPv4. Users will need to either bridge them both or buy (or upgrade to) routers that can route them both. I think IPv6 is really IPng not a completely different protocol. It is tied to IPv4 in numerous ways: upper level protocols, shared address space, etc. Let's leave the Ethertype alone and move on to more important topics. -- Ed P.S. The best argument I've heard so far in favor of a new Ethertype is that we could make the Flow ID field 32 bits by removing the Version field. :-) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 07:57:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05799; Tue, 16 May 95 07:57:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05793; Tue, 16 May 95 07:56:49 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19018; Tue, 16 May 1995 07:47:49 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA20074; Tue, 16 May 95 07:47:50 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA18544; Tue, 16 May 95 10:46:21 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA03391; Tue, 16 May 95 10:51:07 EDT Date: Tue, 16 May 95 10:51:07 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505161451.AA03391@BayNetworks.com> To: kre@munnari.OZ.AU Subject: (IPng 93) Re: Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Subject: (IPng 90) Re: Ethernet Protocol Type for IPv6 > Date: Tue, 16 May 1995 22:51:47 +1000 > From: Robert Elz > Sender: owner-ipv6@marvin > Content-Length: 2253 > > Date: Tue, 16 May 1995 14:33:11 +0200 (MET DST) > From: "Brian Carpenter CERN-CN" > Message-ID: <9505161233.AA07861@dxcoms.cern.ch> > > It may be the last thing you want, but on some sites it > will be the first thing you get, I think. > > But I don't think it will, or can, work - or not an interact > properly with orderly transition using the compatible IPv4 > address space 0::1.2.3.4 - environments with some IPv4 only > routers (which will be all of them initially) will need to > use tunelling I believe - isn't this what ngtrans is dealing > with? (I haven't been following that very closely). Robert, I have been following ngtrans closely and I can say the IPv6 bridging will work with the IPng transition all right. And, IMO, the transition in many cases will be more orderly if IPv6 bridging can be accomplished without upgrading IPv4 brouters. In a large corparate network interconnected with a large number of legacy IPv4 brouters to get started with IPv6 all that will be needed is to install one or two IPv6 routers in order to support IPv6 hosts that can be hooked up at any point of the network. Such IPv6 hosts need to be assigned IPv6 addresses (IPv4-compartable or not) with prefixes given to the IPv6 routers regardless of addresses of IPv4 routers. That's all. I completely agree with you that multiple demux options are silly. A separate ethertype will do. Regards, Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 08:09:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05814; Tue, 16 May 95 08:09:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05808; Tue, 16 May 95 08:09:17 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20387; Tue, 16 May 1995 08:00:17 -0700 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA22063; Tue, 16 May 95 08:00:07 PDT Received: by rodan.UU.NET id QQypzg11490; Tue, 16 May 1995 11:00:07 -0400 Message-Id: To: ipng@sunroof.Eng.Sun.COM Cc: mo@uunet.uu.net Subject: (IPng 94) 2 shelves where none are needed...... Date: Tue, 16 May 1995 11:00:06 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Ahem.... How is it that this august group has suddenly all gone wacko???? Is there a solar flair? Bad Winds? Latent Danvers Syndrome???? Sap's risin' and the brain's disconnectin'???? We know from astoundingly painful experience that having TWO ways to do something fundamental like Ethernet encapsulation simply means that half of the time it is wrong. Anyone remember Berkeley TRAILERS and how much grief they have caused? options on ifconfig - get it wrong and it just won't work and it's a nightmare to debug? then someone had the bright idea of *negotiating* with ARP?? boy, that sure fixed it right up, yessiree. Only after banishing trailers has it become possible to config a Unix box without manual intervention. sheesh! And anyone remember IPX and how much fun you had, watching the networks progress through the stages of pseudo 802.3 minus 802.2, then Ethernet-II, and now 802.3 WITH 802.2? and of course, drivers that must do 2 or all 3 and have wonderfully subtle bugs because of them? So can someone explain WHY ON EARTH some people seem interested in resurrecting these plagues??? For heavens sakes, folks, get a grip here and learn from the past horrors. The world is already oversupplied with FLAT TIRES. STOP NOW. THE LIFE YOU SAVE COULD BE YOUR OWN. yours for more compelling screeds, -Mike O'Dell ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 08:36:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05832; Tue, 16 May 95 08:36:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05826; Tue, 16 May 95 08:36:25 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22717; Tue, 16 May 1995 08:27:26 -0700 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA26762; Tue, 16 May 95 08:27:27 PDT Received: from relay.imsi.com by wintermute.imsi.com id LAA11665; Tue, 16 May 1995 11:25:46 -0400 Received: from snark.imsi.com by relay.imsi.com id LAA17605; Tue, 16 May 1995 11:25:45 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA17042; Tue, 16 May 95 11:25:44 EDT Message-Id: <9505161525.AA17042@snark.imsi.com> To: "Mike O'Dell" Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 95) Re: 2 shelves where none are needed...... In-Reply-To: Your message of "Tue, 16 May 1995 11:00:06 EDT." Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 16 May 1995 11:25:43 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk "Mike O'Dell" says: > We know from astoundingly painful experience that having TWO ways to > do something fundamental like Ethernet encapsulation simply means > that half of the time it is wrong. I second Mr. O'Dell's double-plus-cohegent(*) remarks. I think that having a second ethernet type is a bad idea, but doing it both ways is like hanging up a big sign that say "please shoot us all in the head now". Perry (*) double-plus-cohegent isn't a real word, but I like it anyway. Its a combination of double plus, coherent, and cogent. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 08:55:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05866; Tue, 16 May 95 08:55:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05860; Tue, 16 May 95 08:55:36 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24734; Tue, 16 May 1995 08:46:37 -0700 Received: from itd.nrl.navy.mil (itd-fddi.nrl.navy.mil) by Sun.COM (sun-barr.Sun.COM) id AA00429; Tue, 16 May 95 08:46:39 PDT Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA26681; Tue, 16 May 95 11:46:37 EDT Date: Tue, 16 May 95 11:46:37 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9505161546.AA26681@itd.nrl.navy.mil> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 96) ICMPv6 & Port Unreachables Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Folks, At present "ICMP Port Unreachable" messages don't identify the port number that was unreachable as part of the ICMP message (but the information IS available if it fits within the "as much of invoking packet as will fit within 576" rule). In IPv4, the size of the options field was limited. In IPv6 we can potentially have LOTS of daisy-chained headers between the base header and the final payload. I'm concerned that the information needed to discern which port is affected might not always be available to the recipient of the ICMP message. Port Unreachable messages would be more useful if the port number were always present in such ICMP messages. There is a lurking security issue here that I'm reluctant to discuss in gory detail on a public mailing list because it can take out most extant IPv4 systems. Another issue is use of ICMP Port Unreachable messages to mount a denial-of-service attack on secured packets by forcing an early re-key exchange when one wasn't needed (rekeying might be relatively more expensive). My suspicion is that things would be improved by ensuring that port numbers were always available when a system received an ICMP Port Unreachable message. What do folks think about devoting part of the "Unused" 32-bits for the port number and upper-layer protocol (TCP, UDP, whatever) number for the case of ICMP Port Unreachable messages ? It might be the case that this isn't a sensible idea, but I thought it was worth mentioning just in case it is sensible. Ran atkinson@itd.nrl.navy.mil (old, but forwards) rja@cs.nrl.navy.mil (new) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 09:55:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05921; Tue, 16 May 95 09:55:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05915; Tue, 16 May 95 09:55:40 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02448; Tue, 16 May 1995 09:46:41 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA12050; Tue, 16 May 95 09:46:39 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA22557; Tue, 16 May 95 12:45:09 EDT Received: from cabernet.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA08439; Tue, 16 May 95 12:49:56 EDT Date: Tue, 16 May 95 12:49:56 EDT From: rcallon@BayNetworks.com (Ross Callon) Message-Id: <9505161649.AA08439@BayNetworks.com> To: kre@munnari.OZ.AU, dhaskin@BayNetworks.com Subject: (IPng 97) Re: Re: Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > I have been following ngtrans closely and I can say the IPv6 bridging > will work with the IPng transition all right. And, IMO, the transition > in many cases will be more orderly if IPv6 bridging can be accomplished > without upgrading IPv4 brouters. In a large corparate network interconnected > with a large number of legacy IPv4 brouters to get started with IPv6 all > that will be needed is to install one or two IPv6 routers in order to > support IPv6 hosts that can be hooked up at any point of the network. > Such IPv6 hosts need to be assigned IPv6 addresses (IPv4-compartable or not) > with prefixes given to the IPv6 routers regardless of addresses of IPv4 > routers. That's all. To make sure that I understand this fully, let's consider the following example: link to dual (v4 and v6) Internet | | +------+-------+ | Dual IP/IPv6 | | router | +------+-------+ | --------+-----+-------------------------+------ | | +-----+-------+ +-------+-----+ | IP router | | IP router | | else bridge | | else bridge | +-----+-------+ +-------+-----+ | | --------+-----------+-- --+--------+------------- | | +-+----------+-+ | IP router | | else bridge | +-------+------+ | ---------+-----+-------------- | +-----+-----+ | dual-host | +-----------+ If we use a separate Ethertype, then the devices which are routers for IP but bridges otherwise will treat IPv6 as something that is bridged, and thus the dual host will find that there is an IPv6- capable router directly attached. Thus the dual host will be able to communicate directly with both IPv6 and IPv4 capable routers. This implies that the dual host can use any type of v6 address, and can run native v6 end-to-end (as well as native v4). If we use the same Ethertype, then v6 will not be bridged via the IProuter/else bridge devices. This implies that the dual host in order to run IPv6 will need to either (i) use an IPv4-compatible v6 address combined with automatic tunneling; or (ii) have a manually configured point to point tunnel between itself and the dual router. Thus the transition scheme will deal with either choice. However, if we use a separate Ethertype then a bit more flexibility will be obtained in the transition. > I completely agree with you that multiple demux options are silly. > A separate ethertype will do. Yes absolutely, we should pick one of the two choices. Ross ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 09:58:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05933; Tue, 16 May 95 09:58:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05275; Mon, 15 May 95 18:21:11 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09599; Mon, 15 May 1995 18:12:13 -0700 Received: from mentat.com by venus.Sun.COM (Sun.COM) id SAA14341; Mon, 15 May 1995 18:12:08 -0700 Received: from leo.mentat.com ([192.88.122.132]) by mentat.com (4.1/SMI-4.1) id AA25239; Mon, 15 May 95 18:09:33 PDT Received: from feller.mentat.com by leo.mentat.com (4.1/SMI-4.1) id AA02794; Mon, 15 May 95 18:09:31 PDT Received: by feller.mentat.com (5.x/SMI-SVR4) id AA06411; Mon, 15 May 1995 18:10:06 -0700 Date: Mon, 15 May 1995 18:10:06 -0700 From: tim@mentat.com (Tim Hartrick) Message-Id: <9505160110.AA06411@feller.mentat.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 98) Re: Ethernet Protocol Type for IPv6 X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I would like to voice a couple of opinions in this debate which are shared by other folks here at Mentat. 1) We need the new Ethertype. Others have voiced a number of concerns with regard to legacy hardware. We want a stable and easy trans- ition. I believe this is one of the fundamental goals of IPv6. Requiring users to upgrade every "broken" piece of IPv4 hardware and software on their network simply because they introduced IPv6 traffic on to the network is neither stable nor easy. I will add one more very small log to the legacy hardware bond fire. I am currently working on a driver for an FDDI controller which supports IP checksum offload. There are a lot of these type critters out there from a number of different vendors. I would be willing to bet a six pack of some moderate priced malt beverage that the firmware on this board does not look at the IP version number before sending packets off to be checksummed. In this case it is possible, given appropriate IPv6 header content (specifically priority and source address), for a dual stack host to be unable to receive IPv6 packets from this interface. Obviously, a board which operated in the above fashion would be "broken" from an engineering point of view. However, what the user sees is that the IPv6 transition is a pain because they have to rip out a bunch of hardware for which they have payed good money. This is not my definition of a smooth transition. 2) We have plenty of SHOULDs and MAYs in the RFCs already. If we are going to have a new Ethertype then make it a MUST. The option of doing both adds complexity but does not appear to have any functional benefit. 3) As a company who is actively working on an IPv6 implementation it would be very nice if we could get resolution of this particular problem soon. By soon I mean before Stockholm and preferably via the mailing list. Thanks for the indulgence. Tim Hartrick Mentat Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 10:13:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05962; Tue, 16 May 95 10:13:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05638; Tue, 16 May 95 05:46:21 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10731; Tue, 16 May 1995 05:37:23 -0700 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA02624; Tue, 16 May 95 05:37:17 PDT Received: by rodan.UU.NET id QQypyw25469; Tue, 16 May 1995 08:37:05 -0400 Message-Id: To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) From: "Louis A. Mamakos" Subject: (IPng 99) Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Tue, 16 May 1995 13:51:29 +0200." <9505161151.AA06680@dxcoms.cern.ch> Date: Tue, 16 May 1995 08:37:04 -0400 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > > > If we were to allow this, we'd also need some kind of negotiation > > or rules to figure out when you might want to send one, and when > > the other. Really! > > Of course. > > IPv6 nodes on Ethernet or any other link using the Ethertype field > MUST set Ethertype = 0800 or Ethertype = . > > They SHOULD set Ethertype = 0800 but they MAY be configured to set > Ethertype = if necessary due to local requirements. > > IPv6 nodes on Ethernet or any other link using the Ethertype field > MUST accept and process incoming IPv6 packets with either > Ethertype = 0800 or Ethertype = . Plug 'n play, eh? This is just nuts. Having seen and experienced what happened in the Novell world with (at the time 2) encapsulations and now 3 on Ethernets, we paid over and over for this kind of foolishness. Remember Berkeley "trailers" encapsualtion on Ethernets? It took years to stomp that out, even after adding negotiation cruft to ARP. Sure, we got really good at diagnosing these problems. We don't need to relive this, agin. Please do not add gratutitous degrees of freedom to the configuration of an IPv6 host. It ought to be possible to pick one answer. While there is a certain elegance in using 0x800, I'd much prefer a different ethernet type field as an alternative to *two* of them. Louis A. Mamakos, Manager of Network Engineering louie@uu.net, uunet!louie UUNET Technologies, Inc. Voice: +1 703 206 5823 3060 Williams Drive Fax: +1 703 206 5908 Fairfax, VA 22031 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 10:14:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05974; Tue, 16 May 95 10:14:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05687; Tue, 16 May 95 06:05:29 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11444; Tue, 16 May 1995 05:56:31 -0700 Received: from carmen.logica.co.uk by Sun.COM (sun-barr.Sun.COM) id AA04939; Tue, 16 May 95 05:55:56 PDT Received: from smtpmail.logica.com (mssmtp.logica.com) by carmen.logica.co.uk (4.1/SMI-4.1) id AA04662; Tue, 16 May 95 13:55:39 BST Received: by smtpmail.logica.com with Microsoft Mail id <2FB8AED4@smtpmail.logica.com>; Tue, 16 May 95 13:55:32 bst From: Fieldhouse Dirk To: 'IPng mailing list' Subject: (IPng 100) Re: Ethernet Protocol Type for IPv6 Date: Tue, 16 May 95 13:55:00 bst Message-Id: <2FB8AED4@smtpmail.logica.com> Encoding: 22 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk gja@thumper.bellcore.com remarked: > (Poses an interesting side question - when is a version not > a version, but a new protocol?) No problem here surely? Technically a version change implies some degree of direct interoperability with the current version by addition of non-critical extension fields, or such. Otherwise it's a new protocol. You may want to use a version number in the same series for presentational reasons, but you can't get any technical benefit from doing so. BTW, an earlier post in this thread mentioned the desire to avoid an 802.3 mapping. At least that would ensure the demuxing that Dimitry is looking for. If this is such an obvious non-starter, perhaps someone in the know would email me, rather than clogging the list. Otherwise ... Dirk Fieldhouse Logica UK Limited fieldhouse@logica.com 75 Hampstead Road c=gb;a=tmailuk;p=logica; London NW1 2PL o=lg;ou1=lgwct;s=fieldhouse UK +44 (171) 637 9111 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 10:44:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05999; Tue, 16 May 95 10:44:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05993; Tue, 16 May 95 10:43:58 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09717; Tue, 16 May 1995 10:34:58 -0700 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA23279; Tue, 16 May 95 10:34:57 PDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25978; Wed, 17 May 1995 03:34:49 +1000 (from kre) Date: Wed, 17 May 1995 03:34:49 +1000 From: Robert Elz Message-Id: <9505161734.25978@munnari.oz.au> To: dhaskin@BayNetworks.com, rcallon@BayNetworks.com Subject: (IPng 101) Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Tue, 16 May 95 12:49:56 EDT From: rcallon@BayNetworks.com (Ross Callon) Message-Id: <9505161649.AA08439@BayNetworks.com> If I may borrow your diagram for a minute, (I hate drawing these things myself) lets consider a slightly more complex example: link to dual (v4 and v6) Internet | | +------+-------+ | Dual IP/IPv6 | | router A | +------+-------+ | --------+-----+-------------------------+------ | | +-----+-------+ +-------+-----+ | IP router | | Dual IP/IPv6| | else bridge | | router B | +-----+-------+ +-------+-----+ | | --------+-----------+-- --+--------+------------- | | +-+----------+-+ | IP router | | else bridge | +-------+------+ | ---------+-----+-------------- | +-----+-----+ | dual-host | +-----------+ (The lowest of those routers is largely irrelevant here). Now the dual-host at the bottom sees itself connected to two different IPv6 networks, on the same cable - worse, the dual router (B) on the second level sees what appears to be the same IPv6 network on two of its interfaces. This kind of thing looks like it is going to get far too complicated far too quickly to me, I'd hate to try and explain to anyone what is going on - yet this is the natural consequence of taking the state in Ross's diagram, and upgrading one more router to code that can handle IPv6. We have to be able to handle routing between IPv6 clouds where there is no bridging, there's no way we can expect all the long haul nets of the world to bridge IPv6 for us - I don't see a need to add bridging as yet another way to get past IPv4 only routers. Note - this is not an argument against a new ethertype, other than being (perhaps) an argument against one of the reasons for that change. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 11:00:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06037; Tue, 16 May 95 11:00:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06031; Tue, 16 May 95 11:00:16 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11797; Tue, 16 May 1995 10:51:16 -0700 Received: from ccc.casc.com ([152.148.40.231]) by Sun.COM (sun-barr.Sun.COM) id AA26727; Tue, 16 May 95 10:50:23 PDT Received: from alpo.casc.com ([152.148.10.6]) by ccc.casc.com (4.1/3.1.012693-Cascade) Received: from apollo13.cascade by alpo.casc.com (4.1/SMI-4.1) id AA00954; Tue, 16 May 95 13:47:07 EDT Received: by apollo13.cascade (5.0/SMI-SVR4) id AA02414; Tue, 16 May 1995 13:47:06 +0500 Date: Tue, 16 May 1995 13:47:06 +0500 From: jmoy@alpo.casc.com (John Moy) Message-Id: <9505161747.AA02414@apollo13.cascade> To: sthomas@mindspring.com Cc: ipng@sunroof.Eng.Sun.COM, ospf@gated.cornell.edu In-Reply-To: <199505160218.WAA07115@dylan.mindspring.com> (sthomas@mindspring.com) Subject: (IPng 102) Re: OSPF for IPv6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Stephen- I think that work on IPng routing protocols is supposed to be done in the various routing Working Groups. In particular, you should probably send comments on the OSPF for IPng draft to the OSPF mailing list (ospf@gated.cornell.edu). Rob needs to send out an updated version of the OSPF for IPng draft. As for your comments/questions, there will indeed be analogues of IPv4's group-membership-LSAs (MOSPF) and type-7-LSAs (NSSAs) for IPng. (Type-8 LSAs are however being replaced by Rob's Opaque-LSAs). The fields that you listed will indeed be extended to 16 bytes (the only one that was ever in doubt was the Router ID, but we decided last meeting to extend that to 16 bytes also): generic header: Router ID hello packet: Designated Router, Backup DR, Neighbor router-LSA: Attached Router AS-external-LSA: Forwarding Address group-membership-LSA: Vertex ID type-7-LSA: Forwarding Address Last meeting we decided to drop support for both IPv4 and IPv6 in a single protocol. Now, OSPF for IPng will route IPv6 only; if you also want to route IPv4 simultaneously, you have to do SIN routing. I think that this matches the current IPng transition strategy (dual stack and automatic tunneling) well. So, there's no bit in the Options field indicating IPv6 support, and we'll stop adding 16 to the LS type field (IPng router-LSAs will again be Type 1 LSAs, etc.). The Link Data field in the router-LSA will continue to be either a netmask, an IfIndex or an IP interface address, depending on context. It too will have to be 16 bytes (since it needs to contain an IP address sometimes), although OSPF for IPng will express net masks in a more compact fashion (i.e., as the number of prefix bits instead of a 16-byte mask). John ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 11:46:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06086; Tue, 16 May 95 11:46:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06080; Tue, 16 May 95 11:46:11 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18953; Tue, 16 May 1995 11:37:10 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA06723; Tue, 16 May 95 11:37:10 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA25488; Tue, 16 May 95 14:35:41 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA13722; Tue, 16 May 95 14:40:26 EDT Date: Tue, 16 May 95 14:40:26 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505161840.AA13722@BayNetworks.com> To: kre@munnari.oz.au, rcallon@BayNetworks.com Subject: (IPng 103) Re: Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > From major@marvin Tue May 16 13:49:50 1995 > Date: Wed, 17 May 1995 03:34:49 +1000 > From: Robert Elz > To: dhaskin@BayNetworks.com, rcallon@BayNetworks.com > Subject: (IPng 101) Re: Ethernet Protocol Type for IPv6 > Cc: ipng@sunroof.Eng.Sun.COM > Sender: owner-ipv6@marvin > Content-Length: 2310 > > Date: Tue, 16 May 95 12:49:56 EDT > From: rcallon@BayNetworks.com (Ross Callon) > Message-Id: <9505161649.AA08439@BayNetworks.com> > > > link to > dual (v4 and v6) > Internet > | > | 81::1 > +------+-------+ > | Dual IP/IPv6 | > | router A | > +------+-------+ > | 82::1 > --------+-----+-------------------------+------ > | | 82::2 > +-----+-------+ +-------+-----+ > | IP router | | Dual IP/IPv6| > | else bridge | | router B | > +-----+-------+ +-------+-----+ > | | 83::1 > --------+-----------+-- --+--------+------------- > | | > +-+----------+-+ > | IP router | > | else bridge | > +-------+------+ > | > ---------+-----+-------------- > | 83::2 > +-----+-----+ > | dual-host | > +-----------+ > > (The lowest of those routers is largely irrelevant here). Now the > dual-host at the bottom sees itself connected to two different IPv6 > networks, on the same cable - worse, the dual router (B) on the second > level sees what appears to be the same IPv6 network on two of its interfaces. > > This kind of thing looks like it is going to get far too complicated > far too quickly to me, I'd hate to try and explain to anyone what is > going on - yet this is the natural consequence of taking the state in > Ross's diagram, and upgrading one more router to code that can handle > IPv6. Robert, I took the liberty to assign IPv6 addresses to IPv6 interfaces. With the addresses assigned it doesn't look too complecated at all. The host at the bottom (which doesn't have to be dual) see itself connected to a single network 83::0. The dual router (B) (doesn't have to be dual) is connected to the same logical link but see itself connected to two different networks: 82::0 and 83::0 -- we do it all the time. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 16 12:35:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06195; Tue, 16 May 95 12:35:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06189; Tue, 16 May 95 12:35:03 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26041; Tue, 16 May 1995 12:26:05 -0700 Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA16025; Tue, 16 May 95 12:25:48 PDT Subject: (IPng 104) More Port Unreachable stuff To: IPng Mailing list Date: Tue, 16 May 1995 15:25:35 -0500 (EST) From: Dan McDonald Cc: 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: <9505162025.aa08680@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I have two big questions. The first one is now in its THIRD time being circulated. I STILL haven't received an answer: 1. OPTION STRIPPING AT THE TRANSPORT LAYER, AND ICMP PORT UNREACHABLE a. Should a higher level protocol (like UDP) strip IPv6 options from a packet before sending Dest. Unreachable so that the source of the offending packet can send the incoming Dest. Unreachable to its appropriate higher-level protocol? b. If not, what if the options (like a monstrously large source route) take all of the 576 bytes allowed for ICMP messages? How does my IPv6 module deal with this? Let me illustrate with an example. Let's say I send a UDP message with a source route to a machine. The header chain will look like: 0 40 n +------------+----------------+------------------------ | IPv6 hdr | Routing header | UDP header + data | | | | Next Hdr = | Next Header = | | Routing | UDP | +------------+----------------+------------------------ Now let's say the UDP header specifies a port that has no listeners. The receiving UDP module will send an ICMP Dest. Unreachable with code Port Unreachable. What will the ICMP Port/Dest. unreachable message look like? Will it look like this? <----- Offending packet, up to 576 bytes ---> (Potentially might not include UDP header. Think of n > 526. ) 0 40 48 88 n+48 +------------+-----++-----------+----------------+------------------ | IPv6 hdr |I D U||(Bad) IPv6 | Routing header | UDP header + data | |C e n||Header | | | Next Hdr = |M s r||Next Hdr = | Next Header = | | ICMP |P t c|| Routing | UDP | +------------+-----++-----------+----------------+------------------ Or will it look like.... 0 40 48 88 +------------+-----++-----------+------------------ | IPv6 hdr |I D U||(Bad) IPv6 | UDP header + data | |C e n||Header | | Next Hdr = |M s r||Next Hdr = | | ICMP |P t c|| UDP | +------------+-----++-----------+------------------ For those of you who like proposed answers with your questions I can say that my code, like it's 4.4BSD IPv4 counterpart, strips options, and will send back the packet with only the IPv6 header with next header set to UDP, and as much of the UDP datagram that fits. For those of you who think in terms of specs, and proposed changes to the spec, consider the _Implementation Notes_ section of the ICMPv6 spec (draft-ietf-ipngwg-icmp-01.txt). It currently reads: (b) Every IPv6 ICMP error message (the first four messages in the above list) includes as much of the IPv6 offending (invoking) packet (the packet that causes the error) as will fit without making the error message packet exceed 576 octets. (c) In those cases where the Internet layer is required to pass a IPv6 ICMP error message to the transport layer, the IPv6 Transport Protocol is extracted from the original header (contained in the body of the IPv6 ICMP error message) and used to select the appropriate transport protocol entity to handle the error. The interpretation of part (b) tells me I should include as much of the whole datagram, options and all, in the ICMP packet. This leads to making the job of implementing part (c) much MUCH harder, because I have to parse through a potential rats nest of options in the offending packet. Perhaps it should read: (b) Every IPv6 ICMP error message (the first four messages in the above list) includes as much of the IPv6 offending (invoking) packet (the packet that causes the error) as will fit without making the error message packet exceed 576 octets. If the IPv6 ICMP message is generated by the transport layer, with | the intent of notifying the sending transport layer, the offending | packet included SHOULD consist of only the IPv6 header and | transport header, followed by transport data. Again, this | offending packet must fit within 576 octets. | (c) In those cases where the Internet layer is required to pass a IPv6 ICMP error message to the transport layer, the IPv6 Transport Protocol is extracted from the original header (contained in the body of the IPv6 ICMP error message) and used to select the appropriate transport protocol entity to handle the error. Finally, there is another alternative: c. If I send back options in the enclosed ICMP packet, do I put ALL options in there? Or do I put select options in there? 2. FILTERING ROUTER WHICH FILTERS ON PORTS If I have a filterning router which filters on destination TCP or UDP ports (say I reject all incoming finger attempts, but accept SMTP), what happens when that filter fails? Do I send unreachable with code: a. Host unreachable b. Port unreachable c. Administratively unreachable (And how do I separate admin. HOST unreachable from admin. PORT unreachable?) I personally DON'T have an answer yet, because I have to finish host-related code before I can consider router-related code. I hope people have thought about these. I haven't seen a good answer on the first question despite having asked it months ago. (Either that, or that answer never reached NRL.) Thanks, Dan McD. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 17 02:41:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06689; Wed, 17 May 95 02:41:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06683; Wed, 17 May 95 02:41:45 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27070; Wed, 17 May 1995 02:32:46 -0700 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA29823; Wed, 17 May 95 02:32:44 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB08701; Wed, 17 May 1995 19:31:51 +1000 (from kre@munnari.OZ.AU) To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 105) Re: ICMPv6 & Port Unreachables In-Reply-To: Your message of "Tue, 16 May 1995 11:46:37 EDT." <9505161546.AA26681@itd.nrl.navy.mil> Date: Wed, 17 May 1995 19:30:24 +1000 Message-Id: <7425.800703024@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Tue, 16 May 95 11:46:37 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-ID: <9505161546.AA26681@itd.nrl.navy.mil> What do folks think about devoting part of the "Unused" 32-bits for the port number and upper-layer protocol (TCP, UDP, whatever) number for the case of ICMP Port Unreachable messages ? Excellent idea, though to make it more general, I think I'd rename those 32 bits from "unused" to "transport dependant data" and then for udp & tcp define the transport dependant data to be the port number pair (having both src and dst available is needed I think - dst so you know what port wasn't available, and src so the message can be returned to the correct sender). kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 17 05:47:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06771; Wed, 17 May 95 05:47:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06765; Wed, 17 May 95 05:47:16 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06064; Wed, 17 May 1995 05:38:17 -0700 Received: from ftp.com (wd40.ftp.com) by Sun.COM (sun-barr.Sun.COM) id AA19669; Wed, 17 May 95 05:38:16 PDT Received: by ftp.com ; Wed, 17 May 1995 08:36:36 -0400 Received: by ftp.com ; Wed, 17 May 1995 08:36:36 -0400 Date: Wed, 17 May 1995 08:36:36 -0400 From: jdemarco@ftp.com (Jim DeMarco) Message-Id: <9505171236.AA23304@ftp.com> To: kre@munnari.OZ.AU Cc: atkinson@itd.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM In-Reply-To: Robert Elz's message of Wed, 17 May 1995 19:30:24 +1000 <7425.800703024@munnari.OZ.AU> Subject: (IPng 106) Re: ICMPv6 & Port Unreachables Reply-To: jdemarco@ftp.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > What do folks think about devoting part of the "Unused" > 32-bits for the port number and upper-layer protocol (TCP, UDP, > whatever) number for the case of ICMP Port Unreachable messages ? > >Excellent idea, though to make it more general, I think >I'd rename those 32 bits from "unused" to "transport dependant >data" and then for udp & tcp define the transport dependant >data to be the port number pair (having both src and dst >available is needed I think - dst so you know what port >wasn't available, and src so the message can be returned to the >correct sender). This assumes that TCPng and UDPng will use 16-bit ports, like the current versions of TCP and UDP. Is this a valid assumption? How would 32-bit ports be handled? --Jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 17 06:20:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06814; Wed, 17 May 95 06:20:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06808; Wed, 17 May 95 06:20:17 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08426; Wed, 17 May 1995 06:11:12 -0700 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA26606; Wed, 17 May 95 06:10:58 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 17 May 1995 23:07:40 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Wed, 17 May 1995 23:10:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 17 May 1995 23:10:48 +1000 Date: Wed, 17 May 1995 23:10:48 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof2.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL May 17 23:10:48 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 481023170595 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <481023170595*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof2.Eng.Sun.COM (Non Receipt Notification Requested) Subject: (IPng 107) Re: ICMPv6 & Port Unreachables Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >> What do folks think about devoting part of the "Unused" >> 32-bits for the port number and upper-layer protocol (TCP, UDP, >> whatever) number for the case of ICMP Port Unreachable messages ? >> >>Excellent idea, though to make it more general, I think >>I'd rename those 32 bits from "unused" to "transport dependant >>data" and then for udp & tcp define the transport dependant >>data to be the port number pair (having both src and dst >>available is needed I think - dst so you know what port >>wasn't available, and src so the message can be returned to the >>correct sender). >This assumes that TCPng and UDPng will use 16-bit ports, like the >current versions of TCP and UDP. Is this a valid assumption? How >would 32-bit ports be handled? Is this a case of expanding the message format to create more "unused bit"? Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 17 08:51:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07029; Wed, 17 May 95 08:51:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07023; Wed, 17 May 95 08:50:54 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19819; Wed, 17 May 1995 08:41:53 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA19937; Wed, 17 May 95 08:41:53 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA15309; Wed, 17 May 95 11:40:23 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA20873; Wed, 17 May 95 11:45:07 EDT Date: Wed, 17 May 95 11:45:07 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505171545.AA20873@BayNetworks.com> To: sale@sware.com Subject: (IPng 108) Re: Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM, dhaskin@BayNetworks.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Date: Tue, 16 May 1995 09:25:30 -0400 > From: Ed Sale > > Dimitry Haskin writes: > | Among the reasons for using an unique EtherType for ST2 were: > | > | - improved performance since no extra level of demultiplexing. > | - there were a number of legacy systems (and I'm confident still > | are ;\ ) that handled only IPv4 and did not check the version of > | IP header (e.g. Motorola's security encapsulation device (NES)). > | Such systems crashed when ST2 packets showed up. > > Dimitry, > > The sky is not falling. The "legacy systems" that do not check > the IP header type that receive an IPv6 packet will *probably* > check the IPv4 header checksum, which is almost guaranteed to > fail, since IPv6 does not have one -- it has part of the source > address where the IPv4 checksum resides. If they do not, let > them crash and burn. > Ed, Your argument would be very sensible except, as was discovered during the ST-2 deployment, those system that don't check IP version DO NOT verify the IPv4 header checksum either (ST-2 has its checksum in the different from IPv4 place). This was the result of an attempt on part of some vendors to gain max performance on theit boxes. Unfortunately, how indignant we can be, we may not have luxury to "burn" those devices -- I still have to see clients lining up to deploy IPv6 even at a marginal cost to them. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 17 10:11:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07192; Wed, 17 May 95 10:11:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07186; Wed, 17 May 95 10:11:31 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29757; Wed, 17 May 1995 10:02:30 -0700 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA06908; Wed, 17 May 95 10:02:17 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26501; Thu, 18 May 1995 03:02:07 +1000 (from kre@munnari.OZ.AU) To: dhaskin@BayNetworks.com (Dimitry Haskin) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 109) Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Tue, 16 May 1995 14:40:26 EDT." <9505161840.AA13722@BayNetworks.com> Date: Thu, 18 May 1995 03:01:37 +1000 Message-Id: <7513.800730097@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Tue, 16 May 95 14:40:26 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-ID: <9505161840.AA13722@BayNetworks.com> > link to > dual (v4 and v6) > Internet > | > 10.1.1.1 | 81::1 > +------+-------+ > | Dual IP/IPv6 | > | router A | > +------+-------+ > 10.2.1.1 | 82::1 > --------+-----+-------------------------+------ > 10.2.1.3 | 10.2.1.2 | 82::2 > +-----+-------+ +-------+-----+ > | IP router | | Dual IP/IPv6| > | else bridge | | router B | > +-----+-------+ +-------+-----+ > 10.3.1.3 | 10.4.1.2 | 83::1 > --------+-----------+-- --+--------+------------- > 10.3.1.4 | 10.4.1.4| > +-+----------+-+ > | IP router | > | else bridge | > +-------+------+ > 10.5.1.4 | > ---------+-----+-------------- > 10.5.1.5 | 83::2 & 82::3 > +-----+-----+ > | dual-host | > +-----------+ > I took the liberty to assign IPv6 addresses to IPv6 interfaces. OK, but let's complete the job, as I have (partly) done above. First, with the pure IPv6 numbers, the host you had labelled 83::2 is also 82::3 - as packets from the 82::x net are bridged directly to it (as well as being routed). Also note that the dual router (82::2 and 83::1) also receives packets from the 82::x net on its 83::1 interface, as they can be bridged through the IPv4 only router on the left, and then the one below those two, meaning it too should have an 82::x address on the interface currently numbered 83::1 ... but similarly, 83::x packets can traverse those bridges the other way, so the two 82::x interfaces on the dual routers above also need 83::x numbers - that is, everything that is 82::y is also 83::z for some y and z. This is really truly simple stuff! But during the transition phase, hosts, to be useful for almost anything, are going to have to have IPv4 compatability addresses, or they won't be able to talk to the old part of the universe that only speaks IPv4 - and while upgrading routers is typically quick, upgrading hosts is slow (these are in relative terms, not absolute), so you can expect that there will be IPv4 only hosts around, and even interesting ones, well after essentially all routers have been upgraded. With this, the 83::2 host, which will be a dual-stack host, or it will be useless (or close enough to that - lets just assume it is dual for now), in the diagram above, will need to be, for IPv6 routing purposes, 0::10.2.1.5 and 0::10.4.1.5 as those are the IPv4 interfaces of the routers it is (via the IPv6 net) connected to, but according to its own rules for constructing IPv4 compat addresses, it would be 0::10.5.1.5. (In all of this, I probably really mean 0::FFFF:10.a.b.c but those F's just add confusion here) I have no idea how to make this kind of addressing work, and remain compatible with IPv4 routing, other than possibly by requiring all such topologies to multi-number all such cables (and interfaces), with every possible compatability address, so our host would have all 3 addresses, and consequently the dual stack routers would also have 3 addresses, with, in each case, just one of them relating to its natural IPv4 addressing. I don't know how this kind of numbering fits with the transition plans using the IPv4 compatible number spaces, but I certainly know its going to be as confusing as anything can be if we allow this kind of addressing scheme, and all the manual configuration it would entail (hosts can autoconfigure their "natural" IPv4 compatability address(es), I see no way for them to do that with all those others they seem required to obtain). What's more, all these extra IPv4 compat addresses need to be taken from the IPv4 address space available to the site - many address-conservationist sites, that don't have zillions of available free IPv4 addresses in their address ranges may not have enough IPv4 addresses left free to number everything this way. Next, if you really want nightmares, consider that the internal dual router follows the original DIX philosophy, and has just one MAC address it shares amongst all its interfaces, rather than a private one for each (if you like, say that router is a multi- interface Sun). Now form its "link local" address on each of its two interfaces, and attempt to figure out just what those mean to packet delivery, and which packets each interface should receive and from where. For extra credit form an IPv6 multicast distribution tree that has a hope of sanity in this topology. I still really can't see IPv6 bridging while simultaneously routing IPv4 being a productive way to allow anyone but a masochist to manage their nets (regardless of what are the capabilities of the routers involved, or the mechanism they use to work out which packets should be routed and which bridged). kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 17 11:17:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07445; Wed, 17 May 95 11:17:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07439; Wed, 17 May 95 11:16:53 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10346; Wed, 17 May 1995 11:07:38 -0700 Received: from bastion.sware.com by Sun.COM (sun-barr.Sun.COM) id AA20018; Wed, 17 May 95 11:07:24 PDT Received: from shlep.sware.com (shlep.sware.com [139.131.1.14]) by bastion.sware.com (8.6.5/8.6.5) with SMTP id OAA05861; Wed, 17 May 1995 14:06:55 -0401 Received: by shlep.sware.com (5.65/2.0) from wanda.sware.com id AA03822; Wed, 17 May 95 14:07:07 -0400 Received: by wanda.sware.com.sware.com (1.38.193.4/2.0) id AA00503; Wed, 17 May 1995 14:08:24 -0400 Date: Wed, 17 May 1995 14:08:24 -0400 From: Ed Sale Message-Id: <9505171808.AA00503@wanda.sware.com.sware.com> To: dhaskin@BayNetworks.com Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9505171545.AA20873@BayNetworks.com> (dhaskin@BayNetworks.com) Subject: (IPng 110) Re: Re: Re: Ethernet Protocol Type for IPv6 Reply-To: sale@sware.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Productive Suggestion: ---------------------- Perhaps there is a need to start a new IPv6 working group aimed at preventing the problem Dimitry has illustrated. The group would be responsible for producing a test suite that would perform a thorough test of the basic IPv6 functionality. Vendors could use this test suite to verify their products and customers could use them to perform site acceptance tests. In this way we will be much less likely to find ourselves in this situation again. Argumentative Diatribe: ----------------------- | Dimitry Haskin writes: | Your argument would be very sensible except, as was discovered | during the ST-2 deployment, those system that don't check IP version | DO NOT verify the IPv4 header checksum either (ST-2 has its checksum | in the different from IPv4 place). This was the result of an attempt | on part of some vendors to gain max performance on theit boxes. | Unfortunately, how indignant we can be, we may not have luxury to "burn" | those devices -- I still have to see clients lining up to deploy | IPv6 even at a marginal cost to them. I will agree to disagree with you on this point. I do not think we are going to change each others' minds. However, I do not want this list to come to the conclusion that since yours is the only voice that is being heard that there is anywhere near consensus on the issue. I understand your concern, but the vendors (would you care to name them?) that your are concerned about did not deploy IPv4, they deployed a close approximation. This is the Internet Engineering Task Force, not the Society for Hoplessly Incompatible Technology, or the Foundation for the Preservation of Poor Coders. These are a few of our rules: >From rfc791 "Internet Protocol": Header Checksum: 16 bits A checksum on the header only. Since some header fields change (e.g., time to live), this is recomputed and verified at each point that the internet header is processed. >From rfc1122 "Requirements for Internet Hosts -- Communication Layers": 3.1 INTRODUCTION The Robustness Principle: "Be liberal in what you accept, and conservative in what you send" is particularly important in the Internet layer, where one misbehaving host can deny Internet service to many other hosts. ... and ... 3.2.1.1 Version Number: RFC-791 Section 3.1 A datagram whose version number is not 4 MUST be silently discarded. 3.2.1.2 Checksum: RFC-791 Section 3.1 A host MUST verify the IP header checksum on every received datagram and silently discard every datagram that has a bad checksum. >From rfc1123 "Requirements for Internet Hosts -- Application and Support": 1.2.2 Robustness Principle At every layer of the protocols, there is a general rule whose application can lead to enormous benefits in robustness and interoperability: "Be liberal in what you accept, and conservative in what you send" The vendors you allude to chose to give up interoperability at the cost of a few instructions per packet. That was a business decision that they (and unfortunately their customers) should pay for, not the rest of us. The only way to discourage this kind of behavior is *economically*. Expose their dirty laundry and let the vendors decide whether to bring their products up to the defined standard or go out of business for not doing so. If customers purchased equipment that will not allow them to easily upgrade to IPv6 they should go back to the vendors of their incompatible equipment and demand an upgrade. If this demand is not met, they should look for alternative vendors that will supply compatible products and cease to use the vendors that failed to provide products that adhered to standards. In case you haven't been listening, customers are demanding interoperability and adherence to standards which allows them the freedom to choose from among a number of vendors for any given solution. If you're unwilling to produce IPv6 products in this kind of environment due to a perceived reluctance on the part of potential customers to purchase a solution that *might* break something already on their network, please find another line of work and give somebody that is willing to do it the names and addresses of your customers. Great care has been taken in the production of IPv6 to avoid breaking *standard* implementations of IPv4. If you were making the argument that IPv6 as it stands will break *correct* implementations or IPv4, I would be behind you 100%. If we be begin to make the kinds of modifications you suggest because a vendor chose to ignore our published standards we will never be able to produce a reasonable standard again, in my opinion. -- Ed ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 17 11:47:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07483; Wed, 17 May 95 11:47:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07477; Wed, 17 May 95 11:47:42 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14758; Wed, 17 May 1995 11:38:38 -0700 Received: from venera.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA26391; Wed, 17 May 95 11:38:37 PDT Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 17 May 1995 11:38:35 -0700 From: bmanning@ISI.EDU Posted-Date: Wed, 17 May 1995 11:36:50 -0700 (PDT) Message-Id: <199505171836.AA11814@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 17 May 1995 11:36:50 -0700 Subject: (IPng 111) Re: Re: Re: Re: Re: Ethernet Protocol Type for IPv6 To: bound@zk3.dec.com Date: Wed, 17 May 1995 11:36:50 -0700 (PDT) Cc: bmanning@ISI.EDU, ipng@sunroof.Eng.Sun.COM In-Reply-To: <9505152004.AA13167@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at May 15, 95 04:04:08 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 > > > >Would it be appropriate to try and set up an IDRP structure so that > >we can really test routing of IPv6 packets w/o tunneling? > > Yes. > And how do you propose we do this? -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 17 12:28:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07532; Wed, 17 May 95 12:28:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07526; Wed, 17 May 95 12:28:42 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20075; Wed, 17 May 1995 12:19:43 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA03275; Wed, 17 May 95 12:19:41 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA23054; Wed, 17 May 95 15:18:12 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA00833; Wed, 17 May 95 15:22:58 EDT Date: Wed, 17 May 95 15:22:58 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505171922.AA00833@BayNetworks.com> To: kre@munnari.OZ.AU Subject: (IPng 112) Re: Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM, dhaskin@BayNetworks.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > From: Robert Elz > > > link to > > dual (v4 and v6) > > Internet > > | > > 10.1.1.1 | 81::1 > > +------+-------+ > > | Dual IP/IPv6 | > > | router A | > > +------+-------+ > > 10.2.1.1 | 82::1 > > --------+-----+-------------------------+------ > > 10.2.1.3 | 10.2.1.2 | 82::2 > > +-----+-------+ +-------+-----+ > > | IP router | | Dual IP/IPv6| > > | else bridge | | router B | > > +-----+-------+ +-------+-----+ > > 10.3.1.3 | 10.4.1.2 | 83::1 > > --------+-----------+-- --+--------+------------- > > 10.3.1.4 | 10.4.1.4| > > +-+----------+-+ > > | IP router | > > | else bridge | > > +-------+------+ > > 10.5.1.4 | > > ---------+-----+-------------- > > 10.5.1.5 | 83::2 & 82::3 > > +-----+-----+ > > | dual-host | > > +-----------+ > > > > OK, but let's complete the job, as I have (partly) done above. > > First, with the pure IPv6 numbers, the host you had labelled > 83::2 is also 82::3 - as packets from the 82::x net are bridged > directly to it (as well as being routed). Also note that the > dual router (82::2 and 83::1) also receives packets from the 82::x > net on its 83::1 interface, as they can be bridged through the > IPv4 only router on the left, and then the one below those two, > meaning it too should have an 82::x address on the interface > currently numbered 83::1 ... but similarly, 83::x packets can > traverse those bridges the other way, so the two 82::x interfaces > on the dual routers above also need 83::x numbers - that is, > everything that is 82::y is also 83::z for some y and z. > > This is really truly simple stuff! Oh, boy! Robert, you're really confused :) First, the host at the bottom does not have to be on both subnets 82::0 and 83::0 unless, of cause, you want it to. The fact that a host can directly reach multiple subnetworks doesn't require such a host to have addresses on all of them. Similarly, the fact that the router B can directly receive traffic from the same subnetwork on its both interfaces doesn't mean that the both interfaces should have addresses on that subnet. Topologies like that are quite common. > > But during the transition phase, hosts, to be useful for almost > anything, are going to have to have IPv4 compatability addresses, > or they won't be able to talk to the old part of the universe that > only speaks IPv4 - and while upgrading routers is typically > quick, upgrading hosts is slow (these are in relative terms, not > absolute), so you can expect that there will be IPv4 only hosts > around, and even interesting ones, well after essentially all > routers have been upgraded. > In order for a dual host to speak to the hosts that only speaks IPv4 it will need to use IPv4 stack. A dual host needs a IPv4-compatible IPv6 address only if there is no adjacent IPv6 router, so that such a host can be reached from the IPv6-speaking universe via automatic tunnels. If you want, you can re-number interfaces on the diagram to IPv4-compatible addresses. But if you deploy bridging to create adjacency between hosts and a remote IPv6 router you can start using any type of IPv6 addresses with added benefits of doing so (you also can use manually configured tunnels as an alternative). > ... > > Next, if you really want nightmares, consider that the internal > dual router follows the original DIX philosophy, and has just one > MAC address it shares amongst all its interfaces, rather than > a private one for each (if you like, say that router is a multi- > interface Sun). Now form its "link local" address on each of > its two interfaces, and attempt to figure out just what those > mean to packet delivery, and which packets each interface should > receive and from where. For extra credit form an IPv6 multicast > distribution tree that has a hope of sanity in this topology. > I'm not sure if your nightmare examples can't be dealt in the given topology (don't have mental cycles to look at them now :), but i concede that in some cases deploying bridging may not be appropriate. It still doesn't mean that it can't successfully used in many other cases. > > kre Regards, Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 17 12:32:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07544; Wed, 17 May 95 12:32:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07538; Wed, 17 May 95 12:32:13 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20460; Wed, 17 May 1995 12:23:13 -0700 Received: from BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA03893; Wed, 17 May 95 12:23:06 PDT Message-Id: <9505171923.AA03893@Sun.COM> From: "John Day" Subject: (IPng 113) Re: ethertype for v6 To: ipng@sunroof.Eng.Sun.COM Date: Wed, 17 May 95 15:15:22 EST Mail-System-Version: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk This has been an interesting discussion, but as some of indicated we should just admit that IPv6 regardless of its name is a new protocol. It has been another example of how a lot of little changes can leave one in an entirely different place without really noticing that you have moved at all. While the early drafts of SIP did resemble IPv4 fairly strongly, the only field IPv6 has in common (both in semantics and placement) is the version field. The comment yesterday that IPv6 "is tied to IPv4 in numerous ways: upper level protocols, shared address space, etc." Was one of the greatest tongue in cheek comments yet on this list. All indications are that the best solution is a new ethertype and a new protocol. Which brings up do you need the Version Field? Now some would argue that every protocol should have a version field, but in this case I would say that the "articulated" nature of the IPv6 header actually makes it unnecessary. It is very unlikely that anything should ever change the "basic" header, and new facilities will be added by tacking on additional headers. The "other" headers don't need versions either since revisions can simply be considered as new additional headers and the old ones simply fall out of use. As was pointed out, not having a version field would allow a full 32 bit Flow Id, which might be a good thing. Since addresses should apply to individual flows, one could consider it as providing a few additional bytes of address space. It might even make mapping NSAPs easier, who knows. Take care John ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 17 12:59:49 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07581; Wed, 17 May 95 12:59:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07575; Wed, 17 May 95 12:59:36 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24113; Wed, 17 May 1995 12:50:36 -0700 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA08638; Wed, 17 May 95 12:50:34 PDT Received: from relay.imsi.com by wintermute.imsi.com id PAA19122; Wed, 17 May 1995 15:49:08 -0400 Received: from snark.imsi.com by relay.imsi.com id PAA12904; Wed, 17 May 1995 15:49:08 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA19433; Wed, 17 May 95 15:49:07 EDT Message-Id: <9505171949.AA19433@snark.imsi.com> To: "John Day" Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 114) Re: Re: ethertype for v6 In-Reply-To: Your message of "Wed, 17 May 1995 15:15:22 EST." <9505171923.AA03893@Sun.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 17 May 1995 15:49:06 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk "John Day" says: > This has been an interesting discussion, but as some of indicated we > should just admit that IPv6 regardless of its name is a new protocol. This is a semantic issue, not a technical issue. What is and is not a new protocol is purely a matter of definition. Since definitional arguments are usually quite futile, I'd suggest that we drop the matter. Repeating, its a matter of belief, not a technical question. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 17 13:26:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07599; Wed, 17 May 95 13:26:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07593; Wed, 17 May 95 13:26:22 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27417; Wed, 17 May 1995 13:17:22 -0700 Received: from BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA13825; Wed, 17 May 95 13:17:19 PDT Message-Id: <9505172017.AA13825@Sun.COM> From: "John Day" Subject: (IPng 115) Re: Re: ethertype for v6 To: perry@imsi.com Cc: Day@BBN.COM, ipng@sunroof.Eng.Sun.COM In-Reply-To: <9505171949.AA19433@snark.imsi.com> Date: Wed, 17 May 95 16:16:01 EST Mail-System-Version: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >This is a semantic issue, not a technical issue. What is and is not a >new protocol is purely a matter of definition. Since definitional >arguments are usually quite futile, I'd suggest that we drop the >matter. Repeating, its a matter of belief, not a technical question. You are absolutely right. That was what I said in my previous note, but as I suggested then if one wanted to try to characterize when one had a new protocol one might consider how similar the two headers are. One would like to have a technical reason for when it is a different protocol. With your argument, IPX, Pup and CLNP are all versions of IP. In fact, one might even argue that CLNP is closer to being a version of IP than IPv6. Take care John ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 17 14:23:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07640; Wed, 17 May 95 14:23:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07618; Wed, 17 May 95 14:11:17 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03189; Wed, 17 May 1995 14:02:17 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA22793; Wed, 17 May 95 14:02:15 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA26984; Wed, 17 May 95 17:00:46 EDT Received: from maggie.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA04949; Wed, 17 May 95 17:05:33 EDT Date: Wed, 17 May 95 17:05:32 EDT From: jkrawczy@BayNetworks.com (John Krawczyk) Message-Id: <9505172105.AA04949@BayNetworks.com> Received: by maggie.wellfleet (4.1/SMI-4.1) id AA07730; Wed, 17 May 95 17:02:49 EDT To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 116) Re: Ethernet Protocol Type for IPv6 In-Reply-To: <9505171808.AA00503@wanda.sware.com.sware.com> References: <9505171545.AA20873@BayNetworks.com> <9505171808.AA00503@wanda.sware.com.sware.com> Reply-To: jkrawczy@BayNetworks.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk On Wed, 17 May, Ed Sale (sale@sware.com) wrote: The vendors you allude to chose to give up interoperability at the cost of a few instructions per packet. That was a business decision that they (and unfortunately their customers) should pay for, not the rest of us. The only way to discourage this kind of behavior is *economically*. Expose their dirty laundry and let the vendors decide whether to bring their products up to the defined standard or go out of business for not doing so. If customers purchased equipment that will not allow them to easily upgrade to IPv6 they should go back to the vendors of their incompatible equipment and demand an upgrade. If this demand is not met, they should look for alternative vendors that will supply compatible products and cease to use the vendors that failed to provide products that adhered to standards. In case you haven't been listening, customers are demanding interoperability and adherence to standards which allows them the freedom to choose from among a number of vendors for any given solution. If you're unwilling to produce IPv6 products in this kind of environment due to a perceived reluctance on the part of potential customers to purchase a solution that *might* break something already on their network, please find another line of work and give somebody that is willing to do it the names and addresses of your customers. Great care has been taken in the production of IPv6 to avoid breaking *standard* implementations of IPv4. If you were making the argument that IPv6 as it stands will break *correct* implementations or IPv4, I would be behind you 100%. If we be begin to make the kinds of modifications you suggest because a vendor chose to ignore our published standards we will never be able to produce a reasonable standard again, in my opinion. Ed, I don't know what your experience is, but here is some of mine: When the network turns into a "notwork", those in charge put aside their concerns about interoperability and adherence to standards and instead concentrate on the single goal of getting their network up and running again, as soon as possible. Since they usually have a gun at their head at this point, they turn their own gun in the direction where they think they will get the quickest results. The vendor that gets the phone call is usually: 1) The "new kid on the block"; i.e., the one whose hardware or new software release they just installed. It all worked before, and it's broken now. It doesn't matter if the new stuff complies to the standards and the problem lies elsewhere - that vendor is still on the hook. Start talking about standards adherence and pointing fingers and you'll go home with your equipment. 2) The one who tends to get things fixed. You've been responsive in the past, and/or they've had bad luck their other vendors. Again, who is at fault isn't always the issue. 3) The one who still supports their product. Some equipment may be from vendors out of business or not supporting the hardware/software they are running. They may not be able to replace this equipment because they don't have the time (get that network up now!), the money, or they lack both. We have many hacks and kludges in our IPv4 code that violate "standards" in order to deal with specific customer problems. The reasons are various: they have some ancient buggy equipment, received some bad advice somewhere in the past in designing their network, or run some "novel" network applications. I anticipate the same will happen with IPv6, since we cannot anticipate everything people will do with this stuff (e.g., even if the IETF mandated that thou shalt not route IPv4 and bridge IPv6, someone's going to do it). We know that there are potential problems in using the same link level demux for both IPv4 and IPv6. We know that we can avoid these problems (think of it as preventive medicine) by going to a new demux. Implementing the new demux is not a great hardship to anyone and doesn't break anything (unless I missed something in this thread). If we stick with the same demux, the only satisifaction will be saying "I told you so" later, which doesn't do a lot for me (especially if I'm out there patching up the problems...). -jj ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 17 23:40:26 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08031; Wed, 17 May 95 23:40:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08025; Wed, 17 May 95 23:40:18 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20932; Wed, 17 May 1995 23:31:17 -0700 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA04866; Wed, 17 May 95 23:31:08 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch id AA14324; Thu, 18 May 1995 08:31:05 +0200 Received: by dxcoms.cern.ch id AA02173; Thu, 18 May 1995 08:31:02 +0200 Message-Id: <9505180631.AA02173@dxcoms.cern.ch> Subject: (IPng 117) Re: Re: ethertype for v6 To: ipng@sunroof.Eng.Sun.COM Date: Thu, 18 May 1995 08:31:02 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <9505171923.AA03893@Sun.COM> from "John Day" at May 17, 95 03:15:22 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 John, > > As was pointed out, not having a version field Consider that on some media we don't have an Ethertype field and we don't control the field we do have (NLPID for example). Not having a version field is dangerous. > would allow a full 32 bit > Flow Id, which might be a good thing. Since addresses should apply to > individual flows, one could consider it as providing a few additional > bytes of address space. > It might even make mapping NSAPs easier, who > knows. No. If we can do NSAPs at all, we can do them without perverting the Flow ID. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 18 01:00:46 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08068; Thu, 18 May 95 01:00:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08062; Thu, 18 May 95 01:00:39 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24237; Thu, 18 May 1995 00:51:38 -0700 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA13401; Thu, 18 May 95 00:51:37 PDT Received: by mitsou.inria.fr (8.6.12/8.6.12) id JAA01160; Thu, 18 May 1995 09:51:24 +0200 Message-Id: <199505180751.JAA01160@mitsou.inria.fr> To: dhaskin@BayNetworks.com (Dimitry Haskin) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 118) Re: Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Wed, 17 May 1995 11:45:07 EDT." <9505171545.AA20873@BayNetworks.com> Date: Thu, 18 May 1995 09:51:23 +0200 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk => Ed, => => Your argument would be very sensible except, as was discovered => during the ST-2 deployment, those system that don't check IP version => DO NOT verify the IPv4 header checksum either (ST-2 has its checksum => in the different from IPv4 place). This was the result of an attempt => on part of some vendors to gain max performance on theit boxes. => Unfortunately, how indignant we can be, we may not have luxury to "burn" => those devices -- I still have to see clients lining up to deploy => IPv6 even at a marginal cost to them. => => Dimitry Dimitry, If you compare the two headers, you will see that at least five checks are going to fail: * version number (4 vs 6) * header length (5 vs a "priority", leading to either a too short header or unrecognized options) * total length (length vs low 16 bits of flow label, which will be either zero if flow label is unused or some random value) * protocol type vs. some high order bits of the IPv6 source address * checksum vs. some high order bits of the IPv6 source address This is certainly sufficient to guarantee that if an IPv6 station inadvertently receives an IPv4 packet, this packet will be discarded. As IPv6 uses multicast rather than broadcast, this should only happen when the hashing of one IPv6 address into an Ethernet group address collides with the hashing of the IPv4 class D address of a group to which the IPv4 station subscribed. The argument for keeping the version field "even if we were to use separate ethertypes" was given by Andy Malis of BBN on the SIP list the 30 Sep 92: I would still like to lobby for a Version field, even if, as Steve suggested (perhaps jestingly) it just has its high bit on in the proper position with the other bits used for another purpose. Given that the size of the header is going to increase to at least 24 or 32 bytes, we should try to keep link-layer protocol IDs as compact as possible for the benefit of those folks still running slow links (remember, for example, that >90% of the leased lines in Europe are still 64 Kb or less, and there's lots of X.25 and ISDN in use as well). For X.25, Frame Relay, and ISDN, IP has the benefit of having a compact, one-octet protocol ID (CC). If you move to something requiring an Ethertype, then you have to add five more bytes for a SNAP header (see RFCs 1294 and 1356). In addition, reusing the same protocol ID means less implementation work; you don't have to change your link layer driver to recognize and send a new protocol type - you just kick the packet up to your switching process, which cases on the version number (as it should anyway). There were indeed numerous exchanges on the subject back then... Also, please count me in the "exactly one solution please" camp. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 18 05:24:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08133; Thu, 18 May 95 05:24:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08127; Thu, 18 May 95 05:24:40 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05049; Thu, 18 May 1995 05:15:39 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA05031; Thu, 18 May 95 05:15:39 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA09963; Thu, 18 May 95 08:14:04 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA07122; Thu, 18 May 95 08:18:50 EDT Date: Thu, 18 May 95 08:18:50 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505181218.AA07122@BayNetworks.com> To: Christian.Huitema@sophia.inria.fr Subject: (IPng 119) Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > From: Christian Huitema > If you compare the two headers, you will see that at least five checks are > going to fail: > > * version number (4 vs 6) > > * header length (5 vs a "priority", leading to either a too short header or > unrecognized options) > > * total length (length vs low 16 bits of flow label, which will be either > zero if flow label is unused or some random value) > > * protocol type vs. some high order bits of the IPv6 source address > > * checksum vs. some high order bits of the IPv6 source address > > This is certainly sufficient to guarantee that if an IPv6 station inadvertently > receives an IPv4 packet, this packet will be discarded. As IPv6 uses multicast > rather than broadcast, this should only happen when the hashing of one IPv6 > address into an Ethernet group address collides with the hashing of the IPv4 > class D address of a group to which the IPv4 station subscribed. Christian, I don't worry about an IPv6 station receiving IPv4 packets, I worry about about legacy IPv4 systems receiving IPv6 packets. Some of these system are bound to fail as it has been proven by the IPv5 experiment. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 18 05:58:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08146; Thu, 18 May 95 05:58:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08140; Thu, 18 May 95 05:58:31 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06277; Thu, 18 May 1995 05:49:30 -0700 Received: from ncc.ripe.net by Sun.COM (sun-barr.Sun.COM) id AA08017; Thu, 18 May 95 05:49:29 PDT Received: from belegen.ripe.net by ncc.ripe.net with SMTP id AA08261 (5.65a/NCC-2.22); Thu, 18 May 1995 14:49:12 +0200 Message-Id: <9505181249.AA08261@ncc.ripe.net> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: Christian.Huitema@sophia.inria.fr, ipng@sunroof.Eng.Sun.COM From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: (IPng 120) Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Thu, 18 May 1995 08:18:50 EDT." <9505181218.AA07122@BayNetworks.com> Date: Thu, 18 May 1995 14:48:58 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk On Thu, 18 May 95 08:18:50 EDT Dimitry Haskin wrote: > I don't worry about an IPv6 station receiving IPv4 packets, I worry about abo ut > legacy IPv4 systems receiving IPv6 packets. Some of these system are bound > to fail as it has been proven by the IPv5 experiment. I don't think that the defect on one specific kind of box should decide on a design issue as we are discussing. As the initial design of IPv6 was being completed, decisions were made that will cause severe migration problems. For instance, the decision to rely on multicast for basic IPv6 functionality will cause problems on PC-platforms as there is hardly a PC ethernet card that can do multicasting in a decent way. Which means that people using the widest-spread hardware platform (PeeCee), will need to change some hardware to make things work. (I already brought this up at Toronto) Why would we need to change specs to work around a few manufacturer-broken boxes if we have decided not to do so in the past? (sorry for bringing up already-decided issues again) In general, I feel that there should be *one* solution to this problem, (i.e. choose IP proto field or ether proto field, not both), and I think that demuxing on IP protocol field is best as it is hardware-independent. People have learned that bridging IP networks is a bad idea, and an alternative, tunnels, is part of the base spec. Moreover, I expect that IPv6-router upgrades will be available long before host implementations become available in any significant number, so the impact of local tunnels will not last very long... Geert Jan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 18 06:14:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08174; Thu, 18 May 95 06:14:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08168; Thu, 18 May 95 06:14:43 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06922; Thu, 18 May 1995 06:05:41 -0700 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA09506; Thu, 18 May 95 06:05:37 PDT Received: by mitsou.inria.fr (8.6.12/8.6.12) id PAA02050; Thu, 18 May 1995 15:04:49 +0200 Message-Id: <199505181304.PAA02050@mitsou.inria.fr> To: Geert Jan de Groot Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 121) Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Thu, 18 May 1995 14:48:58 +0200." <9505181249.AA08261@ncc.ripe.net> Date: Thu, 18 May 1995 15:04:48 +0200 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > In general, I feel that there should be *one* solution to this problem, > (i.e. choose IP proto field or ether proto field, not both), > and I think that demuxing on IP protocol field is best as it is > hardware-independent. People have learned that bridging IP networks > is a bad idea, and an alternative, tunnels, is part of the base spec. Geert Jan, The "bridge/router" split argument was not taken in consideration during the initial SIP design where this choice was made. As Ross Callon very well explained, having two separate Ethertype allows to have one gigantic bridged network for IPv6, where exactly one router suffice for deploying the whole stuff, while keeping the IPv4 routing unchanged. This is a very powerful argument, as it makes transitionning much easier. As a consequence, I believe that we will have a consensus to adopt a specific ethertype for IPv6, and that we will have a MUST requirement in the sense that if the media adaptation is "Ethernet like" then the IPv6 ethertype MUST be used -- we all want exactly one solution. This is not however a reason to drop the "version" field. There are at least three very strong arguments for keeping it: 1) It allows demux by version number on those links which do not use the "ethertype" encapsulation. 2) It allow evolution between several versions of IPv6. For example, we may very well come out some time later with a version which does address compression, flow-id switching, increased TTL field, whatever. 3) We have no business changing the header format once more. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 18 06:30:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08190; Thu, 18 May 95 06:30:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08184; Thu, 18 May 95 06:30:31 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07626; Thu, 18 May 1995 06:21:30 -0700 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA11032; Thu, 18 May 95 06:21:06 PDT Received: by mitsou.inria.fr (8.6.12/8.6.12) id PAA02092; Thu, 18 May 1995 15:20:40 +0200 Message-Id: <199505181320.PAA02092@mitsou.inria.fr> To: dhaskin@BayNetworks.com (Dimitry Haskin) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 122) Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Thu, 18 May 1995 08:18:50 EDT." <9505181218.AA07122@BayNetworks.com> Date: Thu, 18 May 1995 15:20:39 +0200 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk => Christian, => => I don't worry about an IPv6 station receiving IPv4 packets, I worry about about => legacy IPv4 systems receiving IPv6 packets. Some of these system are bound => to fail as it has been proven by the IPv5 experiment. => => Dimitry The 5 checks that I quoted were all supposed to be performed by the receiving IPv4 station. Problems will only arrive if the receiving IPv4 station: 1) does not check the version number, 2) does not check the header length, 3) does not check the packet length, 4) does not check the protocol type, 5) does not check the header checksum. I have heard of some which don't check version number and checksum. But then, not checking lengths and protocol type looks like cutting a very large chunk of the corners! Then, I could have added that the fragmentation offset will have some random value, typically 0x07xx or 0x06xx, which is also going to cause an error. By an large, the risk is acceptable for hosts, which can only receive some "colliding multicast" packets. However, the "bridging IPv6 during transition" argument is very powerful, and I believe that this alone can bring us to consensus on exactly one solution. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 18 06:38:32 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08203; Thu, 18 May 95 06:38:32 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08197; Thu, 18 May 95 06:38:23 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07970; Thu, 18 May 1995 06:29:22 -0700 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA12052; Thu, 18 May 95 06:29:22 PDT Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Thu, 18 May 1995 22:27:08 +0900 From: Masataka Ohta Message-Id: <199505181327.WAA18407@necom830.cc.titech.ac.jp> Subject: (IPng 123) Re: Re: Re: Ethernet Protocol Type for IPv6 To: ipng@sunroof.Eng.Sun.COM Date: Thu, 18 May 95 22:27:07 JST In-Reply-To: <199505181304.PAA02050@mitsou.inria.fr>; from "Christian Huitema" at May 18, 95 3:04 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > This is not however a reason to drop the "version" field. There are at least > three very strong arguments for keeping it: 4) We can avoid debate on the new name for IPv6. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 18 07:23:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08231; Thu, 18 May 95 07:23:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08225; Thu, 18 May 95 07:23:45 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10879; Thu, 18 May 1995 07:14:44 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA18215; Thu, 18 May 95 07:14:43 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA12804; Thu, 18 May 95 10:13:14 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA10615; Thu, 18 May 95 10:18:01 EDT Date: Thu, 18 May 95 10:18:01 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505181418.AA10615@BayNetworks.com> To: Christian.Huitema@sophia.inria.fr Subject: (IPng 124) Re: Re: Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > From: Christian Huitema > > This is not however a reason to drop the "version" field. There are at least > three very strong arguments for keeping it: > > 1) It allows demux by version number on those links which do not use the > "ethertype" encapsulation. > I'd like to make it clear that if we decide on a separate ethertype for IPv6 and want a single solution, we shouldn't allow to demux on the IP version number on non-ethernet links. SNAP will need to be used with other encapsulations (802, Q.922, IPoATM, IPoFR) or an NLPID for IPv6 will need to be requested from ISO. SNAP uses ethertype for de-muxing. A separate NLPID for IPv6 saves 6 bytes in encapsulation header (if someone cares). We'll also need to get an IPv6 protocol type value for PPP. > 2) It allow evolution between several versions of IPv6. For example, we may > very well come out some time later with a version which does address > compression, flow-id switching, increased TTL field, whatever. > > 3) We have no business changing the header format once more. > Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 18 08:42:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08264; Thu, 18 May 95 08:42:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08258; Thu, 18 May 95 08:41:52 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17236; Thu, 18 May 1995 08:32:51 -0700 Received: from itd.nrl.navy.mil (itd-fddi.nrl.navy.mil) by Sun.COM (sun-barr.Sun.COM) id AA00830; Thu, 18 May 95 08:32:48 PDT Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA11005; Thu, 18 May 95 11:31:59 EDT Date: Thu, 18 May 95 11:31:59 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9505181531.AA11005@itd.nrl.navy.mil> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 125) EtherType for IPv6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk kre's analyses have all seemed most logical and sensible to me. I'm with him on the EtherType for IPv6 question. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 18 08:53:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08291; Thu, 18 May 95 08:53:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08285; Thu, 18 May 95 08:52:55 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18557; Thu, 18 May 1995 08:43:53 -0700 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA02628; Thu, 18 May 95 08:43:38 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch id AA21058; Thu, 18 May 1995 17:43:14 +0200 Received: by dxcoms.cern.ch id AA12875; Thu, 18 May 1995 17:43:11 +0200 Message-Id: <9505181543.AA12875@dxcoms.cern.ch> Subject: (IPng 126) Re: Re: Re: Re: Ethernet Protocol Type for IPv6 To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Date: Thu, 18 May 1995 17:43:11 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <9505181418.AA10615@BayNetworks.com> from "Dimitry Haskin" at May 18, 95 10:18:01 am 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 Dimitry, > I'd like to make it clear that if we decide on a separate ethertype for IPv6 > and want a single solution, we shouldn't allow to demux on the IP version number > on non-ethernet links. SNAP will need to be used with other encapsulations > (802, Q.922, IPoATM, IPoFR) or an NLPID for IPv6 will need to be requested from > ISO. SNAP uses ethertype for de-muxing. A separate NLPID for IPv6 saves 6 bytes > in encapsulation header (if someone cares). What about media where there is neither SNAP nor NLPID, which are being used only for IP? The null encapsulation of RFC 1483 is an example (even though it is not used by RFC 1577). Null encapsulation is theoretically possible on any virtual circuit medium. You must be able to run both IPv4 and IPv6 even with null encapsulation, or else transition breaks. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 18 08:54:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08303; Thu, 18 May 95 08:54:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08297; Thu, 18 May 95 08:54:06 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18722; Thu, 18 May 1995 08:44:57 -0700 Received: from inet-gw-1.pa.dec.com by venus.Sun.COM (Sun.COM) id IAA04838; Thu, 18 May 1995 08:44:57 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA28530; Thu, 18 May 95 08:39:07 -0700 Received: by xirtlu.zk3.dec.com; id AA07226; Thu, 18 May 1995 11:39:03 -0400 Message-Id: <9505181539.AA07226@xirtlu.zk3.dec.com> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: Christian.Huitema@sophia.inria.fr, ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com Subject: (IPng 127) Re: Re: Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Thu, 18 May 95 10:18:01 EDT." <9505181418.AA10615@BayNetworks.com> Date: Thu, 18 May 95 11:38:57 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >I'd like to make it clear that if we decide on a separate ethertype for IPv6 >and want a single solution, we shouldn't allow to demux on the IP version number >on non-ethernet links. SNAP will need to be used with other encapsulations >(802, Q.922, IPoATM, IPoFR) or an NLPID for IPv6 will need to be requested from >ISO. SNAP uses ethertype for de-muxing. A separate NLPID for IPv6 saves 6 bytes >in encapsulation header (if someone cares). I will not support at this time removal of the version # from the packet so let me make that CLEAR. I also am waiting to hear from Steve Deering on this entire issue as he has the previous data on the debate. Christians message reattached. ALso to Geert Jan. I don't agree you will see routers first. In fact I think you will see Advanced Development Early Adopter kits from Host Vendors for IPv6 by June 96 is my guess. Unless we keep changing the protocol and keep being late getting update specs out to the WG like Neighbor Discovery at present. I have customers who have already asked for our IPv6 prototype work on Digital UNIX and I won't let it out because of NON-concrete specs and only two implementations that will publicly state they can test today INRIA and Digital. Note also that Christian is at INRIA and I am at Digital and we have implementations now with real code so lets get this figured out when Steve comes back A.S.A.P. this is pretty basic stuff and we already talked all this out and are revisiting it per an implementor finding an issue. But we have no consensus at all at this time. /jim ************************************************* This is not however a reason to drop the "version" field. There are at least three very strong arguments for keeping it: 1) It allows demux by version number on those links which do not use the "ethertype" encapsulation. 2) It allow evolution between several versions of IPv6. For example, we may very well come out some time later with a version which does address compression, flow-id switching, increased TTL field, whatever. 3) We have no business changing the header format once more. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 18 09:31:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08323; Thu, 18 May 95 09:31:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08317; Thu, 18 May 95 09:31:09 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23976; Thu, 18 May 1995 09:22:06 -0700 Received: from mulga.cs.mu.OZ.AU by Sun.COM (sun-barr.Sun.COM) id AA10069; Thu, 18 May 95 09:22:01 PDT Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27794 Fri, 19 May 1995 02:20:11 +1000 (from kre@munnari.OZ.AU) To: Christian Huitema Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 128) Re: Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Thu, 18 May 1995 15:04:48 +0200." <199505181304.PAA02050@mitsou.inria.fr> Date: Fri, 19 May 1995 02:18:26 +1000 Message-Id: <7710.800813906@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Thu, 18 May 1995 15:04:48 +0200 From: Christian Huitema Message-ID: <199505181304.PAA02050@mitsou.inria.fr> This is not however a reason to drop the "version" field. There are at least three very strong arguments for keeping it: I think I liked Ohta-san's 4th reason best of all, but: 2) It allow evolution between several versions of IPv6. For example, we may very well come out some time later with a version which does address compression, flow-id switching, increased TTL field, whatever. is unlikely to work ... at the relevant time, someone will point out that some IPv6 implementations are a bit slack, and will crash if presented with this new format, and so it would be imprudent to not use a new ethertype (making the version redundant again), or that using a new ethertype would allow IPv7 to be bridged while IPv6 is routed, greatly easing the transition ... kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 18 09:40:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08336; Thu, 18 May 95 09:40:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08330; Thu, 18 May 95 09:40:04 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25330; Thu, 18 May 1995 09:31:01 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA11904; Thu, 18 May 95 09:31:00 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA17991; Thu, 18 May 95 12:29:30 EDT Received: from andover.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA17155; Thu, 18 May 95 12:30:57 EDT Date: Thu, 18 May 95 12:30:57 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9505181630.AA17155@BayNetworks.com> To: brian@dxcoms.cern.ch Subject: (IPng 129) Re: Ethernet Protocol Type for IPv6 Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > From: "Brian Carpenter CERN-CN" > > > I'd like to make it clear that if we decide on a separate ethertype for IPv6 > > and want a single solution, we shouldn't allow to demux on the IP version number > > on non-ethernet links. SNAP will need to be used with other encapsulations > > (802, Q.922, IPoATM, IPoFR) or an NLPID for IPv6 will need to be requested from > > ISO. SNAP uses ethertype for de-muxing. A separate NLPID for IPv6 saves 6 bytes > > in encapsulation header (if someone cares). > > What about media where there is neither SNAP nor NLPID, > which are being used only for IP? The null encapsulation of > RFC 1483 is an example (even though it is not used by RFC 1577). > Null encapsulation is theoretically possible on any virtual > circuit medium. You must be able to run both IPv4 and IPv6 > even with null encapsulation, or else transition breaks. > Brian, What the null encapsulation of RFC 1483 (IP-over-ATM)? RFC 1483 uses SNAP or NLPID (if assigned). Regardless of this, I am not advocating removal of the version field unless there is a good technical reason to do so (I don't have any). All I wanted to point out that an unique ethertype for IPv6 can be also used to demux on medias other that Ethernet. I was suspecting that some people were under the impression that a separate ethertype is only for Ethernet and two levels of demuxing would be still needed on non-ethernet links. Regards, Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 18 10:05:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08374; Thu, 18 May 95 10:05:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08368; Thu, 18 May 95 10:05:31 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29262; Thu, 18 May 1995 09:56:29 -0700 Received: from bastion.sware.com by Sun.COM (sun-barr.Sun.COM) id AA16941; Thu, 18 May 95 09:56:19 PDT Received: from shlep.sware.com (shlep.sware.com [139.131.1.14]) by bastion.sware.com (8.6.5/8.6.5) with SMTP id MAA03863; Thu, 18 May 1995 12:55:51 -0401 Received: by shlep.sware.com (5.65/2.0) from wanda.sware.com id AA12592; Thu, 18 May 95 12:56:06 -0400 Received: by wanda.sware.com.sware.com (1.38.193.4/2.0) id AA03982; Thu, 18 May 1995 12:57:24 -0400 Date: Thu, 18 May 1995 12:57:24 -0400 From: Ed Sale Message-Id: <9505181657.AA03982@wanda.sware.com.sware.com> To: jkrawczy@BayNetworks.com Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9505172105.AA04949@BayNetworks.com> (jkrawczy@BayNetworks.com) Subject: (IPng 130) Re: Re: Ethernet Protocol Type for IPv6 Reply-To: sale@sware.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk | John Krawczyk: | | I don't know what your experience is, but here is some of mine: | | When the network turns into a "notwork", those in charge put aside | their concerns about interoperability and adherence to standards and | instead concentrate on the single goal of getting their network up and | running again, as soon as possible. I agree with you that this happens all the time. Most of us have been involved with similar situations in the past. They tend to be emotionally (and economically) charged situations with a resultant absence of sound reasoning, witness: | We have many hacks and kludges in our IPv4 code that violate | "standards" in order to deal with specific customer problems. The | reasons are various: they have some ancient buggy equipment, received | some bad advice somewhere in the past in designing their network, or | run some "novel" network applications. I anticipate the same will | happen with IPv6, since we cannot anticipate everything people will do | with this stuff (e.g., even if the IETF mandated that thou shalt not | route IPv4 and bridge IPv6, someone's going to do it). In other words, you spent time and money developing an IPv4 hybrid so that you could talk to other such hybrid systems. You should apply for a new EtherType, not the rest of us. :-) You are helping vendors who have shown the willingness to scoff at standards remain economically viable entities. This does not benefit the industry in general and leads to the perception that networks will always be "notworks" some of the time. It may also mean that a lot of us will have to spend time away from other productive work and our families travelling to our common customer sites to put kludges into our code to accomodate this new de-facto standard. This is because the customer has been led to believe that all equipment should work like it does on their networks, not like it says in the standard. Sure, it keeps us in work, just not the kind I'd like to be doing. Somebody's got to be willing to help customers understand the difference between a kludge and a solution -- it's not as easy for them as seeing the difference between duct tape and a welded joint. I agree with you that there are times when standards adherence is not an option. However, the "hacks and kludges" should be put into point-solution code, not into a general release. Customers should also be charged for this point-solution beyond the original price of the equipment to pay for the extra development effort. In this way they will again be made aware of the costs of using non-standard equipment, can identify the guilty parties and hopefully make them pay in one way or another. My argument is that the only way to avoid these circumstances is to insist that standards are adhered to. If we continue to coddle to organizations that lightly take liberties with defined standards we will be forced to resort to this kind of "Sanitation Engineering" more often, not less. If a business decision is made to "violate a standard" then the organization that made that decision should bear the burden of making a "notwork" into a "network" not all of the others that have products connected to that net. In the specific case of IPv6 breaking some IPv4-hybrid implementation, one solution would be to isolate those systems that do not adhere to the spec on a segment of their own. There are probably many others that do not resemble bowing to the vendors that provided the least standard implementation. It's unfortunate that there has been no response to what I hoped would be the more constructive part of my previous message: that we develop a test suite that establishes a minimum level of operation below which a vendor may not say that they are "IP Compatible." Passing these tests would earn the equivalent of a "Good Networking Seal of Approval." This would provide much higher assurance that implementations would cooperate and decrease the likelihood that vendors will attempt to get away with shipping defective products that we all have to deal with. -- Ed ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 18 10:11:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08386; Thu, 18 May 95 10:11:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08380; Thu, 18 May 95 10:11:31 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00276; Thu, 18 May 1995 10:02:29 -0700 Received: from nic.ott.hookup.net by Sun.COM (sun-barr.Sun.COM) id AA18170; Thu, 18 May 95 10:01:56 PDT Received: from [165.154.16.159] (kgk.ott.hookup.net [165.154.16.159]) by nic.ott.hookup.net (8.6.12/1.97) with SMTP id NAA22558; Thu, 18 May 1995 13:01:39 -0400 Message-Id: <199505181701.NAA22558@nic.ott.hookup.net> X-Sender: kgk@nic.ott.hookup.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 May 1995 13:01:35 -0500 To: ipng@sunroof.Eng.Sun.COM From: kgk@hookup.net (Keith G Knightson) Subject: (IPng 131) Semantics of the Version Number Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Gentlemen, I don't see how one can claim that all protocols are the same just because no absolute criteria exists for determining when they are different (ref John Day's insightful remark -" With your argument, IPX, Pup and CLNP are all versions of IP. In fact, one might even argue that CLNP is closer to being a version of IP than IPv6"). Is the version number a generic ISOC network layer protocol identifier, or an identifier of versions of a single ISOC protocol? If the former, then all ISOC network layer protocols, assuming they all have commonality up to the version field can be identified without the use of new ether proto type. In this case, however, all protocols AND their various versions have to be allocated unique version numbers from the same code space. If the latter, then it would seem to indicate the need for a new ether protocol type. In this case uniqueness of version numbers across different protocols would not be necessary, since each protocol would have its own code space specifically for its own versions. Will there be a need, at some point, to use the version number for possible future extensions to of IPv6 itself? There may be merit in diferentiating between small diferences within a single protocol using a version number, and major differences which indicate that it really is a different protocol (warranting the use of a different ether proto type). The former usually implies some sort graceful backwards compatibility and interoperability between versions may be possible, whereas the latter implies no such possibility. IMHO, a new ether type should be used, but the Version number should be retained for potential use within IPv6 itself. Cheers Keith ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 18 12:00:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08621; Thu, 18 May 95 12:00:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08615; Thu, 18 May 95 12:00:37 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15942; Thu, 18 May 1995 11:51:34 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA10277; Thu, 18 May 95 11:51:35 PDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA21229; Thu, 18 May 95 14:50:06 EDT Received: from maggie.wellfleet by BayNetworks.com (4.1/SMI-4.1) id AA23464; Thu, 18 May 95 14:51:32 EDT Date: Thu, 18 May 95 14:51:32 EDT From: jkrawczy@BayNetworks.com (John Krawczyk) Message-Id: <9505181851.AA23464@BayNetworks.com> Received: by maggie.wellfleet (4.1/SMI-4.1) id AA11118; Thu, 18 May 95 14:52:08 EDT To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 132) Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: <9505181657.AA03982@wanda.sware.com.sware.com> References: <9505172105.AA04949@BayNetworks.com> <9505181657.AA03982@wanda.sware.com.sware.com> Reply-To: jkrawczy@BayNetworks.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk On Thu, 18 May, Ed Sale (sale@sware.com) wrote: In other words, you spent time and money developing an IPv4 hybrid so that you could talk to other such hybrid systems. You should apply for a new EtherType, not the rest of us. :-) You are helping vendors who have shown the willingness to scoff at standards remain economically viable entities. This does not benefit the industry in general and leads to the perception that networks will always be "notworks" some of the time. Hi Ed, Actually, if it's an "economically viable entity", you usually don't have to go via the kludge route for the long term - you get them to fix it. It's the legacy systems that aren't supported anymore that worry me. One also cannot forget that the force of capitalism tends to overpower the forces of standards adherence and doing good for the benefit of the industry. If it's a question of losing a customer, you do the kludge. Explain to the stockholders that falling profits are because of "our principal of strict adherence to standards". Believe me, I'd much rather not have to do this stuff... But anyway, that's not the important part - you've hit the nail on the head here: It may also mean that a lot of us will have to spend time away from other productive work and our families travelling to our common customer sites to put kludges into our code to accomodate this new de-facto standard. This is because the customer has been led to believe that all equipment should work like it does on their networks, not like it says in the standard. Sure, it keeps us in work, just not the kind I'd like to be doing. Exactly! This is the point I was trying to make. I guess I should re-state my argument as "please do not use the same ethertype for IPv4 and IPv6 because I know that it will mean that we'll have to waste resources to do kludgy things down the road to keep our customers happy. It will be much easier to stick to the standard if the standard says to use another demux point". Or in other words, let's not give the customers the rope to hang themselves with. -jj ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 19 08:38:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09689; Fri, 19 May 95 08:38:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09683; Fri, 19 May 95 08:37:55 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12651; Fri, 19 May 1995 08:28:50 -0700 Received: from inet-gw-2.pa.dec.com by venus.Sun.COM (Sun.COM) id IAA05385; Fri, 19 May 1995 08:28:50 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA18302; Fri, 19 May 95 08:20:39 -0700 Received: by xirtlu.zk3.dec.com; id AA28607; Fri, 19 May 1995 10:30:24 -0400 Message-Id: <9505191430.AA28607@xirtlu.zk3.dec.com> To: sale@sware.com Cc: jkrawczy@baynetworks.com, ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com Subject: (IPng 133) Re: Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Thu, 18 May 95 12:57:24 EDT." <9505181657.AA03982@wanda.sware.com.sware.com> Date: Fri, 19 May 95 10:30:18 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Ed, >I agree with you that this happens all the time. Most of us >have been involved with similar situations in the past. They >tend to be emotionally (and economically) charged situations >with a resultant absence of sound reasoning, witness: When a Sales rep calls up Corp Marketing and tells the head person I can close a 5 million dollar deal with XYZ company if engineering will come in (or explain to the field engineers how to or give them patch) and make XYZ's notwork work with a kludge network it usually happens. The reason is monetary gain anytime you can get it. I doubt anyone would listen to an argument that its in the best interest of the "industry" if we tell the customer they should not do this or add XXX dollars of consulting fee to the customers purchase order. Most likely engineering can get a cost transfer for the time to fix the notwork. In theory I agree with you, in practice it will never happen and the kludges will continue forever. I have also worked for a non-vendor and will tell you when my past enterprize provided a big enough P.O. on the table the vendor would do most anything to make the "sale". But for the most part its my experience most customers adhere to the standards and in fact request them exactly as they are written. So lets write this one correct. >It's unfortunate that there has been no response to what I >hoped would be the more constructive part of my previous >message: that we develop a test suite that establishes a >minimum level of operation below which a vendor may not say >that they are "IP Compatible." Passing these tests would earn >the equivalent of a "Good Networking Seal of Approval." This >would provide much higher assurance that implementations would >cooperate and decrease the likelihood that vendors will >attempt to get away with shipping defective products that we >all have to deal with. This is a task on our implementors list though not as formal as you state. To join send mail to ipv6imp-request@munnari.oz.au. Looking for folks to help us develop such test suites. I already sent out a testing level plan I will send to your privately if you like which you can respond to on ipv6imp. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 19 09:10:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09743; Fri, 19 May 95 09:10:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09737; Fri, 19 May 95 09:09:52 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16083; Fri, 19 May 1995 09:00:49 -0700 Received: from servo (servo.Ipsilon.COM) by Sun.COM (sun-barr.Sun.COM) id AA21955; Fri, 19 May 95 08:56:17 PDT Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo (8.6.11/8.6.10) with SMTP id IAA13903; Fri, 19 May 1995 08:55:12 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 May 1995 08:56:37 -0700 To: ipng@sunroof.Eng.Sun.COM, IPv6Imp@munnari.OZ.AU From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 134) IPng Mailing Lists Cc: hinden@Ipsilon.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The IPng working group currently has two mailing lists. I would like to clarify the intended use of two mailing lists. The main list (ipng@sunroof.eng.sun.com) is for discussions of protocol changes, working group issues, overall process, schedules, meeting scheduling, etc. The implementors list (IPv6Imp@munnari.OZ.AU) is for discussions of implementation approaches, test planning, test results, test coordination, deployment, etc. Issues raised on this list which might result in changes to the IPv6 protocol should be moved to the main IPng list. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 19 09:39:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09813; Fri, 19 May 95 09:39:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09807; Fri, 19 May 95 09:38:52 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19625; Fri, 19 May 1995 09:29:47 -0700 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA28176; Fri, 19 May 95 09:29:43 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA07286; Fri, 19 May 95 07:40:41 -0700 Received: by xirtlu.zk3.dec.com; id AA28952; Fri, 19 May 1995 10:40:17 -0400 Message-Id: <9505191440.AA28952@xirtlu.zk3.dec.com> To: jkrawczy@baynetworks.com Cc: ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com Subject: (IPng 135) Re: Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Thu, 18 May 95 14:51:32 EDT." <9505181851.AA23464@BayNetworks.com> Date: Fri, 19 May 95 10:40:11 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >Exactly! This is the point I was trying to make. I guess I should >re-state my argument as "please do not use the same ethertype for IPv4 >and IPv6 because I know that it will mean that we'll have to waste >resources to do kludgy things down the road to keep our customers >happy. It will be much easier to stick to the standard if the >standard says to use another demux point". >Or in other words, let's not give the customers the rope to hang >themselves with. This is a valid point into the debate. We all know that software engineering costs are directly proportional to engineering AD then product development. Most entities probably have formulas to determine the cost and then probably some business or marketing person has to be able to state we can make XXXX dollars if we build this product, and this makes the AD cost absorbed in most cases. Etc. Etc. But I do see a potential cost as JJ points out above for IPv6. Again that its a valid point into the debate. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 19 13:48:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10255; Fri, 19 May 95 13:48:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10249; Fri, 19 May 95 13:48:22 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23192; Fri, 19 May 1995 13:39:14 -0700 Received: from bridge2.NSD.3Com.COM by Sun.COM (sun-barr.Sun.COM) id AA26903; Fri, 19 May 95 13:39:10 PDT Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA01314 (5.65c/IDA-1.4.4nsd for ); Fri, 19 May 1995 13:39:02 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA05609 (5.65c/IDA-1.4.4-910730); Fri, 19 May 1995 13:37:19 -0700 Message-Id: <199505192037.AA05609@remmel.NSD.3Com.COM> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 136) Re: Re: Re: Re: Ethernet Protocol Type for IPv6 In-Reply-To: Your message of "Thu, 18 May 1995 10:18:01 EDT." <9505181418.AA10615@BayNetworks.com> Date: Fri, 19 May 1995 13:37:19 -0700 From: Tracy Mallory Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > This is not however a reason to drop the "version" field. There are at least > > three very strong arguments for keeping it: > > > > 1) It allows demux by version number on those links which do not use the > > "ethertype" encapsulation. > > > > I'd like to make it clear that if we decide on a separate ethertype for IPv6 > and want a single solution, we shouldn't allow to demux on the IP version numbe > r > on non-ethernet links. I strongly disagree. A system that sends and receives the new ethertype but actually demuxes on the version number field is just fine. And regardless of whether it is actually used for demux, the spec. should include a MUST requirement for checking the version number. SNAP will need to be used with other encapsulations > (802, Q.922, IPoATM, IPoFR) or an NLPID for IPv6 will need to be requested from > ISO. SNAP uses ethertype for de-muxing. A separate NLPID for IPv6 saves 6 byte > s > in encapsulation header (if someone cares). (Do we know of any non-version-checking PPP implementations?) (Private replies are just fine.) I'm questionning the not-yet-fully-discussed assertion that the required use of a new ethertype generalizes to the requirement unique link-layer demuxing is required everywhere? Tracy (P.S. I think a new ethertype for IPv6 is just fine, but I wonder about the actual problem of IPv6 packets hitting non-conforming IPv4 systems. Is it really the case that the broken, legacy, systems (that don't check the ip version number) are also multicast-capable? Usable multicast for IP is relatively recent, and I'd expect most systems with IP multicast to be upgradeable. Private replies to me would be fine. Thanks.) (Dimitry: Why were ST2 packets ever hitting non-ST-capable routers/hosts?) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 19 19:05:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10497; Fri, 19 May 95 19:05:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10491; Fri, 19 May 95 19:05:09 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28842; Fri, 19 May 1995 18:56:05 -0700 Received: from servo (servo.Ipsilon.COM) by Sun.COM (sun-barr.Sun.COM) id AA11408; Fri, 19 May 95 18:56:07 PDT Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo (8.6.11/8.6.10) with SMTP id RAA17385; Fri, 19 May 1995 17:36:36 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 May 1995 17:38:00 -0700 To: ipng@sunroof.Eng.Sun.COM From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 137) IPng Working Group Interim Meeting Cc: hinden@Ipsilon.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk There will be an interim IPng working group meeting on Tuesday and Wednesday June 13 and 14, at Sun Microsystems in Mt. View, CA. The meeting may be joint with the addr autoconf w.g. Agenda topics for the meeting include: - Review new revision of Neighbor Discovery document (to be done soon). - Work on auto-config & auto-reconfig (if joint w/ addr autoconfig w.g.) - Discuss alternative addressing schemes. - Start to work on IPv6 mobility. There may also be a joint meeting of the ipng and mobile-ip working groups scheduled for Stockholm. Mt. View is about equal distant from the San Francisco and San Jose airports. A final agenda, driving directions, and other logistics will be sent in a subsequent message. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 22 09:50:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11241; Mon, 22 May 95 09:50:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11235; Mon, 22 May 95 09:49:53 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02304; Mon, 22 May 1995 09:40:46 -0700 Received: from usr.com (mailgate.usr.com) by Sun.COM (sun-barr.Sun.COM) id AA28168; Mon, 22 May 95 09:40:47 PDT Received: from robogate.usr.com ([149.112.2.203]) by usr.com (4.1/3.1.090690-US Robotics ) id AA16293; Mon, 22 May 95 11:36:53 CDT Received: from cc:Mail by robogate.usr.com id AA801168040; Mon, 22 May 95 11:16:20 CST Date: Mon, 22 May 95 11:16:20 CST From: "Pat Calhoun" Message-Id: <9504228011.AA801168040@robogate.usr.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 138) Request for CI in IPV6 header Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Since this is my first time on the IPV mailing list, I hope that I am not bringing back a topic from the dead :-) I would like to know if there has been any consideration for a 2 bit CI (Congestion Indication) field in the V6 header. Basically, these bits would be used for Frame Relay (although it is not exclusive to Frame Relay) and would allow better management of Congestion by IPV6. In today's IPV4 implementation, since there is no Congestion Indication bits, the end hosts could end up flooding a Frame Relay link. Granted, with TCP Slow Start, this situation is circumvented, but if the routers and possibly end hosts had access to the Link Congestion Management, it could make for a cleaner TCP/IP over WAN links (specifically FR). Any thoughts??? Pat R. Calhoun Lan Access R&D US Robotics Access Corp. pcalhoun@usr.com (708) 933-5181 Frame Relay Forum Member ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 22 13:06:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11390; Mon, 22 May 95 13:06:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11384; Mon, 22 May 95 13:06:40 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29081; Mon, 22 May 1995 12:57:34 -0700 Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA21278; Mon, 22 May 95 12:57:33 PDT Subject: (IPng 139) Re: Request for CI in IPV6 header To: ipng@sunroof2.Eng.Sun.COM (IPng Mailing list) Date: Mon, 22 May 1995 13:49:40 -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: <9505221849.aa06233@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I dunno. This sounds suspiciously like a job for a transport protocol, like TCP. IMHO, IPv6 is bloated enough as it is. How would these two bits get set? Who would set them, the IPv6 engine? The IPv6 engine has enough to do with neighbor discovery (which is doable, BTW), auto-config, etc. Having a link protocol (like Frame Relay) set these bits is a layering violation, but who's counting those? Also, is this congestion management supposed to take place at each hop, or at the endpoints? See the slides from a neat talk by Van Jacobson at ftp://ftp.ee.lbl.gov/talks/usenix.hsn94.ps.Z for why this should be at the endpoints. I don't like the sound of CI bits, but I'll defer total damnation to someone else. Dan McD. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 22 21:06:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11772; Mon, 22 May 95 21:06:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11766; Mon, 22 May 95 21:06:24 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23732; Mon, 22 May 1995 20:57:16 -0700 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA01438; Mon, 22 May 95 20:57:14 PDT Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Tue, 23 May 1995 12:54:53 +0859 From: Masataka Ohta Message-Id: <199505230355.MAA10426@necom830.cc.titech.ac.jp> Subject: (IPng 140) Re: Re: Request for CI in IPV6 header To: danmcd@sundance.itd.nrl.navy.mil (Dan McDonald) Date: Tue, 23 May 95 12:54:51 JST Cc: ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9505221849.aa06233@sundance.itd.nrl.navy.mil>; from "Dan McDonald" at May 22, 95 1:49 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > I dunno. This sounds suspiciously like a job for a transport protocol, like > TCP. So, it might not be a bad idea to allocate some bits from flow label for congestion control. Just recently, it was discussed in RSVP WG that it might be good to mark a policed packet to be dropped at the congestion, which means that we need some bits for marking of congestion control. > IMHO, IPv6 is bloated enough as it is. As a transport layer issue, the discussion can mostly be separated from the rest of the issues, I think. We may need a IPv6 transport layer ML. > I don't like the sound of CI bits, but I'll defer total damnation to someone > else. I'm neutral to the CI bits. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 22 23:41:32 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11794; Mon, 22 May 95 23:41:32 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11788; Mon, 22 May 95 23:41:21 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01057; Mon, 22 May 1995 23:32:14 -0700 Received: from ceres.fokus.gmd.de by Sun.COM (sun-barr.Sun.COM) id AA12935; Mon, 22 May 95 23:32:07 PDT Message-Id: <9505230632.AA12935@Sun.COM> Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Tue, 23 May 1995 08:29:02 +0200 X-Mailer: exmh version 1.6 4/21/95 To: Dan McDonald Cc: ipng@sunroof2.Eng.Sun.COM (IPng Mailing list) From: Henning Schulzrinne X-Url: http://www.fokus.gmd.de/step/hgs/ Subject: (IPng 141) Re: Re: Request for CI in IPV6 header In-Reply-To: Your message of "Mon, 22 May 1995 13:49:40 CDT." <9505221849.aa06233@sundance.itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 May 1995 08:28:14 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Congestion bits (and TCP loss-based congestion control) have the same fairness problems, particularly for flows traversing paths of different lengths. This was also the reason why the ATM Forum abandoned the EFCI bit approach for ABR and went to explicit rate control, which seems to achieve far better fairness and utilization. Thus, I see no great advantage in adding the CI bits. Henning ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 23 00:48:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11815; Tue, 23 May 95 00:48:07 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11809; Tue, 23 May 95 00:47:58 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04386; Tue, 23 May 1995 00:38:49 -0700 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA20090; Tue, 23 May 95 00:38:44 PDT Received: by mitsou.inria.fr (8.6.12/8.6.12) id JAA19252; Tue, 23 May 1995 09:38:10 +0200 Message-Id: <199505230738.JAA19252@mitsou.inria.fr> To: Henning Schulzrinne Cc: ipng@sunroof2.Eng.Sun.COM (IPng Mailing list) Subject: (IPng 142) Re: Re: Re: Request for CI in IPV6 header In-Reply-To: Your message of "Tue, 23 May 1995 08:28:14 +0200." <9505230632.AA12935@Sun.COM> Date: Tue, 23 May 1995 09:38:08 +0200 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk => Congestion bits (and TCP loss-based congestion control) have the same => fairness problems, particularly for flows traversing paths of different => lengths. This was also the reason why the ATM Forum abandoned the EFCI => bit approach for ABR and went to explicit rate control, which seems to => achieve far better fairness and utilization. Thus, I see no great => advantage in adding the CI bits. Absolutely. The congestion bit is at best an half-good idea. It is very difficult to set up a realistic triggering level. If the congestion threshold is set too low, then the CI sequence becomes very noisy and has to be subjected to heavy duty filtering before being any use. If the threshold is set too high, then the indications arrive too late and are not very useful. All in all, solutions like RED, or the combination of drop priorities with explicit scheduling (combination of fair queuing and weighted queues) perform better. There is no need for this. Besides, this is a virtual circuit design, ill fitted to a real datagram network. Don't change the spec. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 23 01:04:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11831; Tue, 23 May 95 01:04:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11825; Tue, 23 May 95 01:04:21 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05298; Tue, 23 May 1995 00:55:13 -0700 Received: from bells.cs.ucl.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA21386; Tue, 23 May 95 00:55:03 PDT Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 23 May 1995 08:54:17 +0100 To: Henning Schulzrinne Cc: Dan McDonald , ipng@sunroof2.Eng.Sun.COM (IPng Mailing list) Subject: (IPng 143) Re: Re: Re: Request for CI in IPV6 header In-Reply-To: Your message of "Tue, 23 May 95 08:28:14 +0100." <9505230632.AA12935@Sun.COM> Date: Tue, 23 May 95 08:54:09 +0100 Message-Id: <793.801215649@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >Congestion bits (and TCP loss-based congestion control) have the same >fairness problems, particularly for flows traversing paths of different >lengths. This was also the reason why the ATM Forum abandoned the EFCI >bit approach for ABR and went to explicit rate control, which seems to >achieve far better fairness and utilization. Thus, I see no great >advantage in adding the CI bits. Henning by coincidence, we were just discussing the history of ICMP source quench, and why it was hard to do anything smart with it - at least anything much smarter than TCP already does with the implicit loss notification it gets from packet loss sure, ICMP soruce quench comes back a tad sooner (i..e after an RTT to bottleneck gateway ratehr than after an RTT to the sink), but i) you don't know what high watermark the rotuer people have triggered the soruce quench on ii) the router doesn't know the relative dfelays to the sources that are filling its queues, so can't estimate easily what is the best person to quenech (could behave like a RED router though as a first approximation) iii) its problematical if you have UDP mbone style traffic as well as TCP traffic in fact, one can imagine a scenario dearly beloved of ATM people where there is a TCP over IP over an end to end ATM path, and congestion notification from the udnerlying EFCI at the ABR/ATM layer is passed right through IP to the TCP layer - one could, but a more relaistic scenario is that the End to End path is only partly built out of ATM, andf that at least the first and last hops are (say) switched ether hubs or even just straight multiple hops of other "legacy" internet.....then you have to map the ABR EFCI into a new form of ICMP source quench - say a ICMP Explicit Window Indication for TCP, (IE WIT) for example this might be a good thing, and then again it might not.... jon ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 23 05:08:49 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11892; Tue, 23 May 95 05:08:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11886; Tue, 23 May 95 05:08:38 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14982; Tue, 23 May 1995 04:59:31 -0700 Received: from charon.siemens.be by Sun.COM (sun-barr.Sun.COM) id AA14706; Tue, 23 May 95 04:59:14 PDT Received: by charon.siemens.be (5.65c/charon-0) id ; Tue, 23 May 1995 13:55:50 +0200 with SMAPD Received: from atea.atea.be(193.210.197.11) by charon via smap (V1.3mjr) id sma008293; Tue May 23 13:55:36 1995 Received: from atdec1.ATEA.BE by atea.atea.be with SMTP (1.37.109.4/15.6-FW) id AA24213; Tue, 23 May 95 13:58:40 +0100 Received: from vnet by atdec1.atea.be (5.65/Ultrix3.0-C) id AA02282; Tue, 23 May 1995 13:58:29 +0200 Received: by vnet.atea.be; Tue, 23 May 95 13:58:34 +0100 Date: Tue, 23 May 95 13:58:32 +0100 Message-Id: From: (Lode Coene) To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 144) Re: request for CI in IPV6 header X-Incognito-Sn: 319 X-Incognito-Format: VERSION=1.60g ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Congestion indication doesn't do an thing for reducing the congestion itself if it is included in the IP header. Perhaps, it might be of use in the interface between the linklayer and the networklayer but it should NOT be included in the messageheader itself. There is much more use for some form of priority scheme and a policy for assigning priorities by a application to message which setup some form of connection(sorry for the word)/dialogue/transaction , the continueation of the connection/.. and the breakdown of the connection/.... This policy should kick in when congestion occurs. The setup msg should have the lowest prioriy, continue should occupy the middle ground and the breakdown msg should have the higgest priority. Every node should do its duty when it runs into congestion and drop the messages with the lowest priority. As far as I can see, congestion control is something that is the responsability of every node along the route. The end node may not have enough information to detect a congestion somewhere in the network. It should at least go in the direction of what Christian proposes. Yours sincerly Lode Coene ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 23 06:42:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11941; Tue, 23 May 95 06:42:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11935; Tue, 23 May 95 06:42:06 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18899; Tue, 23 May 1995 06:32:59 -0700 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA23723; Tue, 23 May 95 06:32:52 PDT Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Tue, 23 May 1995 22:28:52 +0859 From: Masataka Ohta Message-Id: <199505231329.WAA13650@necom830.cc.titech.ac.jp> Subject: (IPng 145) Re: Re: request for CI in IPV6 header To: P82609@vnet.atea.be (Lode Coene) Date: Tue, 23 May 95 22:28:51 JST Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: ; from "Lode Coene" at May 23, 95 1:58 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Congestion indication doesn't do an thing for reducing the congestion itself > if it is included in the IP header. Perhaps, it might be of use in the > interface between the linklayer and the networklayer but it should NOT be > included in the messageheader itself. It's information for the transport layer collected from link layer segments. Anyway, anything which must be checked and/or modified hop by hop by routers quickly should be placed in a fixed place of IP heder, even if it actually belongs to the transport layer. > There is much more use for some form of priority scheme and a policy for > assigning priorities by a application to message Perhaps. And that is the reason why we have a TClass field, which is a form of priority scheme and a policy for assigning priorities by a application to message. And, maybe, CI is a bad idea. But, how, do you think, about the fact that the TClass field IS included in the messageheader itself? Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 23 07:43:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11966; Tue, 23 May 95 07:43:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11960; Tue, 23 May 95 07:43:32 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22450; Tue, 23 May 1995 07:34:25 -0700 Received: from usr.com (mailgate.usr.com) by Sun.COM (sun-barr.Sun.COM) id AA01878; Tue, 23 May 95 07:34:25 PDT Received: from robogate.usr.com ([149.112.2.203]) by usr.com (4.1/3.1.090690-US Robotics ) id AA22311; Tue, 23 May 95 09:30:31 CDT Received: from cc:Mail by robogate.usr.com id AA801246915; Tue, 23 May 95 09:23:05 CST Date: Tue, 23 May 95 09:23:05 CST From: "Pat Calhoun" Message-Id: <9504238012.AA801246915@robogate.usr.com> To: ipng@sunroof2.Eng.Sun.COM, "Dan McDonald" Cc: tsocolof@usr.com Subject: (IPng 146) Re: Re: Request for CI in IPV6 header Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Dan, I guess I was hoping to get away with this question without getting into too many protocol details (I suppose my initial question was more to see if anything was in the works). While I agree that this sounds like a layering violation, it is not necessary so. Most Frame Relay switches support RFC1490, which allow them to do some nifty things to certain IP messages (i.e. ARP). There is nothing to stop the switches from setting these two bits... Anyways, for your first question, who sets up these bits. Initially, I suppose the Router (FR->Eth) would set this bit to inform the endpoints that congestion is occurring on the WAN link. Second, how do these two bits get set, well the Frame Relay supports Congestion Management (ala ANSI T1.606). A bit called FECN (Forward Explicit Congestion Notification) is set when the Frame Relay must start setting the DE (discard eligibility) bit on certain packets that cause the total throughput to exceed a user subcribed limitation (or switch throughput limitation). Once the congestion is cleared, a packet with the BECN (Backward Explicit Congestion Notification) set is sent to the endpoint. Now, is congestion management managed at each hop and at the endpoint? I suppose the answer is no. The management should only occur at the endpoint (for controlling the flow of data) and the FR-Eth router which will set this bit. Maybe in the future, if these bits exist, they could get set by the FR switch??? But that is another story. The total benefit of these two bits??? CLEAN TCP/IP over Frame Relay... In today's implementation many FR vendors oversubscribe their Frame Relay switches, which causes massive packet drops and the current implementation cannot deal with this properly (of course, there is slow-start). My idea would be that instead of flodding the WAN and constantly re-adjusting the windows, simply get notification from the router that there is congestion. OK. now, what are the side-effects.... For Lan users.... NONE!! for Frame Relay users with a router which does not support this feature.... NONE (since it will operate as it does today). For lucky Frame Relay users... LOTS!!! Pat R. Calhoun Lan Access R&D US Robotics Access Corp. pcalhoun@usr.com (708) 933-5181 Frame Relay Forum Member ______________________________ Reply Separator _________________________________ Subject: (IPng 139) Re: Request for CI in IPV6 header Author: "Dan McDonald" at Internet Date: 5/22/95 3:22 PM I dunno. This sounds suspiciously like a job for a transport protocol, like TCP. IMHO, IPv6 is bloated enough as it is. How would these two bits get set? Who would set them, the IPv6 engine? The IPv6 engine has enough to do with neighbor discovery (which is doable, BTW), auto-config, etc. Having a link protocol (like Frame Relay) set these bits is a layering violation, but who's counting those? Also, is this congestion management supposed to take place at each hop, or at the endpoints? See the slides from a neat talk by Van Jacobson at ftp://ftp.ee.lbl.gov/talks/usenix.hsn94.ps.Z for why this should be at the endpoints. I don't like the sound of CI bits, but I'll defer total damnation to someone else. Dan McD. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 23 23:59:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12579; Tue, 23 May 95 23:59:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12573; Tue, 23 May 95 23:59:24 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24465; Tue, 23 May 1995 23:50:11 -0700 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA28017; Tue, 23 May 95 23:50:08 PDT Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA11493; Wed, 24 May 1995 16:50:01 +1000 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA25870; Wed, 24 May 95 16:28:45 +1000 Date: Wed, 24 May 95 16:28:45 +1000 Message-Id: <9505240628.AA25870@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au; Wed, 24 May 95 16:57:36 +1100 Resent-Date: Wed, 24 May 95 16:14:15 +1100 Resent-Message-Id: Resent-From: Alan.Lloyd@datacraft.com.au From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 147) re: Request for CI in IPV6 header X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Forwarded to: internet[ipng@sunroof.eng.sun.com] cc: Comments by: Alan Lloyd@Marketing@DCTHQ -------------------------- [Original Message] ------------------------- Re this congestion stuff ie FECN and BECN, etc. I have a phylosophical problem with them anyway. If a network with n nodes in gets congested somewhere and the respective nodes sets these bits, what is the algorithm for relaying these bits back to the originator source. ie By the time they get back has the congestion cleared? If the condition persists what does a connection less service do? Hold off for what period, What does the application do, because by definition it should not send another packet. Also in a datagram network that spans the planet with multiple paths how does one know what path any specific datagram took (specifically with dynamically allocated links?) So what does an application do if some IP packets hit Frame relay/atm services and some dont. So interesting concept - flow controlling datagrams BUT. I dont think it worth the trouble resolving this by setting bits in Internet packets by the link layers (integrity?) or what does one do at the application to service them? Also does the last point also apply to RSVP? How does one target a reservation path for a IP datagram (with and RSVP datagram) in a global network to allocate network resource for another datagram which may flow through different nodes (depending on traffic). Just thoughts Regards alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 24 10:04:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12713; Wed, 24 May 95 10:04:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12602; Wed, 24 May 95 00:24:05 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25899; Wed, 24 May 1995 00:14:56 -0700 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA03577; Wed, 24 May 95 00:14:52 PDT Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA12574; Wed, 24 May 1995 17:14:38 +1000 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA25931; Wed, 24 May 95 16:51:03 +1000 Received: by dcthq2.datacraft.com.au; Wed, 24 May 95 17:19:55 +1100 Date: Wed, 24 May 95 17:02:08 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 148) addressing architecture doc (bob.hinden) X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk a couple of quereies can any one help with few lines. What is the "Neutral Interconnect" addressing used for? The formats permitted in 2.4.1 say that an E.164 or an 802 address can be used at the LS end. How does one determine this format in directing the datagram. And I am still perplexed on the ISDN/B-ISDN interworking issues with IP6 - E.164 address mapping, multicasting over B-ISDN / ISDN, etc. As the carrier networks move to digital ISDN for voice/data integration AND circuits will be allocated on demand using E.164 addrs (and these will be charged on packets passed and call duration), what are the approaches to getting IP6 to work over switched services. More importantly what IP services break with a connection oriented (on demand) network- eg does discovery/ RSVP break. Either the IP layer will require a reasonable degree of directory support and connection management or perhaps some optimisation can be made in some cases by IP+E.164 addressing in a consistent manner. In this case we need to have a clear format definition AND we need to resolve the administration issues. ie IP bit = registeries, E.164 = ITU or national bodies. Hopefully both schemes when combined but considered seperately will relate to a common point (region /country/state) on the planet. please advise regards alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 25 16:52:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13655; Thu, 25 May 95 16:52:48 PDT Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13649; Thu, 25 May 95 16:52:40 PDT Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id QAA21813; Thu, 25 May 1995 16:43:28 -0700 Received: by kandinsky.Eng.Sun.COM (5.x/SMI-SVR4) id AA09616; Thu, 25 May 1995 16:45:50 -0700 Date: Thu, 25 May 1995 16:45:50 -0700 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9505252345.AA09616@kandinsky.Eng.Sun.COM> To: addrconf@cisco.com, ipng@sunroof, ngtrans@sunroof Subject: (IPng 149) Directions for IPng interim meeting Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Sun Microsystems will be hosting the interim joint meeting of the IPng, addrconf and ngtrans working groups: Dates: Tuesday and Wednesday June 13 and 14 Time: 9:00 am - 6:00 pm Location: Sparcys Conference Room Sun Building 21 2675 Coast Ave, Mt. View, California. Local Host: Bob Gilligan (gilligan@eng.sun.com) Here are directions to Sun building 21: FROM SAN JOSE: Travel Highway 101 Northbound Exit at San Antonio Road Turn right at stop sign (San Antonio Rd) Continue straight through stoplight to Casey ave. Turn right on Casey Ave. Turn right at Marine Way (first street). Turn left at Coast Ave (first street). Building 21 is on your left, on the corner of Coast and Marine. Park in lot and proceed to building lobby. FROM SAN FRANCISCO: Travel Highway 101, Southbound Exit at San Antonio Road North (There is a North and a South exit, North is the second exit) Travel over the freeway. Continue straight through stoplight to Casey ave. Turn right on Casey Ave. Turn right at Marine Way (first street). Turn left at Coast Ave (first street). Building 21 is on your left, on the corner of Coast and Marine. Park in lot and proceed to building lobby. FROM MILPITAS: Travel 237 to Mountain View Exit at Highway 101, Northbound Exit at San Antonio Road Turn right at stop sign (San Antonio Rd) Continue straight through stoplight to Casey ave. Turn right on Casey Ave. Turn right at Marine Way (first street). Turn left at Coast Ave (first street). Building 21 is on your left, on the corner of Coast and Marine. Park in lot and proceed to building lobby. FROM FREMONT: Travel Highway 84, Westbound After crossing bridge, turn the very first left, this is University Avenue Follow University Avenue to Highway 101, Southbound Exit at San Antonio Road North (There is a North and a South exit, North is the second exit) Travel over the freeway. Continue straight through stoplight to Casey ave. Turn right on Casey Ave. Turn right at Marine Way (first street). Turn left at Coast Ave (first street). Building 21 is on your left, on the corner of Coast and Marine. Park in lot and proceed to building lobby. When you arrive, tell the receptionist that you are here for the IPng meeting. You will be directed to the meeting room, which is located just off to the right of the lobby, next to the Sun cafeteria. There will be NO MBONE service for this meeting. This conference room is not network-connected, and we do not have the proper audio equipment. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat May 27 11:17:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14683; Sat, 27 May 95 11:17:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14677; Sat, 27 May 95 11:17:07 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19362; Sat, 27 May 1995 11:07:53 -0700 Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA22704; Sat, 27 May 95 11:07:54 PDT Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3917; Sat, 27 May 95 14:06:43 EDT Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" id 3527; Sat, 27 May 1995 14:06:43 EDT Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Sat, 27 May 95 14:06:43 EDT Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA48797; Sat, 27 May 1995 14:06:41 -0400 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9505271806.AA48797@hawpub1.watson.ibm.com> To: mobile-ip@Tadpole.COM, ipng@sunroof.Eng.Sun.COM Subject: (IPng 150) Mobile-IP for IP version 6 In-Reply-To: (Your message of Fri, 26 May 95 19:53:21 EST.) <9505262353.AA50534@hawpub1.watson.ibm.com> Date: Sat, 27 May 95 14:06:41 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk For a long time, I have been maintaining the mobile-IP document as a "dual-purpose" document, which by a macro switch can be turned into a IPv6 protocol specification. My intention was to give the ultimate in "fidelity", should the IPng working group decide to adopt the protocol devised by the IPv4 working group. However, on the advice of various interested parties, I have not released this document. I believe the time is finally right, since mobility is on the agenda for the upcoming IPng interim working group meeting next month. I do not claim that the mobile-IP working group has approved this document, or that it actually is a perfect translation of the IPv4 document -- although I have tried to make sure that it would be. Moreover, I am personally much more favorable to an alternate protocol specification that we sent out for comments last October or so. I intend to send an updated version of the other document in for consideration within a week or so. I offer the translated document mainly for everyone's convenience in understanding how the IPv4 protocol might look in IPv6. The proposed translation is being sent in as an Internet Draft, and is also available as draft-perkins-mobility-ipv6-00.txt on software.watson.ibm.com. Lastly, I admit that this document submission was done fairly hastily, and your patience is requested in advance. I will gladly incorporate suggested improvements, even before the IPv6 interim meeting. Regards, Charlie P. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 29 05:16:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15026; Mon, 29 May 95 05:16:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15020; Mon, 29 May 95 05:16:28 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01843; Mon, 29 May 1995 05:07:13 -0700 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA02553; Mon, 29 May 95 05:05:59 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch id AA05719; Mon, 29 May 1995 14:03:08 +0200 Received: by dxcoms.cern.ch id AA06624; Mon, 29 May 1995 14:03:05 +0200 Message-Id: <9505291203.AA06624@dxcoms.cern.ch> Subject: (IPng 151) NOSI status report To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Date: Mon, 29 May 1995 14:03:04 +0200 (MET DST) 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 Status of NOSI work ------------------- This is a brief report for the IPNG WG on the status of the NOSI ("Next Generation and OSI") work. There have been two NOSI BOFs at San Jose and Danvers. The object was to identify requirements and mechanisms for the OSI community to converge on IPv6 as a network layer. The result is a two-pronged approach - - upper layer convergence (ISO Transport over TCP i.e. RFC1006bis, ISO Transport over IPv6, or ISO CLNP over IPv6). All these are feasible and can be architected as elective standards. A new BOF in the transport Area is scheduled in Stockholm to carry these forward. - address convergence (restricted or truncated ISO NSAPs used to address IPv6 packets, and IPv6 addresses embedded in ISO format) A revised Internet Draft on the address convergence mechanisms will shortly be posted. At Stockholm I will ask the IPNG WG to endorse its progression to Experimental RFC status. There is still an issue about the routability of such addresses in the global Internet, hence the experimental status. Regards, Brian Carpenter (CERN) (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 30 17:29:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15642; Tue, 30 May 95 17:29:12 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15636; Tue, 30 May 95 17:29:03 PDT Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id RAA05426; Tue, 30 May 1995 17:19:45 -0700 Received: by kandinsky.Eng.Sun.COM (5.x/SMI-SVR4) id AA12383; Tue, 30 May 1995 17:22:10 -0700 Date: Tue, 30 May 1995 17:22:10 -0700 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9505310022.AA12383@kandinsky.Eng.Sun.COM> To: addrconf@cisco.com, ipng@sunroof, ngtrans@sunroof Subject: (IPng 152) Hotels for IPng interim meeting Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk A couple of people have asked about hotels for the IPng interim meeting being held June 14-15 at Sun in Mountain View. Here are some hotels which are located within about 5 miles of Sun: Holiday Inn Palo Alto 625 El Camino Real Palo Alto, CA 94301 415-328-2800 Hyatt Rickeys 4219 El Camino Real Palo Alto, CA 94306 415-493-8000 Residence Inn by Marriott Mountain View 1854 W. E. Camino Real Mountain View, CA 94040 415-940-1300 Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 30 18:08:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15717; Tue, 30 May 95 18:08:16 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15711; Tue, 30 May 95 18:08:08 PDT Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id RAA08644; Tue, 30 May 1995 17:58:49 -0700 Received: by kandinsky.Eng.Sun.COM (5.x/SMI-SVR4) id AA12528; Tue, 30 May 1995 18:01:13 -0700 Date: Tue, 30 May 1995 18:01:13 -0700 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9505310101.AA12528@kandinsky.Eng.Sun.COM> To: addrconf@cisco.com, ipng@sunroof, ngtrans@sunroof Subject: (IPng 153) re: Hotels for IPng interim meeting Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk My previous note regarding hotels incorrectly said that the interim meeting would be held June 14 and 15. It will actually be held Tuesday and Wednesday June 13 and 14, as announced in earlier email messages. Sorry for the confusion! Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com