From owner-ipng Wed Mar 1 11:54:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12462; Wed, 1 Mar 95 11:54:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12348; Wed, 1 Mar 95 04:46:25 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27577; Wed, 1 Mar 1995 04:38:05 -0800 Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA05410; Wed, 1 Mar 95 04:37:59 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA11274; Wed, 1 Mar 95 04:26:00 -0800 Received: by xirtlu.zk3.dec.com; id AA29378; Wed, 1 Mar 1995 07:25:53 -0500 Message-Id: <9503011225.AA29378@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: Re: (IPng) WG last call: v6 ICMP draft In-Reply-To: Your message of "Tue, 28 Feb 95 21:09:02 PST." <95Feb28.210914pst.12174@skylark.parc.xerox.com> Date: Wed, 01 Mar 95 07:25:46 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > ICMP for the Internet Protocol Version 6 (IPv6) > draft-ietf-ipngwg-icmp-01.txt I support this document moving to proposed standard. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 1 11:54:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12466; Wed, 1 Mar 95 11:54:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12367; Wed, 1 Mar 95 07:22:17 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04406; Wed, 1 Mar 1995 07:15:03 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA14330; Tue, 28 Feb 95 13:28:29 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09280; 28 Feb 95 14:33 EST 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 Subject: (IPng) I-D ACTION:draft-ietf-ipngwg-icmp-01.txt Date: Tue, 28 Feb 95 14:33:33 -0500 Message-Id: <9502281433.aa09280@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --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 : ICMP for the Internet Protocol Version 6 (IPv6) Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-icmp-01.txt Pages : 17 Date : 02/27/1995 This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). The Internet Group Management Protocol (IGMP) messages specified in RFC-1112 have been merged into ICMP, for IPv6, and are included in this document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-icmp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-icmp-01.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) 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-icmp-01.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: <19950227164002.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950227164002.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 1 11:54:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12463; Wed, 1 Mar 95 11:54:20 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12373; Wed, 1 Mar 95 07:49:04 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id HAA10280; Wed, 1 Mar 1995 07:41:50 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id HAA01306; Wed, 1 Mar 1995 07:41:49 -0800 Date: Wed, 1 Mar 1995 07:41:49 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503011541.HAA01306@elrond.Eng.Sun.COM> To: ipsec@ans.net, tytso@MIT.EDU, ipng@sunroof Subject: (IPng) Re: the silly bit X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ted, Your comment : > Or is what's *really* going on is this bit is saying "this SAID is for > SKIP", and what we're *really* doing is reserving one bit for the > exclusive use of SKIP? That seems unacceptable to me. is, I think, not quite fair. While SKIP is the only in-band keying protocol being actively proposed for IPSEC and IPv6, other examples have been given of protocols that use in-band keying, viz., DEC's. One of the litanies we constantly here about IETF work is that it should be based on actual implementation experience. SKIP is implemented and working in the field. The people working on SKIP are not trying to force others to use in-band keying in general or SKIP in particular. They are saying they would like a way to do in-band keying in both IPv4 and IPv6 in a standard way. This is a reasonable request. > If you need to do in-line key management, why can't that be done by > defining some new, optional transforms that include extra fields which > are especially designed for in-line key management, instead of trying to > kludge it into the SAID? Then, the SAID is used as it's originally > intended to be used --- as an index into a connection table which will > indicate how the rest of the packet needs to be processed --- including > any possible in-line key management, if necessary. When a packet arrives, the only field that is available for indicating that the header contains in-band information, at least with the ESP proposed format, is the SAID or the synchronization field. Since the synchronization field format is dependent on the SAID, this forces designers who want to do in-band keying to use something about the SAID field to indicate this. There is no pre-existing SAID value that the receiver will have cached to determine that the header specifies in-band keying. The SAID value will be allocated after the packet is processed. > I'm not convinced that, as proposed, the reserved bit will actually do > any good (besides wasting one half of the SAID space). I agree with you about taking up a bit in the SAID. I think a special SAID value should be used to indicate that the next field(s) carry additional information about the key management protocol. Since there are already SAID values "reserved for future work," one of these can be chosen. e.g., the SAID value consisting of all ones. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 1 11:54:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12468; Wed, 1 Mar 95 11:54:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12356; Wed, 1 Mar 95 06:37:30 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01895; Wed, 1 Mar 1995 06:30:17 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA17953; Wed, 1 Mar 95 06:30:05 PST Received: from relay.imsi.com by wintermute.imsi.com id JAA22895; Wed, 1 Mar 1995 09:29:58 -0500 Received: from snark.imsi.com by relay.imsi.com id JAA02137; Wed, 1 Mar 1995 09:29:57 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA10566; Wed, 1 Mar 95 09:29:42 EST Message-Id: <9503011429.AA10566@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Proposed Standard or no? In-Reply-To: Your message of "Tue, 28 Feb 1995 15:26:18 PST." <9502282326.AA02831@miraj.> X-Reposting-Policy: redistribute only with permission Date: Wed, 01 Mar 1995 09:29:41 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ashar Aziz says: > > From: "Perry E. Metzger" > > You can't ignore it. If the machine owner can say "gee, I'd like to > > use SKIP" then the kernel has to have the hooks, doesn't it? > > No, it doesn't. Show me code that deals with this without kernel hooks or the use of something like BPF. I just plain do not believe you -- period. I've been working on implementation and I do not see how the packets can be directed without the use of code. If you have an implementation that doesn't require kernel hacks, lets see it. .pm ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 1 11:54:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12465; Wed, 1 Mar 95 11:54:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12334; Wed, 1 Mar 95 04:06:05 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26137; Wed, 1 Mar 1995 03:58:51 -0800 Received: from sg543689.eng.chrysler.com by Sun.COM (sun-barr.Sun.COM) id AA01892; Wed, 1 Mar 95 03:58:51 PST Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id GAA24534 for ; Wed, 1 Mar 1995 06:58:49 -0500 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id GAA23673 for ; Wed, 1 Mar 1995 06:58:48 -0500 Received: from bobsgrid.is.chrysler.com by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA28416; Wed, 1 Mar 95 07:14:16 EST Message-Id: <9503011214.AA28416@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 01 Mar 1995 06:58:37 -0500 To: Danny.Nessett@Eng (Dan Nessett), ipng@sunroof.Eng.Sun.COM, ipsec@ans.net From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: (IPng) Re: Proposed Standard or no? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 02:31 PM 2/24/95 -0800, Dan Nessett wrote: >Folks, > >I originally sent my email on in-band signalling of keying material to both >the IPSEC and IPv6 mailing lists, since the issues are identical to each. > >Right now we have the following people who think in-band signalling should be >allowed : > >IPSEC WG >-------- > >hugo@watson.ibm.com >rgm3@is.chrysler.com >nessett@eng.sun.com >markson@osmosys.incog.com >ashar@osmosys.incog.com > Hold it there. I said work it out. Is there a reason not to support the proposed change to SAIDs to allow in-band signaling. I am not a security expert. I am a security user. I expect you people to hash this out reasonably fast (one week max) and get on the the spec... Robert Moskowitz Chrysler Corporation (810) 758-8212 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 1 14:16:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12705; Wed, 1 Mar 95 14:16:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12699; Wed, 1 Mar 95 14:16:45 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19415; Wed, 1 Mar 1995 14:09:31 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA27691; Wed, 1 Mar 95 14:09:24 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm036-23.dialip.mich.net [141.211.7.65]) by merit.edu (8.6.10/merit-2.0) with SMTP id RAA19052 for ; Wed, 1 Mar 1995 17:09:17 -0500 Date: Wed, 1 Mar 95 17:43:09 GMT From: "William Allen Simpson" Message-Id: <4080.bsimpson@morningstar.com> To: ipsec@ans.net Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: the silly bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM This thread was not on IPng, and I firmly object to you bothering them with it. I, for one, will not be replying to this thread on any list in the future. > From: Danny.Nessett@eng.sun.com (Dan Nessett) > implementation experience. SKIP is implemented and working in the field. > This is, as I've mentioned before, utter bullshit. SKIP is supposedly a "key management proposal". Please show us the key management, particularly the deployed X.509 certificate database. SKIP uses completely different certificates from the (non-deployed) PEM. Deployment of SKIP is not likely to be any faster than PEM. > There is no pre-existing SAID value that the receiver will have cached > to determine that the header specifies in-band keying. The SAID value will > be allocated after the packet is processed. > Sender assigned SAID values are not allowed in IP Security. All SAID values are assigned per Destination. This is a requirement. SKIP as currently written does not meet our requirements. > I agree with you about taking up a bit in the SAID. I think a special SAID > value should be used to indicate that the next field(s) carry additional > information about the key management protocol. Since there are already > SAID values "reserved for future work," one of these can be chosen. e.g., > the SAID value consisting of all ones. > I suggested this in the first message in this thread. In order to receive this value, you will need to write a security transform draft. You have not supplied the draft. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 1 14:22:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12750; Wed, 1 Mar 95 14:22:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12388; Wed, 1 Mar 95 08:10:49 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB07951; Wed, 1 Mar 1995 08:03:35 -0800 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU) by Sun.COM (sun-barr.Sun.COM) id AA02900; Wed, 1 Mar 95 08:03:29 PST Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA24551; Wed, 1 Mar 95 11:02:40 EST Received: by dcl.MIT.EDU (5.0/4.7) id AA29116; Wed, 1 Mar 1995 11:02:39 +0500 Date: Wed, 1 Mar 1995 11:02:39 +0500 From: Theodore Ts'o Message-Id: <9503011602.AA29116@dcl.MIT.EDU> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) [Theodore Ts'o: Re: the silly bit] Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM By request of a member of the ipng list, I'm forwarding this message which I had sent to the ipsec list. I expect further discussion to take place on ipsec, not ipng. Among other reasons, I'm not on the ipng list, so please don't send mail argueing with me there. I won't be reading it. :-) - Ted ------- Forwarded Message Date: Tue, 28 Feb 1995 21:41:35 +0500 From: Theodore Ts'o To: ipsec@ans.net In-Reply-To: William Allen Simpson's message of Tue, 28 Feb 95 21:33:26 GMT, <4061.bsimpson@morningstar.com> Subject: Re: the silly bit Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1104 Quite frankly, I'm a little bit puzzled by this whole discussion --- what's the point of designating a bit which means "this SAID is structured", when the structure of the SAID isn't being standardizied? What are implementations supposed to do differently when they detect that this bit is set? Or is what's *really* going on is this bit is saying "this SAID is for SKIP", and what we're *really* doing is reserving one bit for the exclusive use of SKIP? That seems unacceptable to me. If you need to do in-line key management, why can't that be done by defining some new, optional transforms that include extra fields which are especially designed for in-line key management, instead of trying to kludge it into the SAID? Then, the SAID is used as it's originally intended to be used --- as an index into a connection table which will indicate how the rest of the packet needs to be processed --- including any possible in-line key management, if necessary. I'm not convinced that, as proposed, the reserved bit will actually do any good (besides wasting one half of the SAID space). - Ted ------- End Forwarded Message ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 1 14:39:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12852; Wed, 1 Mar 95 14:39:07 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12846; Wed, 1 Mar 95 14:38:59 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id OAA28480; Wed, 1 Mar 1995 14:31:45 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id OAA01893; Wed, 1 Mar 1995 14:31:44 -0800 Date: Wed, 1 Mar 1995 14:31:44 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503012231.OAA01893@elrond.Eng.Sun.COM> To: ipsec@ans.net, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: the silly bit X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From bsimpson@morningstar.com Wed Mar 1 14:11:59 1995 > To: ipsec@ans.net > Cc: ipng@sunroof.Eng.Sun.COM > Subject: (IPng) Re: the silly bit > > This thread was not on IPng, and I firmly object to you bothering them > with it. I, for one, will not be replying to this thread on any list in > the future. Since Bill will not be responding to this thread, allow me to explain to others why I sent this to the IPng list. Anyone who has read both the I-Ds submitted by Ran to IPng and the I-Ds written by Bill and Perry for IPsec will note the high degree of similarity. Both specify SAIDs in a way that prevents in-band signalling of keying material. This issue (and many others) are common to both efforts. While I believe IPv6 need not follow the direction being set by IPsec, including both communities in a discussion of common issues, I think, is prudent. It widens the base of expertise, allowing more insight to be gained by the participants. While I can get as irritated as anyone about certain issues, I think it is best to attempt to remain objective and courteous in email exchanges, rather than using them as a blunt instrument. If I have bothered anyone other than Bill, Perry or Ran by posting my discussions of the in-band signalling issues to both the ipsec and ipng mailing lists, please let me know. I am not trying to irritate people. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 1 15:09:32 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12921; Wed, 1 Mar 95 15:09:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12915; Wed, 1 Mar 95 15:09:24 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25134; Wed, 1 Mar 1995 15:02:10 -0800 Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA08183; Wed, 1 Mar 95 15:01:29 PST Message-Id: <9503012301.AA08183@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7853; Wed, 01 Mar 95 17:56:37 EST Date: Wed, 1 Mar 95 17:56:37 EST From: yakov@watson.ibm.com To: ipng@sunroof.Eng.Sun.COM, Christian.Huitema@sophia.inria.fr Subject: (IPng) Provider-based addressing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Wed, 22 Feb 1995 10:36:35 +0100 Christian, >Another reason is that structure of BGP (or IDRP) which carries >administrative preferences rather than plain metrics. Small reality check: IDRP for IPv6 carries RD hop count and path bandwidth. If there is consensus the document could be augmented to include delay and error rate. So, while your assertion about BGP is correct, your assertion about IDRP is incorrect. Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 1 16:43:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12995; Wed, 1 Mar 95 16:43:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12989; Wed, 1 Mar 95 16:43:37 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04193; Wed, 1 Mar 1995 16:36:18 -0800 Received: from titan.sprintlink.net by Sun.COM (sun-barr.Sun.COM) id AA24907; Wed, 1 Mar 95 16:36:05 PST Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id TAA02101 for ipng@sunroof.Eng.Sun.COM; Wed, 1 Mar 1995 19:35:50 -0500 Date: Wed, 1 Mar 1995 19:35:50 -0500 From: Vadim Antonov Message-Id: <199503020035.TAA02101@titan.sprintlink.net> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Provider-based addressing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Christian wrote: >> Another reason is that structure of BGP (or IDRP) which carries >> administrative preferences rather than plain metrics. Yakov wrote: >Small reality check: > IDRP for IPv6 carries RD hop count and path bandwidth. If there is > consensus the document could be augmented to include delay and error rate. >So, while your assertion about BGP is correct, your assertion about IDRP >is incorrect. Would you please stop for a second to listen to somebody who actually runs a large network? Physical metrics MAKE NO SENSE in the real life. Please. I tried to use them in a sensible way and found that it is impossible (SprintLink used to have cisco IGRP on the backbone). They only are useful if they depend on traffic -- i.e. instead of "bandwidth" there should be "available bandwidth", instead of "delay" -- "average latency, including time spent in queues". The path bandwidth (non-additive) metric is particularly ridiculous, because metrics on slow access circuits completely shadow metrics of the high-speed backbone circuits, and it is the backbone links which usually are forming alternative paths. Since nobody figured out how to do sensible traffic-dependent routing yet, the only useful alternative is administrative distances. Even when there are "plain metrics" the real life forces network administrators to feed bogus information to the routing algoriths to achieve the desired effect. It is simply a twisted way to do administrative metrics. As a plea from network operators -- pleeeease, we don't need fancy metric toys; we need some simple and robust tools to do various routing policies. Like the per-hop BGP metrics i asked Yakov for. --vadim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 1 17:31:01 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13024; Wed, 1 Mar 95 17:31:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13018; Wed, 1 Mar 95 17:30:54 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09581; Wed, 1 Mar 1995 17:23:38 -0800 Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA05177; Wed, 1 Mar 95 17:23:37 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA11183; Wed, 1 Mar 95 17:02:01 -0800 Received: by xirtlu.zk3.dec.com; id AA24990; Wed, 1 Mar 1995 20:01:55 -0500 Message-Id: <9503020101.AA24990@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: the silly bit In-Reply-To: Your message of "Wed, 01 Mar 95 14:31:44 PST." <199503012231.OAA01893@elrond.Eng.Sun.COM> Date: Wed, 01 Mar 95 20:01:49 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan, >note the high degree of similarity. Both specify SAIDs in a way that prevents >in-band signalling of keying material. This issue (and many others) are >common to both efforts. While I believe IPv6 need not follow the direction >being set by IPsec, including both communities in a discussion of common >issues, I think, is prudent. It widens the base of expertise, allowing >more insight to be gained by the participants. I am only responding to ipng as I don't want to be the cause of overload on the mail list. Please forward this response if proper to ipsec. I think I am on that list now and will be for sure soon. Have not seen any mail yet though. At this point I am convinced that if our IPv6 Security Architecture is not able to support both in-band and out-band key management then I question whether it is flexible enough. I think we need both. If that cannot be technically accomplished with the present drafts then I think that is a valid issue for an objection to last call, in addition to other issues I have all ready raised with no response at this point to me privately or on the mail list. I figure Ran like me is completely snowed under trying to get specs out the door prior to Danvers. So I am not beating up on Ran here or anyone. Its strictly an issue of whether a spec is ready for proposed standard. This note is to express my support of your continued drilling of the IPv6 security specification which all in their hearts want you to do cause we have to get this right. Otherwise I would not have responded. I will add that you have remained in your responses a professional which is hard to do at times. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 2 00:48:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13098; Thu, 2 Mar 95 00:48:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13092; Thu, 2 Mar 95 00:48:15 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02520; Thu, 2 Mar 1995 00:41:01 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA28996; Thu, 2 Mar 95 00:41:02 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-08.dialip.mich.net [141.211.7.144]) by merit.edu (8.6.10/merit-2.0) with SMTP id DAA14083 for ; Thu, 2 Mar 1995 03:40:59 -0500 Date: Tue, 28 Feb 95 21:10:05 GMT From: "William Allen Simpson" Message-Id: <4094.bsimpson@morningstar.com> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) Last Calls - Unicast Assignment Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Resend, as I have not seen the echo: > An Architecture for IPv6 Unicast Address Allocation > draft-ietf-ipngwg-arch-addr-01.txt > > An IPv6 Global Unicast Address Format > draft-ietf-ipngwg-address-format-01.txt > > alternative > addressing architectures and formats may and, we hope, will be specified > in the future, at which point they will go through the same process of > WG review.) > Given the above promise, I will write one of these alternatives. Since I have long been opposed to these documents, I will first repeat my opposition: - does not adequately address multi-homed and multi-provider networks, - assumes static layering, - does not provide for rapid re-addressing. - formalizes a treework, rather than a network. - results in political "ownership" of address blocks. Also, they assign too large a site/subscriber part, given the (false) assumption that we need many heirarchical layers of addressing. Therefore, they are not self-consistent. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 2 07:07:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13329; Thu, 2 Mar 95 07:07:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13323; Thu, 2 Mar 95 07:06:51 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18587; Thu, 2 Mar 1995 06:59:36 -0800 Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AA06665; Thu, 2 Mar 95 06:59:36 PST Received: by research.att.com; Thu Mar 2 09:50 EST 1995 Received: from roc (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (8.6.9/8.6.5) with ESMTP id JAA00171; Thu, 2 Mar 1995 09:50:04 -0500 Message-Id: <199503021450.JAA00171@smb.research.att.com> From: Steve Bellovin To: ipsec@ans.net, ipng@sunroof.Eng.Sun.COM Subject: (IPng) problems with SKIP Date: Thu, 02 Mar 1995 09:50:02 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM There appear to be some serious problems with the current SKIP draft. Some of these seem to apply to the DEC scheme as well. First, the stream cipher mode doesn't work well, and in particular is not very general. The draft says that MI ``is simply the count of bytes that have already been encrypted in key Kp'', and is 64 bits long. But using a counter only works if packets are in order; arbitrary stream ciphers cannot be cranked backwards, though clearly some can (such as DES in OFB mode). If the new counter is much higher than the last one received, the receiving host may have to turn the crank forward very far. This can lead to denial of service attacks; an attacker can flood the recipient with many bogus packets with wildly different byte counts. While there are some stream ciphers for which neither of these objections apply -- say, encrypting a byte counter with a block cipher to produce an XOR stream -- in the general case the idea appears to be unworkable. SKIP's in-band key negotiation makes it difficult to revoke a compromised certificate. A host may have a cached copy of the old certificate and to use when computing the long-term key Kij. But such packets will be rejected by the recipient, since they won't decrypt properly. Nor will either party know why, unless the receiving machine sends a special bounce message any time decryption fails, if that happens between the revocation time and the normal expiration time of the certificate (and that period could be several years, per the draft). Note the possibility here for a denial of service attack on the the certificate directory: after a revocation, the attacker sends lots of messages with forged source addresses to some target. This causes the bounce messages, which in turn would cause the nominal senders of the packets (who had received the bounce messages) to query the directory server for a current certificate. It isn't clear how one side can force the use of different session keys for each connection between a given pair of hosts. While it can choose different session keys itself, there is no way for it to tell the other side to do so. A number of attacks are possible under these circumstances, especially if a stream cipher is used. The most serious problem, though, is that SKIP makes it very difficult to reject a compromised session key. Suppose that an I have somehow obtained some session key, along with the encryption of it using the long-term key Kij. This isn't impossible, as I may have years to work on it. I can now send fraudulent packets, using the address and Kij encryption from an original packet. Since Kij will remain constant for a very long time, and since by definition the receiving host has no input into the key generation process, it has no way of detecting the forgery. Granted, the attacker has no way of seeing the output from the target host, as it will have its own session key, but as we've seen in the last few weeks, one can quite easily launch certain attacks without ever seeing any output. I can think of a few ways to try to patch SKIP to get around this, such as encrypting the current time with Kij, but the real problem is much deeper: in an avowedly ``stateless'' scheme, the receiving host has no part in the key generation, and hence can't forbid old or bad keys. This problem appears to affect the DEC scheme as well, though it may be repairable there. With the DEC scheme (does it have a name?), the key-encrypting key is private to the receiving host, and thus can be changed at any time. If the generated session keys all expire at the same time, and the KEK is changed at the same instant, old session keys will fail. I would expect a bit of churn for a few seconds on either side of the changeover time, but that might be acceptable. There are other minor problems with SKIP (cleartext algorithm identifiers, a bit to indicate compression, etc., but the problems I've outlined above seem to me to be very serious, and arguably fatal. --Steve Bellovin ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 2 10:24:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13401; Thu, 2 Mar 95 10:24:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13395; Thu, 2 Mar 95 10:24:06 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08113; Thu, 2 Mar 1995 10:16:51 -0800 Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA20862; Thu, 2 Mar 95 10:16:50 PST Message-Id: <9503021816.AA20862@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0085; Thu, 02 Mar 95 13:16:48 EST Date: Thu, 2 Mar 95 13:16:47 EST From: yakov@watson.ibm.com To: brian@dxcoms.cern.ch, ipng@sunroof.Eng.Sun.COM Subject: (IPng) National Registry of Routing is Harmful Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Tue, 21 Feb 1995 13:37:43 +0100 (MET) Brian, >If you go for a geographical address hierarchy, in a competitive >multiprovider network, you will need a FIX in every city >unless you are prepared to flat route... Observe that this FIX is nothing, but a provider. And since there should be only one FIX per city, this creates a bonafide monopoly that is introduced by the FIX. Upon deeper introspection one could see that hierarchical routing, no matter whether it is "provider-based" or "geography-based", tends to create "monopolistic situations". The only question on the table is what kind of counter-measures would be available to counteract this monopolistic nature of hierarchical routing. Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 2 12:15:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13507; Thu, 2 Mar 95 12:15:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13501; Thu, 2 Mar 95 12:15:40 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22223; Thu, 2 Mar 1995 12:08:26 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA18002; Thu, 2 Mar 95 12:08:25 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14626(2)>; Thu, 2 Mar 1995 12:08:12 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Thu, 2 Mar 1995 12:08:02 -0800 To: yakov@watson.ibm.com Cc: brian@dxcoms.cern.ch, ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) National Registry of Routing is Harmful In-Reply-To: yakov's message of Thu, 02 Mar 95 10:16:47 -0800. <9503021816.AA20862@Sun.COM> Date: Thu, 2 Mar 1995 12:07:55 PST From: Steve Deering Message-Id: <95Mar2.120802pst.12174@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Yakov, > ...since there should be only one FIX per city, this creates a bonafide > monopoly that is introduced by the FIX. This does not contradict your point, but note that you can (and probably should, for robustness sake) have multiple, redundant FIXes within a city (or, rather "MIXes", for "metropolitan internet exchanges"). Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 2 12:16:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13519; Thu, 2 Mar 95 12:16:44 PST Received: from eunuchs.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13513; Thu, 2 Mar 95 12:16:36 PST Received: by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA23806; Thu, 2 Mar 1995 12:09:23 +0800 Received: from snail.Sun.COM by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA23788; Thu, 2 Mar 1995 12:09:19 +0800 Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA26118; Thu, 2 Mar 95 12:09:16 PST Received: from ns.incog.com by Sun.COM (sun-barr.Sun.COM) id AA18124; Thu, 2 Mar 95 12:09:07 PST Received: by ns.incog.com (8.6.10/94082501) id MAA17788; Thu, 2 Mar 1995 12:09:33 -0800 Received: from osmosys.incog.com by ns.incog.com (8.6.10/94082501) id MAA17772; Thu, 2 Mar 1995 12:09:04 -0800 Received: from miraj. (miraj.incog.com) by osmosys.incog.com (5.x/SMI-SVR4) id AA08087; Thu, 2 Mar 1995 12:08:19 -0800 Received: by miraj. (5.x/SMI-SVR4) id AA03658; Thu, 2 Mar 1995 12:06:04 -0800 Date: Thu, 2 Mar 1995 12:06:04 -0800 From: ashar@icgmail.Eng.Sun.COM (Ashar Aziz) Message-Id: <9503022006.AA03658@miraj.> To: ipsec@ans.net, ipng@sunroof.Eng.Sun.COM X-Sun-Charset: US-ASCII X-Icg-Mailfrom: ashar@icgmail.eng.sun.com Content-Length: 8886 Subject: Re: (IPng) problems with SKIP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >From: Steve Bellovin Steve, Thanks for the comments. I will respond to some of your other points later, but I'll address these first. (Incidentally, I am responding to ipng as well, but this discussion might be more appropriate for ipsec, since this doesn't relate to encapsulation formats). >First, the stream cipher mode doesn't work well, and in particular >is not very general. The draft says that MI ``is simply the count >of bytes that have already been encrypted in key Kp'', and is 64 >bits long. But using a counter only works if packets are in order; >arbitrary stream ciphers cannot be cranked backwards, though clearly >some can (such as DES in OFB mode). If the new counter is much >higher than the last one received, the receiving host may have to >turn the crank forward very far. This can lead to denial of service >attacks; an attacker can flood the recipient with many bogus packets >with wildly different byte counts. While there are some stream >ciphers for which neither of these objections apply -- say, encrypting >a byte counter with a block cipher to produce an XOR stream -- in >the general case the idea appears to be unworkable. You are correct about the possibility of denial-of-service (d-o-s) attacks on stream ciphers with byte counters. Our implementation at the moment does some things to prevent this sort of attack. In particular it keeps track of current offsets, and has a notion of what reasonable offset differences can be, even given out-of-order arrival of packets. This doesn't completely eliminate all possible d-o-s but can help, in that wildly different counter values are ignored. However, this really isn't a SKIP issue per se. The issue is generic to how one does stream ciphers at the IP layer. The same issues would apply to any other key-mgmt scheme that would use a stream cipher of the RC4 variety. Also, this doesn't mean that because of the possibility of d-o-s attacks, one shouldn't use this mode of operation, because there may be environments where confidentiality and performance are greater considerations than d-o-s. All environments don't suffer from the same threat possibilities. > The most serious problem, though, is that SKIP makes it very > difficult to reject a compromised session key. Suppose that an I > have somehow obtained some session key, along with the encryption > of it using the long-term key Kij. This isn't impossible, as I > may have years to work on it. I can now send fraudulent packets, > using the address and Kij encryption from an original packet. > Since Kij will remain constant for a very long time, and since by > definition the receiving host has no input into the key generation > process, it has no way of detecting the forgery. Granted, the > attacker has no way of seeing the output from the target host, as > it will have its own session key, but as we've seen in the last > few weeks, one can quite easily launch certain attacks without ever > seeing any output. The issue you raise, (essentially a known key attack) has been raised in the past on ipsec by Hugo. At the last IETF meeting, I presented a zero-message way of updating the SKIP master key (Kij) that eliminates this attack. Essentially the master key becomes a function of a counter (that is communicated in the packet) that only runs forward. (This modification was also discussed on the ipsec list soon after the IETF meeting, under the subject zero-message master key update.) If a session key is ever compromised, (but the master key is not) it cannot be replayed because the attacker will not know the encryption of Kp under the current Kij. The IETF presentation slides explained how the counter can be implemented as a function of time units since the more recent of I or J's certificate. Since the counter never runs backwards, it isn't possible to reuse past compromised keys. With this modification, there are no known-key attacks on SKIP that I am aware of. Incidentally, the type of attack you cite (known key attack), applies to Photuris as well. Compromise of a session's secret DH exponent allows the party that connected to later impersonate the party whose session exponent was compromised. I have described this in the past, although there hasn't yet been agreement on the correct way to fix this. The SKIP draft hasn't yet been updated to reflect the master key update mechanism that I described above, and I am working on updating the draft. > This problem appears to affect the DEC scheme as well, though it > may be repairable there. With the DEC scheme (does it have a > name?), the key-encrypting key is private to the receiving host, > and thus can be changed at any time. If the generated session keys > all expire at the same time, and the KEK is changed at the same > instant, old session keys will fail. I would expect a bit of churn > for a few seconds on either side of the changeover time, but that > might be acceptable. I believe that this situation is not applicable to the DEC scheme, because keys are not established by sending them encrypted in the per node master key. A key-negotiation protocol is employed to establish the session key, so if the key-negotiation protocol doesn't suffer from key playback weaknesses, neither will the DEC scheme. (Charlie Kaufmann can correct me if am wrong). Regards, Ashar. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 2 13:02:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13580; Thu, 2 Mar 95 13:02:58 PST Received: from eunuchs.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13574; Thu, 2 Mar 95 13:02:46 PST Received: by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA24539; Thu, 2 Mar 1995 12:55:33 +0800 Received: from snail.Sun.COM by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA24521; Thu, 2 Mar 1995 12:55:28 +0800 Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AB28601; Thu, 2 Mar 95 12:55:27 PST Received: from ns.incog.com by Sun.COM (sun-barr.Sun.COM) id AA27339; Thu, 2 Mar 95 12:55:25 PST Received: by ns.incog.com (8.6.10/94082501) id MAA18678; Thu, 2 Mar 1995 12:55:51 -0800 Received: from osmosys.incog.com by ns.incog.com (8.6.10/94082501) id MAA18663; Thu, 2 Mar 1995 12:55:45 -0800 Received: from miraj. (miraj.incog.com) by osmosys.incog.com (5.x/SMI-SVR4) id AA09064; Thu, 2 Mar 1995 12:55:01 -0800 Received: by miraj. (5.x/SMI-SVR4) id AA03762; Thu, 2 Mar 1995 12:52:44 -0800 Date: Thu, 2 Mar 1995 12:52:44 -0800 From: ashar@icgmail.Eng.Sun.COM (Ashar Aziz) Message-Id: <9503022052.AA03762@miraj.> To: ipsec@ans.net, ipng@sunroof.Eng.Sun.COM X-Sun-Charset: US-ASCII X-Icg-Mailfrom: ashar@icgmail.eng.sun.com Content-Length: 5007 Subject: (IPng) Re: problems with SKIP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Steve Bellovin > SKIP's in-band key negotiation makes it difficult to revoke a > compromised certificate. A host may have a cached copy of the old > certificate and to use when computing the long-term key Kij. But > such packets will be rejected by the recipient, since they won't > decrypt properly. Nor will either party know why, unless the > receiving machine sends a special bounce message any time decryption > fails, if that happens between the revocation time and the normal > expiration time of the certificate (and that period could be several > years, per the draft). Steve, CRL distribution is supposed to be much more frequent than certificate validity periods. If your CRL has expired, (and the CRL format that is specified in SKIP I-D is the same type as in RFC 1422, where there is a "next-issue-date" field") then, possibly under policy control, you stop operation. One doesn't wait for the expiry date of the certificate if the CRL directory has been suppressed through denial-of-service. If one doesn't have an up-to-date CRL, then the certificate cannot be considered to be any good. This is precisely why there is a "next-issue-date" in the RFC 1422 CRL format. Once a new CRL is issued, all cached certificates are purged from any local cache (including cached Kijs). Note that far more serious attacks than denial-of-service are possible if a certificate has been compromised and CRLs are suppressed, including outright impersonation. > It isn't clear how one side can force the use of different session > keys for each connection between a given pair of hosts. While it > can choose different session keys itself, there is no way for it > to tell the other side to do so. A number of attacks are possible > under these circumstances, especially if a stream cipher is used. The fact that each source of encrypted traffic should use different traffic keys is an important part of SKIP. SKIP accomplishes this not just for the case of a pairwise connection, (the easy part) but also for the far trickier case of multicast traffic. This is accomplished by each source of traffic (for both unicast and multicast IP) to randomly generate its own traffic key encrypted in either Kij for the case of unicast IP or the Group Interchange Key (GIK) for the case of multicast IP. So, e.g., in case of a TCP connection, each side automatically uses different keys for each direction of encrypted traffic, allowing the use of any kind of stream cipher and eliminating the possibility of key-stream reuse scenarios. Regards, Ashar. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 02:57:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13950; Fri, 3 Mar 95 02:57:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13944; Fri, 3 Mar 95 02:57:03 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24257; Fri, 3 Mar 1995 02:49:48 -0800 Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA23878; Fri, 3 Mar 95 02:49:46 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA16390; Fri, 3 Mar 95 05:06:07 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA01530; Fri, 3 Mar 95 04:49:17 CST Date: Fri, 3 Mar 95 04:49:17 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9503031049.AA01530@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re (IPng) Last Calls - Unicast Assignment Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > a reaction on William Allen Simpson's message: > > > alternative addressing architectures and formats may and, > > we hope, will be specified in the future, at which point they > > will go through the same process of WG review. > > Given the above promise, I will write one of these alternatives. > Since I have long been opposed to these documents, I will first repeat > my opposition: > (1) does not adequately address multi-homed and multi-provider networks, > (2) assumes static layering, > (3) does not provide for rapid re-addressing. > (4) formalizes a treework, rather than a network. > (5) results in political "ownership" of address blocks. > (6) Also, they assign too large a site/subscriber part, given the > (false) assumption that we need many heirarchical layers of > addressing. Therefore, they are not self-consistent. On (1) Multihoming/multiprovider. True, true and true. But can we define an alternative that allows for address abstraction? If you can do so; please... Dirty fixes? Lets say we have a network connected to two providers A and B Provider A has an address prefix "a" of n bits. (a/n) Provider B has an address prefix "b" of n bits. (b/n) My network uses address prefix "a-c" of n+m bits. (ac/n+m) I have a router to A with address "a-c-d". (acd/128) I have a router to B with address "b-e", (be/128) and an address "a-c-f". (acf/128) My connection to A goes to A's router "a-g", (ag/128) My connection to B goes to B's router "b-h", (bh/128) ((((((((((((the backbone))))))))) | | +---+----+ +----+----+ | A | | B | | | | | | ag | | bh | +--+-----+ +---+-----+ | | | | +-------+ | | | +---+-----------------+----+ | acd acf\be | | my network | +--------------------------+ router bh gets the info from be that net ac/n+m is reachable, but also learns via BGP or IDRP that a/n is reachable. he can send a test message with source route: to acf. As long as that test message is answered, bh nows that a connection between A and the site network ac is alive and bh can ignore the advertizement of be. As soon as the test message is not answered, bh nows that ac/n+m is isolated from a/n and he needs to pick up the advertizement to re-establish the connection. If connection ag-acd is alive, B does not have to advertize ac/n+m, so address abstraction works and we keep the routing information small If connection ag-acd is dead, B starts to advertize ac/n+m, NO address abstraction but this should only happen in exeptional situations and only with a small set of all multi-homed sites. Fred Rabouw ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 02:58:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13962; Fri, 3 Mar 95 02:58:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13956; Fri, 3 Mar 95 02:58:33 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24277; Fri, 3 Mar 1995 02:51:16 -0800 Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA23992; Fri, 3 Mar 95 02:51:08 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA16393; Fri, 3 Mar 95 05:07:30 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA01533; Fri, 3 Mar 95 04:50:40 CST Date: Fri, 3 Mar 95 04:50:40 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9503031050.AA01533@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re2 (IPng) Last Calls - Unicast Assignment Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > a reaction on William Allen Simpson's message: > > > alternative addressing architectures and formats may and, > > we hope, will be specified in the future, at which point they > > will go through the same process of WG review. > > Given the above promise, I will write one of these alternatives. > Since I have long been opposed to these documents, I will first repeat > my opposition: > (1) does not adequately address multi-homed and multi-provider networks, > (2) assumes static layering, > (3) does not provide for rapid re-addressing. > (4) formalizes a treework, rather than a network. > (5) results in political "ownership" of address blocks. > (6) Also, they assign too large a site/subscriber part, given the > (false) assumption that we need many heirarchical layers of > addressing. Therefore, they are not self-consistent. On (2) static layering Hmmmm, yes? I see they propose we can have three layers in the address as "a" proposal, not as "the" proposal ..... Fred Rabouw ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 02:59:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13985; Fri, 3 Mar 95 02:59:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13968; Fri, 3 Mar 95 02:59:01 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24296; Fri, 3 Mar 1995 02:51:46 -0800 Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA24074; Fri, 3 Mar 95 02:51:43 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA16399; Fri, 3 Mar 95 05:08:05 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA01536; Fri, 3 Mar 95 04:51:15 CST Date: Fri, 3 Mar 95 04:51:15 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9503031051.AA01536@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re3 (IPng) Last Calls - Unicast Assignment Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > a reaction on William Allen Simpson's message: > > > alternative addressing architectures and formats may and, > > we hope, will be specified in the future, at which point they > > will go through the same process of WG review. > > Given the above promise, I will write one of these alternatives. > Since I have long been opposed to these documents, I will first repeat > my opposition: > (1) does not adequately address multi-homed and multi-provider networks, > (2) assumes static layering, > (3) does not provide for rapid re-addressing. > (4) formalizes a treework, rather than a network. > (5) results in political "ownership" of address blocks. > (6) Also, they assign too large a site/subscriber part, given the > (false) assumption that we need many heirarchical layers of > addressing. Therefore, they are not self-consistent. On (3) rapid re-addressing. Bill's documents on IPv6 neighbour discovery allow a router to tell endstations to change the address prefix. rapid re-addressing can be done by lifting the prefix-change option to protocols as OSPF, RIP and BGP and by that allow an internet backbone router to dictate the change the prefix of a whole site. (1) That puts a heavy burden on DNSv6. (2) This option will be easier to define if the number of bits in the site/subsriber part if fixed for every backbone/provider. If internet-backbone-provider X allows each site below him to have a site/subscriber part of 64 bits, And internet-backbone-provider Y dictates each site below him to have a site/subscriber part of 32 bits, A change from X to Y will not only require a prefix change, but also a change of all subnet and host addresses. If X and Y have the same size for the site/subscriber part, a prefix change will not require a host number change. Fred Rabouw ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 02:59:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13997; Fri, 3 Mar 95 02:59:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13991; Fri, 3 Mar 95 02:59:29 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24316; Fri, 3 Mar 1995 02:52:12 -0800 Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA24110; Fri, 3 Mar 95 02:52:11 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA16402; Fri, 3 Mar 95 05:08:32 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA01539; Fri, 3 Mar 95 04:51:42 CST Date: Fri, 3 Mar 95 04:51:42 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9503031051.AA01539@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re4 (IPng) Last Calls - Unicast Assignment Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > a reaction on William Allen Simpson's message: > > > alternative addressing architectures and formats may and, > > we hope, will be specified in the future, at which point they > > will go through the same process of WG review. > > Given the above promise, I will write one of these alternatives. > Since I have long been opposed to these documents, I will first repeat > my opposition: > (1) does not adequately address multi-homed and multi-provider networks, > (2) assumes static layering, > (3) does not provide for rapid re-addressing. > (4) formalizes a treework, rather than a network. > (5) results in political "ownership" of address blocks. > (6) Also, they assign too large a site/subscriber part, given the > (false) assumption that we need many heirarchical layers of > addressing. Therefore, they are not self-consistent. On (4) a treework. This is due to the fact that we see no way to scale the internet to span the world (and allow a biljoen subscribers somewhere in the futere) without having an hierarchical address structure. What we need is a picture of how the internet will be structured in the future: How many backbone providers? Where do we expect interconnections? Will geographical boundaries indeed be natural boundaries for the internet topology? The stucturing of the IPv6 unicast address in "dratf-ietf-ipngwg-address-format-01" is such that: There will be a hierarchy in the administration of addresses (which implies: address blocks are owned). We all know that administrative structures will tend to exist as long as possible and takes years to change. The topology of any network, including the future internet will change quickly as user demand for bandwidth increases. I'm afraid that the proposed (hierarchical) address structure within five years will no longer match the topology of the internet and all expected gains in the abstraction of the routing information will vanish. Please note that Bill's point 4 and point 1 are strongly related, multi-homing will be the first violation of a tree-structure. But soon more will come since providers might decide to change their connection from one backbone to another. With the draft on IPv6 unicats allocation, can we control how all subscribers change their prefixes ..... ? Fred Rabouw. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 03:00:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14009; Fri, 3 Mar 95 03:00:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14003; Fri, 3 Mar 95 02:59:56 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24340; Fri, 3 Mar 1995 02:52:41 -0800 Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA24151; Fri, 3 Mar 95 02:52:39 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA16406; Fri, 3 Mar 95 05:09:01 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA01542; Fri, 3 Mar 95 04:52:11 CST Date: Fri, 3 Mar 95 04:52:11 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9503031052.AA01542@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re5 (IPng) Last Calls - Unicast Assignment Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > a reaction on William Allen Simpson's message: > > > alternative addressing architectures and formats may and, > > we hope, will be specified in the future, at which point they > > will go through the same process of WG review. > > Given the above promise, I will write one of these alternatives. > Since I have long been opposed to these documents, I will first repeat > my opposition: > (1) does not adequately address multi-homed and multi-provider networks, > (2) assumes static layering, > (3) does not provide for rapid re-addressing. > (4) formalizes a treework, rather than a network. > (5) results in political "ownership" of address blocks. > (6) Also, they assign too large a site/subscriber part, given the > (false) assumption that we need many heirarchical layers of > addressing. Therefore, they are not self-consistent. On (5) "ownership" of address blocks. True. The question is: Can we organize the future internet in such a way that each subscriber can choose between several providers? Preferable different providers which are connected to different backbone segments. If so and if we can rapid re-address a network, it doesn't matter that the addresses are "owned" somewhere as long as we can quickly change the provider. If we don't want addresses to be owned somewhere we need complete dynamic addressing and a complete different DNS. I'm afraid that is too big a change to be accepted by most network managers. Fred Rabouw ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 03:00:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14022; Fri, 3 Mar 95 03:00:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14016; Fri, 3 Mar 95 03:00:33 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24355; Fri, 3 Mar 1995 02:53:18 -0800 Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA24204; Fri, 3 Mar 95 02:53:09 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA16416; Fri, 3 Mar 95 05:09:31 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA01550; Fri, 3 Mar 95 04:52:41 CST Date: Fri, 3 Mar 95 04:52:41 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9503031052.AA01550@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re6 (IPng) Last Calls - Unicast Assignment Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > a reaction on William Allen Simpson's message: > > > alternative addressing architectures and formats may and, > > we hope, will be specified in the future, at which point they > > will go through the same process of WG review. > > Given the above promise, I will write one of these alternatives. > Since I have long been opposed to these documents, I will first repeat > my opposition: > (1) does not adequately address multi-homed and multi-provider networks, > (2) assumes static layering, > (3) does not provide for rapid re-addressing. > (4) formalizes a treework, rather than a network. > (5) results in political "ownership" of address blocks. > (6) Also, they assign too large a site/subscriber part, given the > (false) assumption that we need many heirarchical layers of > addressing. Therefore, they are not self-consistent. On (6): too large a site/subscriber part. Since most people seem to tend to use the IEEE LAN address as IPv6 host address we immediately "have to give" 48 bits to the site/subscriber part of the address. If we then want to allow routing internally in a site we have to "give away" some extra bits. I agree that offering 16 bits looks a lot (it gives every site effectively an old class A address), but since that still leaves 64 bits to the providers and above it shouldn't cause problems. As Christian Huitema has shown in RFC1715, in the top 64 bits of the IPv6 address the world should be able to organize 6000 biljoen sites. (See RFC1715, take H=0.2 and take 64 bits as address length, gives us 6000 bijoen addressable objects as practical to handle in that address range) So a split of the 128 bit in 64 bits for each site to work with and 64 bits for the combinded internet providers allows us to address dozens of (Class A size) networks per person for the next century. Also a fixed split between the prefix and the site/subscriber part makes dynamic and rapid re-addressing easier .... Fred Rabouw ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 04:36:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14114; Fri, 3 Mar 95 04:36:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14108; Fri, 3 Mar 95 04:36:07 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB01069; Fri, 3 Mar 1995 04:28:35 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA05462; Fri, 3 Mar 95 04:28:27 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 3 Mar 95 21:27:08 +0900 From: Masataka Ohta Message-Id: <9503031227.AA24608@necom830.cc.titech.ac.jp> Subject: Re: Re (IPng) Last Calls - Unicast Assignment To: ipng@sunroof.Eng.Sun.COM Date: Fri, 3 Mar 95 21:27:07 JST In-Reply-To: <9503031049.AA01530@anubis.network.com>; from "Fred Rabouw (Gouda office)" at Mar 3, 95 4:49 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > On (1) Multihoming/multiprovider. > > True, true and true. > > But can we define an alternative that allows for address abstraction? > If you can do so; please... Today there are hierarchically addressed strictly provider based telephoney networks and flat routed provider free IP networks. Now, some people are saying that, with magical routing, telephoney addressing scheme can offer enough provider independence. But, it is not proven in the real world test. On the other hand, multihoming and other forms of provider independence are the existing real world requirements. OK? > My network uses address prefix "a-c" of n+m bits. (ac/n+m) > I have a router to A with address "a-c-d". (acd/128) > I have a router to B with address "b-e", (be/128) > and an address "a-c-f". (acf/128) Already to complex to me. But, let's see the consequence. > ((((((((((((the backbone))))))))) > | | > +---+----+ +----+----+ > | A | | B | > | | | | > | ag | | bh | > +--+-----+ +---+-----+ > | | > | | > +-------+ | > | | > +---+-----------------+----+ > | acd acf\be | > | my network | > +--------------------------+ > If connection ag-acd is dead, B starts to advertize ac/n+m, NO address abstraction Provier B can advertise the prefix of the other provider: A? It makes administraiton between providers complex. Moreover, the advertisement is harmful if the failure mode is like: > ((((((((((((the backbone))))))))) > | | > +---+----+ +----+----+ > | A | | B | > | | | | > | ag | | bh | > +--+-----+ +---+-----+ > | | > | | > +-------+ | > | | > +---+-------- -----+----+ > | acd \ \acf\be | > | my network\ \ | > +-------------- --------+ That is, if B's advertisement of ac/n+m is valid, acd can not be reached. > Dirty fixes? Sorry, but, Dirty no fixes. What we need is NOT a magically complex routing scheme that is never tested in the real world but a simple addressing scheme. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 04:46:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14130; Fri, 3 Mar 95 04:46:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14124; Fri, 3 Mar 95 04:46:45 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB01660; Fri, 3 Mar 1995 04:39:29 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA06317; Fri, 3 Mar 95 04:39:28 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 3 Mar 95 21:38:02 +0900 From: Masataka Ohta Message-Id: <9503031238.AA24682@necom830.cc.titech.ac.jp> Subject: Re: Re6 (IPng) Last Calls - Unicast Assignment To: ipng@sunroof.Eng.Sun.COM Date: Fri, 3 Mar 95 21:38:00 JST In-Reply-To: <9503031052.AA01550@anubis.network.com>; from "Fred Rabouw (Gouda office)" at Mar 3, 95 4:52 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Since most people seem to tend to use the IEEE LAN address as IPv6 host address we > immediately "have to give" 48 bits to the site/subscriber part of the address. If As I have already pointed out several monthes ago, given more than 2^32 of world population, 48bit not-so-tightly-packed space is too small for a large number of hosts in the near future. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 04:53:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14160; Fri, 3 Mar 95 04:53:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14148; Fri, 3 Mar 95 04:53:33 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB01817; Fri, 3 Mar 1995 04:46:17 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA06844; Fri, 3 Mar 95 04:46:16 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 3 Mar 95 21:44:59 +0859 From: Masataka Ohta Message-Id: <9503031245.AA24708@necom830.cc.titech.ac.jp> Subject: Re: Re4 (IPng) Last Calls - Unicast Assignment To: ipng@sunroof.Eng.Sun.COM Date: Fri, 3 Mar 95 21:44:57 JST In-Reply-To: <9503031051.AA01539@anubis.network.com>; from "Fred Rabouw (Gouda office)" at Mar 3, 95 4:51 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > On (4) a treework. > > This is due to the fact that we see no way to scale the internet to span the world > (and allow a biljoen subscribers somewhere in the futere) without having an > hierarchical address structure. Wrong. Just make the top most routing layer large enough (several thousands or several nudreds of thousands) and treework disappears. > Will geographical boundaries indeed be natural boundaries for the > internet topology? Geographical boundaries are natural. They will be "a" cause of boundaries for the internet topology. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 05:18:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14201; Fri, 3 Mar 95 05:18:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14195; Fri, 3 Mar 95 05:18:51 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02715; Fri, 3 Mar 1995 05:11:36 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA09197; Fri, 3 Mar 95 05:11:32 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 3 Mar 95 22:10:11 +0900 From: Masataka Ohta Message-Id: <9503031310.AA24788@necom830.cc.titech.ac.jp> Subject: Re: Re3 (IPng) Last Calls - Unicast Assignment To: ipng@sunroof.Eng.Sun.COM Date: Fri, 3 Mar 95 22:10:09 JST In-Reply-To: <9503031051.AA01536@anubis.network.com>; from "Fred Rabouw (Gouda office)" at Mar 3, 95 4:51 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > a reaction on William Allen Simpson's message: > On (3) rapid re-addressing. > > Bill's documents on IPv6 neighbour discovery allow a router to tell endstations to > change the address prefix. > > rapid re-addressing can be done by lifting the prefix-change option to protocols as > OSPF, RIP and BGP and by that allow an internet backbone router to dictate the > change the prefix of a whole site. > > (1) That puts a heavy burden on DNSv6. Good point. While Bill has kindly summariesd the points which my proposal already solved, I haven't yet documented how this side of re-addressing issue can be solved. For re-addressing, we must perform two things. One is the reconfiguration of hosts, which can be covered by router advertisement. The other is the announcement of the change, which is related to DNS. It is surely an administrative burden, if we must change IPv6 address RRs of all the related hosts. Dynamic update is not so useful here. Because an organizational network contains hosts whose names are scattered over several zones, the administrator of the organizational network will not have the right to update the address record of all the affected hosts. Then, what can we do? Use a panacea of computer science, that is, introduce a level of indireciton. Each DNS node of a host should have host's own provider independent ID and, maybe, provider independent intra-organization routable part. It should also have a pointer to a node which have RRs of provider dependent routable part. Then, by changing the pointed node, we can re-address all the hosts in an organization. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 05:48:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14220; Fri, 3 Mar 95 05:48:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14214; Fri, 3 Mar 95 05:48:34 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03742; Fri, 3 Mar 1995 05:41:18 -0800 Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA12315; Fri, 3 Mar 95 05:41:17 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA17191; Fri, 3 Mar 95 07:57:39 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA02840; Fri, 3 Mar 95 07:40:49 CST Date: Fri, 3 Mar 95 07:40:49 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9503031340.AA02840@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re Re Re1 (IPng) Last Call .. Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ">>" is my reaction on a mail from Bill Simpson ">" is Masataka Ohta's reaction on that >> On (1) Multihoming/multiprovider. >> True, true and true. >> But can we define an alternative that allows for address abstraction? >> If you can do so; please... > Today there are hierarchically addressed strictly provider based > telephoney networks and flat routed provider free IP networks. > Now, some people are saying that, with magical routing, telephoney > addressing scheme can offer enough provider independence. But, it is > not proven in the real world test. > On the other hand, multihoming and other forms of provider independence > are the existing real world requirements. > OK? Yes, I'm OK. >> My network uses address prefix "a-c" of n+m bits. (ac/n+m) >> I have a router to A with address "a-c-d". (acd/128) >> I have a router to B with address "b-e", (be/128) >> and an address "a-c-f". (acf/128) > Already to complex to me. But, let's see the consequence. I'm using nothing else as the notation also found the mentioned drafts on address architecture to specify prefix and prefixsize. >> | | >> +---+-------- -----+----+ >> | acd \ \acf\be | >> | my network\ \ | >> +-------------- --------+ > That is, if B's advertisement of ac/n+m is valid, acd can not be reached. You're correct my simple suggestion does not cover this. I wait for the proposal that Bill promised before I spent any time on trying to fix such. > What we need is NOT a magically complex routing scheme that is > never tested in the real world but a simple addressing scheme. My personal opinion is a simple addressing scheme won't solve the problems Bill Simpson pointed out in his mail "(IPng) Last Calls - Unicast Assignment". We will need more than that. I know people will claim that telephone companies can do all kind of things while using a hierarchical address space, but a telephone switch can take a second or more to set up a call. People prefer routers to forward within much less than a millisecond. Fred Rabouw. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 05:49:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14232; Fri, 3 Mar 95 05:49:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14226; Fri, 3 Mar 95 05:49:47 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03804; Fri, 3 Mar 1995 05:42:32 -0800 Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA12433; Fri, 3 Mar 95 05:42:27 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA17201; Fri, 3 Mar 95 07:58:48 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA02852; Fri, 3 Mar 95 07:41:58 CST Date: Fri, 3 Mar 95 07:41:58 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9503031341.AA02852@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re Re Re6 (IPng) Last Call .. Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> (My reaction on Bill Simpson) >> Since most people seem to tend to use the IEEE LAN address as IPv6 host >> address we immediately "have to give" 48 bits to the site/subscriber part >> of the address. > (Masataka Ohta's reply:) > As I have already pointed out several monthes ago, given more than > 2^32 of world population, 48bit not-so-tightly-packed space is too > small for a large number of hosts in the near future. We agree on that. As you can read in the rest of my mail, I suggested 64 bits for the site/subscriber part. That is per single network only, not worldwide. My 64 bits don't have to be unique worldwide (if they are by accident it's nice), only per enduser network. Fred Rabouw ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 06:06:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14305; Fri, 3 Mar 95 06:06:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14281; Fri, 3 Mar 95 06:06:04 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04625; Fri, 3 Mar 1995 05:58:48 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA14254; Fri, 3 Mar 95 05:58:48 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 3 Mar 95 22:57:28 +0900 From: Masataka Ohta Message-Id: <9503031357.AA24952@necom830.cc.titech.ac.jp> Subject: Re: (IPng) National Registry of Routing is Harmful To: ipng@sunroof.Eng.Sun.COM Date: Fri, 3 Mar 95 22:57:27 JST In-Reply-To: <9503021816.AA20862@Sun.COM>; from "yakov@watson.ibm.com" at Mar 2, 95 1:16 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The only question on the > table is what kind of counter-measures would be available to counteract > this monopolistic nature of hierarchical routing. Monopolistic nature? If individual providers are identified in the top most routing layer, providers can freely compete and there can be no monopoly. If it makes the top most routing layer too large, make the hierarchy as flat as possible. That is, reduce the number of layers and make each layer as large as possible. Then, large number of provider groups (providers sharing the top most ID) can freely compete. It is most important to not to give the authority of a root or near-root node to some party who prefers the monopoly. See the subject. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 06:24:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14343; Fri, 3 Mar 95 06:24:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14337; Fri, 3 Mar 95 06:23:56 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05711; Fri, 3 Mar 1995 06:16:40 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA16359; Fri, 3 Mar 95 06:16:38 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 3 Mar 95 23:15:13 +0900 From: Masataka Ohta Message-Id: <9503031415.AA25046@necom830.cc.titech.ac.jp> Subject: Re: Re Re Re6 (IPng) Last Call .. To: ipng@sunroof.Eng.Sun.COM Date: Fri, 3 Mar 95 23:15:12 JST In-Reply-To: <9503031341.AA02852@anubis.network.com>; from "Fred Rabouw (Gouda office)" at Mar 3, 95 7:41 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > (Masataka Ohta's reply:) > > As I have already pointed out several monthes ago, given more than > > 2^32 of world population, 48bit not-so-tightly-packed space is too > > small for a large number of hosts in the near future. > > We agree on that. > As you can read in the rest of my mail, I suggested 64 bits for the site/subscriber > part. That is per single network only, not worldwide. I think your 64 bits contain MAC and site local routing part. Maybe, you can construct an autoconfiguration scheme with temporal 64bit unroutable MAC and permanent 64bit routable site ID. But, I'd like to limit the effect of accidental MAC collision within a single subnet, not within an entire organization. > My 64 bits don't have to be > unique worldwide (if they are by accident it's nice), only per enduser network. The only practical way currently known to make MAC address site unique is to make it globally unique. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 07:03:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14384; Fri, 3 Mar 95 07:03:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14378; Fri, 3 Mar 95 07:03:31 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09894; Fri, 3 Mar 1995 06:56:15 -0800 Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA21940; Fri, 3 Mar 95 06:56:14 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA18033; Fri, 3 Mar 95 09:12:30 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA03794; Fri, 3 Mar 95 08:55:40 CST Date: Fri, 3 Mar 95 08:55:40 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9503031455.AA03794@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: Re Re Re6 (IPng) Last Call .. Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On the 64 bit site addresses, containing MAC addresses: Please get me right, I didn't propose to use MAC addresses, I only noticed that the last draft on auto-configuration suggested it, and than made the point to Bill: In that case we need more than 48 bits for the site address. If one comes up with a scheme of autoconfiguration without using MAC addresses he gets my support. Fred ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 07:07:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14396; Fri, 3 Mar 95 07:07:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14390; Fri, 3 Mar 95 07:07:07 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10509; Fri, 3 Mar 1995 06:59:46 -0800 Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA22609; Fri, 3 Mar 95 06:59:34 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA18067; Fri, 3 Mar 95 09:15:14 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA03863; Fri, 3 Mar 95 08:58:22 CST Date: Fri, 3 Mar 95 08:58:22 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9503031458.AA03863@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re Re Re4 (IPng) Last Call etc.... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> (Me reaction on a mail from Bill Simpson): >> This is due to the fact that we see no way to scale the internet >> to span the world (and allow a biljoen subscribers somewhere in >> the futere) without having an hierarchical address structure. > (Masataka Ohta replying to me:) Wrong. Just make the top most > routing layer large enough (several thousands or several hundreds > of thousands) and treework disappears. If our future internet is there and as big and important as we all hope/fear: If I was a lowest level internet provider I would not be happy with a connection to just one of these backbone providers, 1) I would insist on connections to several backbone providers. 2) I would make direct connection to other low-level providers if my customers needed it and pay me for it. At that moment it's not only the top most routing layer that in interconnected. Also internet providers that start as a small provider at the lowest level will try to grow, they might become backbone providers and their original address block will not nicely fit in the new topology. >> Will geographical boundaries indeed be natural boundaries for >> the internet topology? > Geographical boundaries are natural. They will be "a" cause of > boundaries for the internet topology. Sometimes a geographical boundary will be found back in the internet topology, but as transmission costs drop, there is less and less need for that. As intercontinental ATM is there, a "low level" provider continent X might and will find a need to connect to a backbone on continent Y directly. Fred Rabouw ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 08:06:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14436; Fri, 3 Mar 95 08:06:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14430; Fri, 3 Mar 95 08:06:33 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14445; Fri, 3 Mar 1995 07:59:16 -0800 Received: from merit.edu ([35.1.1.42]) by Sun.COM (sun-barr.Sun.COM) id AA14725; Tue, 28 Feb 95 13:31:48 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-27.dialip.mich.net [141.211.7.163]) by merit.edu (8.6.10/merit-2.0) with SMTP id QAA20341 for ; Tue, 28 Feb 1995 16:23:57 -0500 Date: Tue, 28 Feb 95 21:10:05 GMT From: "William Allen Simpson" Message-Id: <4060.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Last Calls - Unicast Assignment Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > An Architecture for IPv6 Unicast Address Allocation > draft-ietf-ipngwg-arch-addr-01.txt > > An IPv6 Global Unicast Address Format > draft-ietf-ipngwg-address-format-01.txt > > alternative > addressing architectures and formats may and, we hope, will be specified > in the future, at which point they will go through the same process of > WG review.) > Since I have long been opposed to these documents, I will first repeat my opposition: - do not adequately address multi-homed and multi-provider networks, - the assumptions are layered statically, - do not provide for rapid re-addressing. - formalizes a treework, rather than a network. - results in political "ownership" of address blocks. Also, they assign too large a site/subscriber part, given the (false) assumption that we need many heirarchical layers of addressing. Therefore, they are not self-consistent. Given the above promise, I will write one of these alternatives. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 09:18:46 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14482; Fri, 3 Mar 95 09:18:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14476; Fri, 3 Mar 95 09:18:39 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23274; Fri, 3 Mar 1995 09:11:20 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA17005; Fri, 3 Mar 95 09:11:17 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sat, 4 Mar 95 02:09:55 +0859 From: Masataka Ohta Message-Id: <9503031710.AA25591@necom830.cc.titech.ac.jp> Subject: Re: Re Re Re4 (IPng) Last Call etc.... To: ipng@sunroof.Eng.Sun.COM Date: Sat, 4 Mar 95 2:09:53 JST In-Reply-To: <9503031458.AA03863@anubis.network.com>; from "Fred Rabouw (Gouda office)" at Mar 3, 95 8:58 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > (Masataka Ohta replying to me:) Wrong. Just make the top most > > routing layer large enough (several thousands or several hundreds > > of thousands) and treework disappears. > > If our future internet is there and as big and important as we all > hope/fear: If I was a lowest level internet provider I would not be > happy with a connection to just one of these backbone providers, > 1) I would insist on connections to several backbone providers. > 2) I would make direct connection to other low-level providers if my > customers needed it and pay me for it. > At that moment it's not only the top most routing layer that in > interconnected. With complex routing, it's not impossible to make hierarchical boundary fuzzy. But, having large enough layers is a lot simpler. CIDR is not a good example. I don't think we need more than 2 provider layers. > Also internet providers that start as a small provider at the lowest > level will try to grow, they might become backbone providers and > their original address block will not nicely fit in the new topology. You are mixing tow changes. Change of provider level and change of topology. Change of provider level can be supported by simualtaneously support both the old and new addresses, not so different from multihoming support. If a provider changes internal topology which affect subscribers routing prefix, I don't think we can do much. > >> Will geographical boundaries indeed be natural boundaries for > >> the internet topology? > > Geographical boundaries are natural. They will be "a" cause of > > boundaries for the internet topology. > > Sometimes a geographical boundary will be found back in the internet > topology, but as transmission costs drop, there is less and less need > for that. As intercontinental ATM is there, a "low level" provider > continent X might and will find a need to connect to a backbone on > continent Y directly. Wrong. In ATM network, provider X and Y can't be "directly" connected. There are a lot of intermediate switches. Moreover, NHRP model does not work at all. The only way to run IP over ATM is to have switches which operate as routers. So, you can't say "directly". For further details, come and join our BOF in Danvers: TSV CO and CL IP Transport over ATM BOF which is currently scheduled on Tuesday, 1300-1500. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 12:45:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14586; Fri, 3 Mar 95 12:45:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14580; Fri, 3 Mar 95 12:45:34 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19390; Fri, 3 Mar 1995 12:38:19 -0800 Received: from duke.cs.duke.edu by Sun.COM (sun-barr.Sun.COM) id AA02300; Fri, 3 Mar 95 12:38:11 PST Received: from tmp144.cs.duke.edu by duke.cs.duke.edu (5.65/3.10G/4.1.3) id AA01993; Fri, 3 Mar 95 15:38:06 -0500 Received: from localhost by tmp144.cs.duke.edu (5.65/3.10L/4.1.3) id AA14491; Fri, 3 Mar 95 15:37:59 -0500 Message-Id: <9503032037.AA14491@tmp144.cs.duke.edu> To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: Re: (IPng) WG last call: v6 ICMP draft In-Reply-To: (Your message of Tue, 28 Feb 95 21:09:02 PST.) <95Feb28.210914pst.12174@skylark.parc.xerox.com> Date: Fri, 03 Mar 1995 15:37:58 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have a few questions and some nits. Note also that I haven't always followed all previous discussions closely, so some of my questions may seem obvious. Feel free to direct me to the archived mailings if something has been hashed out in detail previously. "query" is misspelled "qeury"; forget to run the document through spell? :-) There are still some to be filled in. Do these need to be filled in before going to proposed standard? I note that in draft-ietf-ipngwg-address-format that the entire conclusion section is missing, which somehow doesn't seem quite appropriate. > > If the message is a response to a message sent to one of the | > node's unicast address, the Source Address of the reply must be | ^^^^^^^ plural > that same address. | > > If the message is a response to a message sent to a multicast | > group in which the node is a member, the Source Address of the | > reply must be a unicast address belonging to the interface on | ^^^ should this be "a" or "the"? That is, can an interface have multiple addresses at the same time? > which the multicast packet was received. | > > Otherwise, the node's routing table must be examined to determine | > which interface will be used to transmit the message to its | > destination, and a unicast address belonging to that interface | > must be used as the Source Address of the message. | > > Implementations MUST observe the following rules when processing IPv6 > ICMP messages (from [RFC-1122]): > > (a) If an IPv6 ICMP message of unknown type is received, it MUST be > silently discarded. > > (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. This statement implies that there may be cases where the returned IP header may be so large that the transport header (with its port numbers) gets omitted. How likely is this to be in practice? Or, perhaps, under what scenarios are the extensions expected to be large? How large? > (e) Finally, to each sender of an erroneous data packet, an IPv6 > node > MUST limit the rate of ICMP error messages sent, in order to | > limit the bandwidth and forwarding costs incurred by the the | > error messages when a generator of erroneous packets does | > not respond to those error messages by ceasing its | > transmissions. There are a variety of ways of implementing | > the rate-limiting function, for example: | a) This seems to me to be a pretty big psychological step; I'd imagine that it places quite a bit more (soft) state into a router, even if not on the common execution path. Also, if node X has three "flows" going through a router, should it be limiting error messages on a per flow basis? On a per-host basis? Other basis? b) are there any ipv4 implementations that limit icmp messages in this manner? What's the experience? > A Destination Unreachable message SHOULD be generated by a router, or | > by the IPv6 layer in the originating node, in response to a packet | ^^^^^^^^^^^^^^^^ I think "destination node" is meant. > that cannot be delivered to its destination address for reasons other | > than congestion. (If a packet is dropped due to congestion, no ICMP | > error message is generated.) If the reason for the failure to | > deliver is lack of a matching entry in the forwarding node's routing | > table, the Code field is set to 0 (NOTE: this error can occur only in | > > >3.2. | > Packet Too Big Message | > > > MTU The Maximum Transmission Unit of the next-hop link. | This may have been discussed before, but I don't recall the final outcome. What happens when a packet's size increases as it goes through (say) an encapsulating router. If I understand correctly, the intervening router is now considered a new "sender", and its address is now the packet's source address, in which case, any later attempt to forward the packet across an MTU that is too small results in a "packet too big" message being returned to the encapsulating router rather than the original sender. Is this in fact what is supposed to happen now? That is, can the size of a V6 datagram increase (after having left the sending node) *ONLY* if it is re-encapsulated, so that any "path too big" message does not go back to the original sender? (As a followup to this point, does this imply that an intervening router (that increases the size of a packet for whatever reason) may have to in fact do fragmentation in order to get around the path too small problem? I know the document says only "Senders" fragment packets, but if the above is true, the statement is a bit misleading.) If the above is in fact not what happens, then a sending node may get an icmp "path too large" even though the MTU in the error message is larger than the size of the outgoing packet (a dilemma). If this is so, does it make sense to have the icmp message contain 2 pieces of information: 1) the MTU of the next-hop, and 2) a number indicating by how many octets the current packet exceeds the MTU? > >Description > > A Packet Too Big MUST be sent by a router in > response to a packet that it cannot forward because the packet is | > larger than the MTU of the outgoing link. The information in this | > message is used as part of the Path MTU Discovery process [RFC-1191]. | > > Sending a Packet Too Big Message makes an exception to the rules of | > when to send an ICMP error message, in that unlike other messages, it | > is sent in response to a packet received with an IPv6 multicast | ^^ change "is" to "may be"? > destination address, or a link-layer multicast or link-layer | > broadcast address. | > >Upper layer notification > > An incoming Packet Too Big message MUST be passed to the transport > layer. Do we really want to say "transport layer"? What about the case where the originating packet is an ICMP echo request? I note that the wording concerning "upper layer notification" differs in some cases. How about just saying something like "... message MUST be passed to the appropriate upper layer module for processing." Is this not specific enough? > > IPv6 systems are expected to avoid fragmentation by implementing Path > MTU discovery. However, IPv6 defines an end-to-end fragmentation > function for backwards compatibility with existing higher-layer | > protocols. All IPv6 implementations are required to support | > reassembly | > of IPv6 fragments. There MUST be a reassembly timeout. The > reassembly timeout SHOULD be a fixed value. It is recommended that > this value lie between 60 and 120 seconds. If the timeout expires, > the > partially-reassembled packet MUST be discarded. If the fragment | > with offset zero was received, the destination host SHOULD also send > an IPv6 ICMP Time Exceeded message with Code 1 to the source of the | > fragment. | I'm not necessarily advocating removing this, but under exactly what scenarios is it in fact useful to get this message? What is a sending node in IPv4 supposed to do when it gets one of these? It seems to me that the message essentially is saying "don't fragment", which v6 senders don't do anyway. v4 senders do this because they have no choice (presumably), in which case they are probably just going to ignore the message. >Upper layer notification > > An incoming Time Exceeded message MUST be passed to the transport > layer. Again, the "transport layer" wording doesn't seem quite right. If the offending message was an echo request... >4.1. > Echo Request Message | > Destination Address | > Any legal IPv6 address. | It might help clarify things a bit to add the words "(including a multicast address)". Reading this the first time, I was wondering whether multicast addresses were allowed and concluded they were only by the lack of discussion explicitely forbidding it. > > The data received in the ICMP Echo Request message MUST be returned | > entirely and unmodified in the ICMP Echo Reply message, unless the | > Echo Reply would exceed the MTU of the path back to the Echo | > requester, in which case the data is truncated to fit that path MTU. | I'm not sure what to say about this statement other than it makes me a bit uncomfortable. Is there a hidden "gotcha"? I assume that the sending ICMP actually truncates the packet, so the ICMP checksum is at least correct. But the sending host now has to explicitely remember what the original packet size was in order to determine that the response was truncated (probably not a big deal). Would it make sense (or even be useful) to use a code other than 0 to indicate that the packet was truncated for path MTU reasons? >Upper layer notification > > Echo Reply messages MUST be passed to the ICMP user interface, unless > the corresponding Echo Request originated in the IP layer. Under what scenarios is an Echo Request originated by the IP layer? Isn't that considered bad form in the sense that the only reason to do so is for lack of an alternative message types, as in "gateway black hole detection"? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 13:48:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14686; Fri, 3 Mar 95 13:48:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14680; Fri, 3 Mar 95 13:48:38 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26775; Fri, 3 Mar 1995 13:41:22 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA14420; Fri, 3 Mar 95 13:41:20 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-09.dialip.mich.net [141.211.7.145]) by merit.edu (8.6.10/merit-2.0) with SMTP id QAA10547 for ; Fri, 3 Mar 1995 16:41:16 -0500 Date: Fri, 3 Mar 95 21:07:39 GMT From: "William Allen Simpson" Message-Id: <4112.bsimpson@morningstar.com> To: ipng@sunroof2.Eng.Sun.COM Subject: Re: (IPng) Last Calls - Unicast Assignment Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Now, here's a delay if I ever saw one! What is wrong with Sun.Com, and why is it intercepting all of our email? > Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) > id AA14430; Fri, 3 Mar 95 08:06:33 PST > Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) > id AA14445; Fri, 3 Mar 1995 07:59:16 -0800 > Received: from merit.edu ([35.1.1.42]) by Sun.COM (sun-barr.Sun.COM) > id AA14725; Tue, 28 Feb 95 13:31:48 PST > Received: from Bill.Simpson.DialUp.Mich.Net (pm002-27.dialip.mich.net [141.211.7.163]) by merit.edu (8.6.10/merit-2.0) > with SMTP id QAA20341 for ; Tue, 28 Feb 1995 16:23:57 -0500 > Date: Tue, 28 Feb 95 21:10:05 GMT > From: "William Allen Simpson" Merit to Sun.Com in 7 minutes; Sun.Com to Eng.Sun.Com in 3 days! And doesn't Eng trust Sun enough that it doesn't need its own email gateway? Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 15:26:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14730; Fri, 3 Mar 95 15:26:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14724; Fri, 3 Mar 95 15:25:55 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08586; Fri, 3 Mar 1995 15:18:38 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA05078; Fri, 3 Mar 95 15:18:37 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA28901; Sat, 4 Mar 1995 10:18:18 +1100 (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 AA19946; Sat, 4 Mar 95 09:02:47 +1000 Received: by dcthq2.datacraft.com.au; Sat, 4 Mar 95 10:20:13 +1100 Date: Sat, 4 Mar 95 10:11:10 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: Re: (IPng) National Registry of Routing is Har mful X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=YES Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM begin 600 attach.Z M'YV0:=R,>7/&31HZ;URTF7,&@,.'$"-*G$BQHL6+&"N"V&BC(P@`&T'$H$'C M8\B1)4&&/#G#QHR--6[(B"E#!HP:-3;&D!%C1@V0,#(*'4JTJ-&)=>;0"2-G M(P`V;\:$87.4(E2I5*MJWO8+7**0."#IHT0*:B6$R9,;.F>-YL(*Z5-"0'1MF3F,024!(=:/VSL$Q:"YGWMQ9 M3EJT9=$H3EYF+`CD8P<6/,B8]QLS($"+)AW$M((@1(A(*3)E"GG#;L@D7VZV MC&6F9`>ZF3.YC)N\*-*0=?,F+YD\B;61!E9LO+=:&@65048*A"D0VVQEU':; M&6\TI5088K!!5ABHJ<;:<6F9M5QNNX$@!EEBI,&&ANI1V%0;EK$FQV9CM%88 M"E/9IEMC;KRUV&T5ZG>?@FHU1Z-G(,C&!AQ)-E=&"`R^YJ!LD$5H&V^Y*6?' MAFH%=(:&IZ7F&8CKY3758^U=5L8;<("9VQK\W:%;&+P1"`)?KC6(Q!MRWA:A M'&8]%^)9:?T7X(!G&DA?@NIQ*.9J"K*`F&+5)6J8'"DN)8>*!8*@@*,>$MDC M'7=4N`8(O@7:1AUL+-9F7\-QUEQ:=*J7U*RHHO%&;[\%AYEFLAIGF*=FO9%4 MK66EP1>M()`1AF5G_.7&&67M6JH<:\C5H&UR5`;"&77DD=9SO'76YAMY8`CF MJ->>:I]D/3;G95G-+90<L\\X\]^SSST`'+?301!=M]-%()ZWTTDPW[?334$M]MILM^WVVW#'+??<=-=M]]UXYZWW -WGSW[???@``RWV ` end ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 17:39:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14929; Fri, 3 Mar 95 17:39:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14923; Fri, 3 Mar 95 17:39:00 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21280; Fri, 3 Mar 1995 17:31:43 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA24286; Fri, 3 Mar 95 17:31:41 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA03383; Sat, 4 Mar 1995 12:31:18 +1100 (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 AA20142; Sat, 4 Mar 95 11:15:52 +1000 Received: by dcthq2.datacraft.com.au; Sat, 4 Mar 95 12:33:31 +1100 Date: Sat, 4 Mar 95 12:29:05 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: (IPng) Last Calls - Unicast Assignment X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=YES Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM begin 600 attach.Z M'YV0:=R,>7/&31HZ;URTF7,&@,.'$"-*G$BQHL6+&"N"V&BC(P@`&T'$H$'C M8\B1)4&&7#FC!HR--6[(B$DC1HT:,S;&D!%C)$@8&8,*'4JTZ,0Z<^B$D;,1 M`)LW8\*P,4KQ:=2I5+-JWO69.X`2&GS!PX;]S,*0,"(0@A:=BP.3$' MQ!LS9LHP-?.&:9BQ4NGH=1.&3AH[;,.0(5-VSIR`9T#,&8.F3!NV=PZBV7BP MK@(S=00:3EL7!9D\A-ND&0-"JM7":=*F8`&B,X@S3\5(;4U&M<&D4`HF),GJ>6Z?\G212":IY)),-NGDDU!&*>645%9IY9589JGE FEEQVZ>678(8IYIADEFGFF6BFJ>::;+;IYIMPQBGGG'36:>>=$`%I ` end ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 18:02:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14943; Fri, 3 Mar 95 18:02:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14937; Fri, 3 Mar 95 18:02:43 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23303; Fri, 3 Mar 1995 17:55:25 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA26881; Fri, 3 Mar 95 17:55:19 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA04117; Sat, 4 Mar 1995 12:55:13 +1100 (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 AA20183; Sat, 4 Mar 95 11:40:04 +1000 Received: by dcthq2.datacraft.com.au; Sat, 4 Mar 95 12:57:32 +1100 Date: Sat, 4 Mar 95 12:34:08 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: Re: (IPng) National Registry of Routing is Har mful X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=YES Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM begin 600 attach.Z M'YV0:=R,>7/&31HZ;URTF7,&@,.'$"-*G$BQHL6+&"N"V&BC(P@`&T'$H$'C M8\B1)4&&##FCQLB--6[(B$F2QDN1,D;"`+DSH\^?0(,*E5AG#ITP"\87HF39DY(!"F15,&!)LT1D&8>9.T M:,`S:]O>H4L&A(@A4H)`$0$B((@V>=R&B2O6J`L02>B`N+,8A)LWDA4,=&-4 M3ITQ=-+8*>/BJVD%5-B"J.-FKAPZK,/0:6LF#&@0;\R`>,IF+=S":.F@D9T7 M!!PT;]RTG9/':)DVD^FN02LFL?#?"MS(3I/\*0@Y9OLT;&27D>,]S!GPS\NXH4.]#)T[9>@'@E-RR&&6'&@I@`(<1:$"*K)8X6YRH'=0&:#5`=YD:*2!'@CZA2$&&R**@1D:&[7QAACP'918 M&!;*!24>:6#Y%AV)Y0:"`G-\J&1;##H(%W=NE*;`5T%82,8;EF'6UG5H_>;: M@,DI!QJ&;,F=JAL<8<`Q'X5<]L54@68%AR>/9;PU6E(:MB'G M5TF`<(9_Q:71!H-GS4$HAI+Q"=QNDC9H&Y5JA4$&&>#-(:T;9[!PV)7PB6OB5:$PMY+QF-/*!=Q M96H)S.)\>1D+6=$*B+K0TFD1B<9E9.5A;ILZC[6NMVT$!#)]H27W6&IMG6&Q M=TD<2C2SAL&H0!YE(`5"C3'<>`=\O8%W-*8;-H'$Y),_L1L;O<$X$%\!R=<7 M<@B6(1:`295X(KS`CL:4K1>^0488B;VH&H$Y(K@NASTG&P9T+J:.+)GNT"U+1VCP"CV?-N6DV^07!QEB35O`UJ[?1ONN'C!CHE0%"'5O8%U,:3!.TT+$9*41*61C2M:(E)``WL3(5MUR6ZG099D M?F.FRZPF32DZ2QH*@B(N]0]=)#&_903#G_D4YA=`,QI[BA=R8Z$]SD MYASP3`T$IXG,M5J()X>E!4_#&4V\@+@7.:P!28YZFNB80C@7)29^;DA,N^QE M.]9`25QGTE!BLMB6S4C+.?MY3WQ$59_[!(A]XRL.I,1P'I%):#46DM!1NE2L MW*WP9BZTHEKHF*(\:"=N5&'#EL0U0^[=\'\B\IB5Q"2B-.@F.6WAT1M$U#M* MZNU*O#DCE^R#J%1E"B&_,T]S9C,VM4!*4G2I5GIZ]I74_`8ND-)+92@6`QNT MIU0/$]?Y%!,7PB'E,H`<%=.6>^,RG/O?)SW[Z\Y\`#:A`!TK0@AKTH`A-J$(7RM"&.O2A M$(VH1"=*T8I:]*(8S:A&-\K1CGKTHR`-J4A'2M*2FO2D*$VI2E?*TI:Z]*4P MC:E,9TK3FMKTICC-J4YWRM.>^O2G0`VJ4(=*U*(:]:A(3:I2E\K4ICKUJ5"- .JE2G2M6J6O6J6,TJ4@%W ` end ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 3 18:24:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14959; Fri, 3 Mar 95 18:24:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14953; Fri, 3 Mar 95 18:24:21 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24912; Fri, 3 Mar 1995 18:17:03 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA28747; Fri, 3 Mar 95 18:16:34 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA04873; Sat, 4 Mar 1995 13:16:31 +1100 (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 AA20228; Sat, 4 Mar 95 12:01:10 +1000 Date: Sat, 4 Mar 95 12:01:10 +1000 Message-Id: <9503040201.AA20228@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au; Sat, 4 Mar 95 13:18:39 +1100 Resent-Date: Sat, 4 Mar 95 10:11:10 +1100 Resent-Message-Id: Resent-From: Alan.Lloyd@datacraft.com.au From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: Re: (IPng) National Registry of Routing is Har mful X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=YES Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM begin 600 attach.Z M'YV0:=R,>7/&31HZ;URTF7,&@,.'$"-*G$BQHL6+&"N"V&BC(P@`&T'$H$'C M8\B1)4&&/'D#AHR--6[(B$G#QHV;&V/(B%%C!D@8&8,*'4JTZ,0Z<^B$D;,1 M`)LW8\*P,4KQ:=2I5+-JWO68V\D7-G*9DR9$`@U+%R8T`Z9>2X*4-G M2QHX;LX`F5/'C9PW;\RX*)/7!5\W+@:VZ=)`0=NV8\:P;=MXR)LV;0C3F0-" M3)[);8.P">,&!).G><@`:;)T#=V`>HD,H8(D2N/&(5OHWLV[M^_>(+8\D9/F M3$"I()J4F3,GS)DR74#\GDZ]Q>/&/"!8C&:I#2`3'G MLG8X;][.<7';<1@0;L+02?,F/QL0V1F7E!QY@`#'7W:D<19G3@1!11)/-,@$ M"&&0049VS"U'GP*-48&&=MF%T5YI28`056ESW''0&&@8B*""<7'6W7;Z;1>7 M=C-F-U!!!_%76F`@-/A@A$%,J$`01!`A11%33,$DA6ZD10<:-4Y91H%+:3>0 M&W-T!Y<;ZZ&0AG9NO+$>&7GDUT8:5[&!)7/%S45&"O5Y"&(9(O8'@AECL:>4 M&&QH5^&%R\VQ'`@S3EECB2=VIIT8:;`1:%I\,M5&@8;*D>`8&N*&@E3MF=C? M7./Y",)88X*)%GMQ;7KHAVS``<*'V85`)X<*V`D@GB."4"*5=@C*'FR!4F@A MAC)RINAZ4OUGI8%EO`%'L26N4>8=)I*6K:0@9+9A?4B\@:V>>,HQ):+*R;71:TZJ#(HL4"?OKY^"Z%DI854C`RC\09[#;/HXAL)6HPQ"`I,^092&:N51F8GDQ%& M@6?$EY=:'R>'`2"<$8=>7"&:&EG3?M&'F$`2B9=.B],F'%SQ06; M6G$MM-V,,Y9Q$*T4@D!H&&VN^>:<=^[Y MYZ"'+OKHI)=N^NFHIZ[ZZJRW[OKKL,O_/+,-^_\\]!'+_WTU%=O_?789Z_]]MQW[_WWX( Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15536; Sun, 5 Mar 95 20:44:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15530; Sun, 5 Mar 95 20:44:36 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06427; Sun, 5 Mar 1995 20:37:16 -0800 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA06596; Sun, 5 Mar 95 20:37:13 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Mon, 6 Mar 1995 14:35:10 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Mon, 6 Mar 1995 14:32:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Mon, 6 Mar 1995 14:31:19 +1000 Date: Mon, 6 Mar 1995 14:31:19 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Mar 06 14:31:18 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 183114060395 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <183114060395*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Subject: re: Re: (IPng) National Registry of Routing is Har mful Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan, As I understand it the DNS will have to provide the address mapping that allows a node to be located? Is that correct? If we are to change provider mid session, I assume that the protocol must allow that fact to be signalled to the participants so that they can dynamically change their addresses and paths etc or start the search for the new address. Sounds pretty up market if the session is to stay up without the participants knowing. Jeff L begin 600 attach.Z M'YV0:=R,>7/&31HZ;URTF7,&@,.'$"-*G$BQHL6+&"N"V&BC(P@`&T'$H$'C M8\B1)4&&/#G#QHR--6[(B"E#!HP:-3;&D!%C1@V0,#(*'4JTJ-&)=>;0"2-G M(P`V;\:$87.4(E2I5*MJWO8+7**0."#IHT0*:B6$R9,;.F>-YL(*Z5-"0'1MF3F,024!(=:/VSL$Q:"YGWMQ9 M3EJT9=$H3EYF+`CD8P<6/,B8]QLS($"+)AW$M((@1(A(*3)E"GG#;L@D7VZV MC&6F9`>ZF3.YC)N\*-*0=?,F+YD\B;61!E9LO+=:&@65048*A"D0VVQEU':; M&6\TI5088K!!5ABHJ<;:<6F9M5QNNX$@!EEBI,&&ANI1V%0;EK$FQV9CM%88 M"E/9IEMC;KRUV&T5ZG>?@FHU1Z-G(,C&!AQ)-E=&"`R^YJ!LD$5H&V^Y*6?' MAFH%=(:&IZ7F&8CKY3758^U=5L8;<("9VQK\W:%;&+P1"`)?KC6(Q!MRWA:A M'&8]%^)9:?T7X(!G&DA?@NIQ*.9J"K*`F&+5)6J8'"DN)8>*!8*@@*,>$MDC M'7=4N`8(O@7:1AUL+-9F7\-QUEQ:=*J7U*RHHO%&;[\%AYEFLAIGF*=FO9%4 MK66EP1>M()`1AF5G_.7&&67M6JH<:\C5H&UR5`;"&77DD=9SO'76YAMY8`CF MJ->>:I]D/3;G95G-+90<L\\X\]^SSST`'+?301!=M]-%()ZWTTDPW[?334$M]MILM^WVVW#'+??<=-=M]]UXYZWW -WGSW[???@``RWV ` end ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 6 00:27:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15578; Mon, 6 Mar 95 00:27:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15572; Mon, 6 Mar 95 00:27:32 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10850; Mon, 6 Mar 1995 00:20:11 -0800 Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA24392; Mon, 6 Mar 95 00:20:04 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA05094; Mon, 6 Mar 95 02:36:29 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA23189; Mon, 6 Mar 95 02:19:35 CST Date: Mon, 6 Mar 95 02:19:35 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9503060819.AA23189@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: re re re re4 (IPng) last call Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> (Me reaction on a mail from Bill Simpson): >> This is due to the fact that we see no way to scale the internet >> to span the world (and allow a biljoen subscribers somewhere in >> the futere) without having an hierarchical address structure. > (Masataka Ohta replying to me:) Wrong. Just make the top most > routing layer large enough (several thousands or several hundreds > of thousands) and treework disappears. If our future internet is there and as big and important as we all hope/fear: If I was a lowest level internet provider I would not be happy with a connection to just one of these backbone providers, 1) I would insist on connections to several backbone providers. 2) I would make direct connection to other low-level providers if my customers needed it and pay me for it. At that moment it's not only the top most routing layer that in interconnected. Also internet providers that start as a small provider at the lowest level will try to grow, they might become backbone providers and their original address block will not nicely fit in the new topology. >> Will geographical boundaries indeed be natural boundaries for >> the internet topology? > Geographical boundaries are natural. They will be "a" cause of > boundaries for the internet topology. Sometimes a geographical boundary will be found back in the internet topology, but as transmission costs drop, there is less and less need for that. As intercontinental ATM is there, a "low level" provider continent X might and will find a need to connect to a backbone on continent Y directly. Fred Rabouw ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 6 02:54:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15684; Mon, 6 Mar 95 02:54:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15678; Mon, 6 Mar 95 02:53:58 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16468; Mon, 6 Mar 1995 02:46:39 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA05126; Mon, 6 Mar 95 02:46:37 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24910; Mon, 6 Mar 1995 20:46:33 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: Re: (IPng) WG last call: v6 ICMP draft In-Reply-To: Your message of "Tue, 28 Feb 1995 21:09:02 PST." <95Feb28.210914pst.12174@skylark.parc.xerox.com> Date: Mon, 06 Mar 1995 21:46:18 +1100 Message-Id: <6440.794486778@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Tue, 28 Feb 1995 21:09:02 PST From: Steve Deering Message-ID: <95Feb28.210914pst.12174@skylark.parc.xerox.com> This is a Working Group last call for the following document, before requesting the IESG to make it a Proposed Standard: ICMP for the Internet Protocol Version 6 (IPv6) draft-ietf-ipngwg-icmp-01.txt One general query - now that IPv6 ICMP has been given a new protocol type, etc, ans is no longer pretending to just be IPv4 ICMP in disguise, should its headers not have a "next header" field, as all the other IPv6 headers do? Is there some particular reason why the IPv4 ICMP packet layout still needs to be retained unchanged, given that almost evrything about its contents has been altered? kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 6 03:11:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15718; Mon, 6 Mar 95 03:11:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15712; Mon, 6 Mar 95 03:10:57 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17012; Mon, 6 Mar 1995 03:03:38 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA09394; Mon, 6 Mar 95 03:03:34 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25423; Mon, 6 Mar 1995 21:03:28 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Required Minimum MTU, and Max Reassembly size Date: Mon, 06 Mar 1995 22:03:12 +1100 Message-Id: <6443.794487792@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I saw a comment, more or less in passing, that the Feb meeting had decided to reduce both the required Minimum MTU, and the minimum required reassembly size, back to 576. Somehow, I have missed seeing any rationale for that. That may be because I also seem to have missed seeing the minutes of the meeting, which probably arrived on one of those days I had way too much mail, and so was in a "delete as much as possible with as little thought as possible" mode... I expect I understand why the MTU requirement was altered back, using a large value for that had always been somewhat contentious. However, I can't quite see why the max reassembly size needs to be 576, or anything like it. In fact, it seems to me that having the minimum MTU and the max reassembly size at the same value, is equivalent to saying that fragmentation/reassembly is a waste of time in all cases (datagrams larger than the MTU should never be sent), and therefore, apart from its role in translating IPv4 packets, which seems to have been lost along the way, fragmentation/reassembly may just as well be deleted completely. Can someone, briefly, expand on the reasons that the reassembly size can't be made something more in line with rational expectations - 1500 at least? Alternatively tell me that I mis-read what I (think I) saw. Personally I wouldn't object to something more like 4096. Basically all this is requiring is a buffer that large at the receiver, and even then, a receiver implementing such a small subset of the protocol suite that it never needs packets that large can easily cope with ignoring this requirement, if packets that large are always bigger than its application wants, it can always silently drop them. It becomes indistinguishable whether they're being dropped because the receiver doesn't have a big enough buffer, or because the application at the node doesn't want to receive packets that large (for TCP, setting a low MSS achieves this). In any case, we probably need a way for nodes to negotiate a larger acceptable packet size - at the minute (IPv4) we pretty much know that for most nodes, 8K is OK, as 8K packets are what NFS likes by default... But we have no way to actually determine that. Note that the TCP MSS doesn't really achieve this, and in any case, TCP is not everything, its large UDP datagrams that are often more important, as UDP datagrams are independant objects, TCP packets can be split and recombined in almost any fashion without harm. Buinding hacks into every UDP (and other non-TCP) application protocol to determine what packet size is acceptable seems like a sub-optimal way to exchange this information. Note that a standard mechanism does not imply a node-wide standard size, the application can still decide what size packets it wants to receive, its just that this information could be conveyed to the peer via an IP level standard mechanism. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 6 05:43:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15896; Mon, 6 Mar 95 05:43:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15890; Mon, 6 Mar 95 05:43:49 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25290; Mon, 6 Mar 1995 05:35:35 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA22534; Mon, 6 Mar 95 05:35:28 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm012-20.dialip.mich.net [141.211.7.188]) by merit.edu (8.6.10/merit-2.0) with SMTP id IAA16946 for ; Mon, 6 Mar 1995 08:35:26 -0500 Date: Mon, 6 Mar 95 12:19:46 GMT From: "William Allen Simpson" Message-Id: <4131.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) WG last call: v6 ICMP draft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Robert Elz > One general query - now that IPv6 ICMP has been given a > new protocol type, etc, ans is no longer pretending to just > be IPv4 ICMP in disguise, should its headers not have a > "next header" field, as all the other IPv6 headers do? > What headers would come after ICMP? It is a final payload. Something has to be a final payload. ESP has no (visible) next header field, either. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 6 06:09:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15961; Mon, 6 Mar 95 06:09:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15955; Mon, 6 Mar 95 06:09:32 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26372; Mon, 6 Mar 1995 06:02:12 -0800 Received: from relay1.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA25137; Mon, 6 Mar 95 06:02:11 PST Received: from iiit.swan.ac.uk by relay1.UU.NET with SMTP id QQyfwx11007; Mon, 6 Mar 1995 08:58:21 -0500 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: (IPng) WG last call: v6 ICMP draft To: ipng%sunroof.eng.sun.com@uunet.uu.net Date: Mon, 6 Mar 1995 13:59:10 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > What headers would come after ICMP? It is a final payload. Something > has to be a final payload. > > ESP has no (visible) next header field, either. But for cleanness having a next header field in all packets would remove the special cases and allow packets to carry a mixture of ESP and non ESP frames. Surely a terminal server with some secure and some insecure ports is not that improbable a concept for the ESP example, and piggy backing ICMP messages seems highly elegant. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 6 06:10:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15973; Mon, 6 Mar 95 06:10:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15962; Mon, 6 Mar 95 06:09:53 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26391; Mon, 6 Mar 1995 06:02:33 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA25204; Mon, 6 Mar 95 06:02:32 PST Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02264; Tue, 7 Mar 1995 00:02:09 +1000 (from kre) Date: Tue, 7 Mar 1995 00:02:09 +1000 From: Robert Elz Message-Id: <9503061402.2264@munnari.oz.au> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) WG last call: v6 ICMP draft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 6 Mar 95 12:19:46 GMT From: "William Allen Simpson" Message-Id: <4131.bsimpson@morningstar.com> What headers would come after ICMP? It is a final payload. Something has to be a final payload. Anything. I am still typing my "payload header" draft (written in December, but...) which was what reminded me. There's no reason any combination of packets from the same source to dest shouldn't be able to go in the same datagram. Sure something has to be last in any particular datagram, but that doesn't mean that something has to be defined to be always last. ESP has no (visible) next header field, either. So? It has a next header field, that's all that counts, whether its visible in transit or not, its certainly visible after the contents have been decrypted. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 6 06:13:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15989; Mon, 6 Mar 95 06:13:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15983; Mon, 6 Mar 95 06:13:32 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26671; Mon, 6 Mar 1995 06:06:11 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA25771; Mon, 6 Mar 95 06:06:10 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm036-26.dialip.mich.net [141.211.7.68]) by merit.edu (8.6.10/merit-2.0) with SMTP id JAA18261 for ; Mon, 6 Mar 1995 09:05:56 -0500 Date: Mon, 6 Mar 95 13:57:41 GMT From: "William Allen Simpson" Message-Id: <4134.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Last Calls - Unicast Assignment Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM As promised, here is my Unicast Allocation initial draft. I am running out of time to work on this, so please submit your comments this week, after which I shall submit this to internet-drafts, and immediately ask for Standardization as a Proposed Standard, in accordance with the WG Chairs promise to consider alternatives. Network Working Group W A Simpson Internet Draft Daydreamer expires in six months March 1995 IPv6 Unicast Allocation by Exchange draft-simpson-ipv6-addr-exch-00.txt preliminary version A Status of this Memo This document is a submission to the IPng Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ipng@sunroof.eng.sun.com mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract This document specifies an administrative plan, wherein unicast node numbering is simply divided for allocation according to the nearest multi-domain interconnection. Simpson expires in six months [Page i] DRAFT Allocation by Exchange March 1995 1. Constraints This is merely a plan for allocation of unicast node numbers in a rational fashion. The main purpose of the allocation plan is to support allocation mechanisms that guarantee uniqueness. 1.1. Administration The plan must be easy to administer. Complexity could engender conflicts between authorities, preventing assignment uniqueness. Initially, there will be very few administrative authorities. As the Internet grows larger and more diverse, the administrative authority must scale appropriately. It is required that this scaling use the mechanisms of the Internet itself, rather than some external administrative structure. Human administrative organization changes at a considerably slower pace than technological innovation and expansion, and exhibits a propensity for self-perpetuation. The Internet is not centrally controlled nor hierarchically administered. Assignment must be readily distributed among many independent Administrative Domains. Each Administrative Domain is responsible only for assignment within its confines. An Administrative Domain must also be responsible for reliable registration of its assignments, and communication of those assignments to other Domains. This is typically provided by the Domain Name Service (DNS). 1.2. Aggregation As the Internet itself scales, aggregation is required to limit the additional resources needed. The plan must identify natural points of numerical aggregation, which closely match the actual changing routing topology of the Internet. Conflicts may arise between organizational or political boundaries. The plan must circumscribe such areas. While the plan must be able to support any topology, it is not necessary that the plan support all topologies with equal efficiency. Simpson expires in six months [Page 1] DRAFT Allocation by Exchange March 1995 The goal is that global routing will require no more than two bytes of a prefix to be examined, and need no more than a few thousand cached routing entries. 1.3. Allocation The plan must make efficient utilization of the numbering space. Each division has a potential allocation inefficiency. Therefore, there should be as few formal levels of division as possible, and a firm rationale for use of each division. The allocation divisions cannot be static. As the topology expands and changes, the numbering must rapidly conform to the new organization. This implies that any allocation include some form of expiration, to allow old numbering to be identified, and eliminated from cached databases. This is a feature already provided by the DNS. Dynamic update of the DNS registration database is beyond the scope of this specification. 1.4. Access The plan must support efficient distributed access techniques. In particular, the number database should be partitioned such that access is widely distributed throughout the Internet, instead of highly dependent on a few root DNS servers. Simpson expires in six months [Page 2] DRAFT Allocation by Exchange March 1995 2. Rejected Considerations There have been many other designs and plans for allocation. Those plans have concentrated on one particular facet of allocation, such as ease of algorithmic transformation from older IP numbers, retaining current administrative entities, or simplicity of assignment. 2.1. Hierarchy The Administrative Domains are rarely interconnected in a hierarchical topology. Many Administrative Domains have independent interconnections with each other. Even small independent organizations, such as FreeNet bulletin boards, frequently are connected to multiple points of access, or provide interconnection services themselves. From its earliest roots, the Internet was envisioned to provide interconnection redundancy and robustness. Relying on establishment of a topological hierarchy introduces single points of failure. This is unacceptable. The plan should recognize this salient feature of the Internet, which is why the infrastructure is called a "Network", rather than a "Treework". 2.2. Regional Registries A regional registry will have more knowledge about a particular region than a global registry, and be better suited to keep track of registration information as it changes over time. Establishment of regional administrative authorities may assist the coordination of local issues, such as different languages. However, some expect that regional registries could further devolve into country and metropolitan registries, and become embedded in local regulation and politics. Such registries would actually interfere with allocation, and add considerable complexity. Moreover, the existance of a regional registry should not prevent an Administrative Domain, which is located within the region by mere happenstance, from obtaining its topological connection from outside the region. This already happens frequently. To avoid excessive local monopoly tariffs, Domains have established links which span Simpson expires in six months [Page 3] DRAFT Allocation by Exchange March 1995 regional boundaries, rather than connect locally. Despite regional availability, perhaps because of political rivalry, Domains in some countries are currently connected directly to the other side of the globe. Interconnections are willy nilly all about the landscape. Instead, the actions of the Administrative Domains themselves should be directly reflected in the expected dynamic distribution of policy routing databases. Dynamic update of the policy database is beyond the scope of this specification. 2.3. Provider/Subscriber Dichotomy Other proposals often include some concept of dividing allocation along artificial Provider to Subscriber boundaries. This is often as an aid to Hierarchy and Regional Registries. However, Providers are not easy to qualify. Every Domain which provides transit traffic is essentially a Provider. Granting some "Providers" special status merely promotes monopoly pricing practices and prevents competition. This is evidenced by the current practice of some Providers, which charge more for a link to another Provider than a link of the same bandwidth to a "Subscriber". There is no rational justification, as the traffic service is the same, and another Provider is less likely to need the customer support of a neophyte Subscriber. The principal effect is to inhibit interconnection. The result is that Providers are not places of interconnection, as the term is used in this document. Rather they are simply Administrative Domains which attach to other Domains at specific points, and charge a premium fee for the privileged status. Allocating node numbers in any relationship to such Providers could be used to discourage Subscribers from changing Providers, further limiting competition. It has been proposed that Providers would act in concert to charge more for advertising Subscribers from another Provider's number block. Any change of Provider could cause service disruption until new node numbers are registered and promulgated. Instead, the plan should reflect easy change of provider, and any other changes of interconnection. Simpson expires in six months [Page 4] DRAFT Allocation by Exchange March 1995 2.4. Ownership Heirarchical allocation, whether Regional or Provider based, exhibits a tendency toward divisive control and ownership issues. It must be clear from the outset that administrative power to allocate a range of numbers or receiving a range of numbers, does not constitute a property interest in those numbers. The plan must ensure through its mechanism that allocation is transitory. Failure to dynamically reassign numbers as topology changes would prevent aggregation. Simpson expires in six months [Page 5] DRAFT Allocation by Exchange March 1995 3. Allocation Plan This plan provides for administrative allocation based on each nexus of interconnection of 3 or more Administrative Domains. These are termed "Internetwork Exchanges" (IX). 3.1. Exchanges Each Exchange is administratively numbered. Authority for numbering Exchanges is vested in the Internet Assigned Number Authority (IANA). Although there is no heirarchy of Exchanges, assigning related numbers to interconnected Exchanges may improve serendipitous aggregation at natural topological boundaries. It is recommended that IANA coordinate with extant Regional Registries in grouping Exchange numbers. From time to time, an additional number may be assigned to a single Exchange. Until the older number is allowed to expire, the Exchange will use both numbers independently. It is not expected that Exchange numbers will change frequently. But, they should be changed from time to time, to exercise the dynamic allocation mechanisms within the Administrative Domains. 3.2. Administrative Domains Each Administrative Domain is administratively assigned a prefix which is used as a Routing Domain Identifier (RDI). The RDI is derived from each Exchange to which the Domain has direct access, or is allowed indirect access through another Domain. Authority for assigning RDIs is exclusively vested in each Exchange administrator. Because the Domain can utilize more than one Exchange, it can have more than one RDI. Each Domain may chose to limit the number of indirect RDI numbers in use at one time. This method of allocation introduces one initial division, between the Exchange and Domain, as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exchange | Domain ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Simpson expires in six months [Page 6] DRAFT Allocation by Exchange March 1995 This division boundary is not fixed. It is illustrated at 12-bits, which follows the target goal of a few thousand cached routing entries. However, the number of Exchanges can easily be expanded or contracted by varying the boundary on a per Exchange prefix basis. The Domain part is extended according to the technique described in [RFC-1219]. The "1" bits of the values are assigned from left-to- right, rather than from right-to-left. This style of assignment reserves zeros on the right side. Domains of different sizes are accomodated by varying the length of the RDI prefix assigned. As Domains expand or contract, aggregation is maintained through simply changing the prefix length. 3.3. Routers Each router is assigned (preferably dynamically) one or more numbers for each interface. These numbers are derived from the RDI prefixes advertised by the nearest boundary routers. 3.4. Hosts Each host is assigned (preferably dynamically) one or more numbers for each interface. These numbers are derived from the prefixes advertised by the nearest routers. 4. Implementation Considerations Interconnection of only 2 Administrative Domains is not an Exchange within the scope of this specification. Each such Domain may allow transit access to its accessable Exchanges. 4.1. Regions Regional Registries are natural administrative entities to operate one or more Exchanges. Rather than Continental or Country boundaries, the optimal regional aggregation should be Metropolitan Internetwork Exchanges (MIX). This fits well with the two byte global routing goal, as there are Simpson expires in six months [Page 7] DRAFT Allocation by Exchange March 1995 fewer than 65,000 metropolitan areas. The discrete topological nature of Exchange-based assignment should avoid political jurisdiction disputes, as these are primarily related to paths and types of links. In the face of such pressures, the Exchanges will simply avoid making such direct connections, and traffic will be routed along more indirect paths. 4.2. Competition Exchange-based assignment should provide healthy competition between Providers, as there are no barriers to rapid change by customers. Providers which attempt to create exclusive "captive" Exchanges will be easily thwarted by Subscribers which interconnect at other Exchanges, and pass transit traffic to these captive Exchanges. Legislative or administrative prohibitions against such transit traffic would turn captive Exchanges into disconnected islands, which have no value to Subscribers. Instead, Providers can improve perceived competitiveness by offering connectivity to many Exchanges. This will provide an economic incentive to enhance interconnection, and thereby Internet robustness. 4.3. Route Selection Coarse route selection may be accomplished by using the longest bit- wise prefix match, which will select the topologically closest common Exchange. Other source-selected policy-based routing is beyond the scope of this specification. 4.4. Annealing Annealing of partitioned Administrative Domains which are multiply connected is easily accomplished by advertisement by the other Exchange(s) of the longest set of prefixes matching the partition. Simpson expires in six months [Page 8] DRAFT Allocation by Exchange March 1995 4.5. DNS Exchange administrators should provide co-located DNS servers, in order to optimally provide external DNS visibility of name registration, and internal Resource Record caching for connected Domains. Simpson expires in six months [Page 9] DRAFT Allocation by Exchange March 1995 Security Considerations Security issues are not discussed in this memo. Acknowledgements The author is grateful to discourse with Vadim Antonov, Steve Deering, Fred Rabouw, and other members of the SIPP and IPv6 Working Groups. Concepts were also adopted from [RFC-1518]. References [RFC-1219] Tsuchiya, P., "On the Assignment of Subnet Numbers", RFC 1219, April 1991. [RFC-1518] Yakov Rekhter, Tony Li, "An Architecture for IP Address Allocation with CIDR", February 1993. Author's Address Questions about this memo can also be directed to: William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com Simpson expires in six months [Page 10] DRAFT Allocation by Exchange March 1995 Table of Contents 1. Constraints ........................................... 1 1.1 Administration .................................. 1 1.2 Aggregation ..................................... 1 1.3 Allocation ...................................... 2 1.4 Access .......................................... 2 2. Rejected Considerations ............................... 3 2.1 Hierarchy ....................................... 3 2.2 Regional Registries ............................. 3 2.3 Provider/Subscriber Dichotomy ................... 4 2.4 Ownership ....................................... 5 3. Allocation Plan ....................................... 6 3.1 Exchanges ....................................... 6 3.2 Administrative Domains .......................... 6 3.3 Routers ......................................... 7 3.4 Hosts ........................................... 7 4. Implementation Considerations ......................... 7 4.1 Regions ......................................... 7 4.2 Competition ..................................... 8 4.3 Route Selection ................................. 8 4.4 Annealing ....................................... 8 4.5 DNS ............................................. 9 SECURITY CONSIDERATIONS ...................................... 10 ACKNOWLEDGEMENTS ............................................. 10 REFERENCES ................................................... 10 AUTHOR'S ADDRESS ............................................. 10 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 6 08:09:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16109; Mon, 6 Mar 95 08:09:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16103; Mon, 6 Mar 95 08:09:00 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04263; Mon, 6 Mar 1995 08:01:38 -0800 Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA15985; Mon, 6 Mar 95 08:01:37 PST Message-Id: <9503061601.AA15985@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0553; Mon, 06 Mar 95 11:01:31 EST Date: Mon, 6 Mar 95 11:01:30 EST From: yakov@watson.ibm.com To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Last Calls - Unicast Assignment Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Mon, 6 Mar 95 13:57:41 GMT While on the topic of possible alternatives for address allocation, here is another proposal (from Tony Li and myself). Comments are welcomed. Yakov. -----------------------------------cut here--------------------------------- - 1 - Network Working Group Y. Rekhter INTERNET DRAFT T.J. Watson Research Center, IBM Corp. T.Li cisco Systems March 1995 Stratum-based Aggregation of Routing Information Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. 1 Introduction Classless Inter-Domain Routing (CIDR) [1], [2] is used in the Internet as a mechanism to improve scaling properties of the Internet routing system. Above the domain level CIDR specifies two more levels of routing hierarchy where routing information aggregation could occur -- direct provider boundaries, and continental boundaries. This document generalizes the idea of routing information aggregation at the continental boundaries by introducing the concept of a "stratum" and "stratum-based" aggregation. Additional levels of Expiration Date September 1995 [Page 1] - 2 - stratum-based routing hierarchy may be used to further reduce the amount of routing information necessary for global routing and thus improve the overall scaling properties of the Internet routing system. 2 Terminology If several providers are interconnected together, then we'll refer to such interconnection as an "exchange". An exchange may be realized either at the IP layer (e.g. a backbone), or at the Data Link layer (e.g. MAE-East, JIX, an NSFNET NAP). From an administrative point of view an exchange may be a provider, or a joint venture operated by a group of providers. We define a "stratum" as a set of providers P connected to a set of exchanges E, such that connectivity among the providers in P is achieved solely by the providers in P and the set of exchanges in E. In an extreme case a stratum is a single exchange with the set of providers (directly) connected to it. A provider connected only to the exchange(s) within a single stratum is called an "intra-stratum" provider. A provider connected to the exchanges in multiple strata is called an "inter-stratum" provider. An inter-stratum provider that is connected to a given stratum, and provides a uniform transit service (carries transit traffic) for all the intra-stratum providers (and their subscribers) within the stratum is called an "equal access" inter-stratum provider (with respect to that stratum). By definition an equal access inter- stratum provider for a given stratum can not discriminate its transit services with respect to the individual intra-stratum providers (and/or their subscribers) of the stratum -- an equal access inter- stratum provider connected to an exchange has to have fairly uniform peering agreements with all the intra-stratum providers connected to that exchange. 3 Strata-based address allocation and aggregation An exchange of a stratum acts as a concentration point for routing. Therefore, the set of exchanges of a given stratum presents a natural Expiration Date September 1995 [Page 2] - 3 - boundary for another level aggregation of routing information. To make the most effective use of stratum-based aggregation, it is necessary that a stratum be assigned an appropriate contiguous block of IP addresses. Intra-stratum providers within the stratum would allocate their addresses from this block. Subsequent address allocation to individual subscribers is expected to be consistent with the guidelines specified in [2]. An equal access inter-stratum provider that is (directly) connected to an exchange of a given stratum should be able to aggregate reachability information for all the subscribers whose addresses are taken out of the block assigned to the stratum (which may include subscribers of any provider that is part of the stratum) into a single address prefix (rather than carrying multiple address prefixes, one per provider), thus reducing the volume of routing information that needs to be carried. Note that there are numerous exceptions to the stratum-based aggregation, in which an inter-stratum provider spans several strata, but wants selectively control the set of destinations for which it provides the transit service (the provider is not an equal access provider). These exceptions could be handled similarly to multi-homed routing domains, as discussed in [2]. It is not clear whether strata-based address allocation and aggregation is suitable for sites directly attached to a provider, such that the provider is connected to one or more exchanges of a stratum, as well as to other provider(s) outside the stratum (or to other stata), as such a provider doesn't clearly fall into either intra-strata or inter-strata category. 4 Other applications of stratum-based aggregation Strata-based aggregation of routing information could be accomplished even in the absence of stratum-based address allocation; however the benefits (and the impact) is expected to be less significant. One such application of stratum-based aggregation is to absorb the entropy introduced within the pure (direct) provider-based addresses. For the cases where a subscriber switches from one single-stratum provider to another and doesn't renumber, if both the old and the new providers are within a common stratum, then any inter-stratum Expiration Date September 1995 [Page 3] - 4 - provider that is connected to at least one of the exchanges of the stratum, and provides the same transit service to both the old and the new providers need not propagate the additional overhead beyond its routers directly connected to the exchanges of the stratum. Likewise, if a multi-homed subscriber is connected to multiple intra-stratum providers, all of whom are within a common stratum, then any inter-stratum provider provider that is connected to at least one of the exchanges of the stratum, and provides the same transit service for all these intra-stratum providers need not propagate the additional overhead beyond its routers directly connected to the exchanges of the stratum. While the examples described in this section don't require equal access inter-stratum providers, they still assume a fair degree of uniformity with respect to the peering agreements between the inter- stratum provider and the intra-stratum providers within a given exchange. Non-uniformity is likely to further reduce the potentials for the stratum-based aggregation. While the examples described in this section do not require stratum-based address allocation, they could be realized in conjunction with the stratum-based address allocation. 5 Aggregation on entrance vs aggregation on exit An inter-stratum provider connected to an exchange of a given stratum may aggregate the routing information it receives from other intra- stratum providers connected to the exchange either (a) at the router(s) connected to the exchange, or (b) at some other routers (connected to the exchanges of other strata). We'll refer to the former as "aggregation on entrance", and to the latter as "aggregation on exit". Aggregation on exit may occur when the cost of links used by an inter-stratum provider is very high (an example of this scenario is an inter-stratum provider that employs trans-oceanic links to interconnect exchanges of strata on different continents). If aggregation is performed "on entrance", then routing information about unreachable destinations within that exchange can only reside on that router. Alternatively, if stratum-based aggregation is done "on exit", the router (of the inter-stratum provider) that is connected to another exchange can perform the aggregation. This Expiration Date September 1995 [Page 4] - 5 - means that packets to destinations which are part of the exchange aggregation, but for which there is not a corresponding more specific prefix can be rejected before leaving the exchange near which they originated. For example, suppose that a set of providers and exchanges in Europe form a stratum, and the stratum is assigned a prefix of <194.0.0.0 254.0.0.0>, such that European routing also contains the longer prefixes <194.1.0.0 255.255.0.0> and <194.2.0.0 255.255.0.0>. Also suppose that a set of providers and exchanges in North America form a stratum, and that there is an equal access inter-stratum provider that interconnects the exchange of the stratum in Europe with an exchange of the stratum in North America (the provider is willing to carry all the traffic for all the subscribers of the provides within the stratum in Europe). Then all of the longer European prefixes may be advertised across a trans-Atlantic link of the inter-stratum provider to North America. The router that belongs to the provider and is connected to the exchange in North America would then aggregate these routes, and only advertise the prefix <194.0.0.0 255.0.0.0> into North American routing. Packets which are destined for 193.1.1.1 would traverse North American routing, but would encounter the North American router which performed the European aggregation. If the prefix <194.1.0.0 255.255.0.0> is unreachable, the router would drop the packet and send an ICMP Unreachable without using the trans-Atlantic link. 7 Implications on Renumbering If a subscribers (e.g. a site) changes its provider, such that the old and the new providers are in different strata, then to contain routing information overhead the site has to change its IP addresses (renumber). If a provider within a stratum changes its connectivity to other providers, such the provider moves out of the stratum, to contain routing information overhead the provider and all of its subscribers have to change their addresses (renumber). Since a set of exchanges form an essential component of a stratum, changes in the set of exchanges may result in dissolving the stratum. If the old stratum is dissolved and a new one is formed, then to contain routing information overhead everyone in the set difference between the providers and all of their subscribers in the new Expiration Date September 1995 [Page 5] - 6 - stratum, and the providers and all of their subscribers in the old stratum have to change their addresses (renumber). For example if the set of exchanges of a stratum consists of a single exchange, and the exchange dissolves, to contain routing information overhead without renumbering any of the providers or their subscribers, a new exchange has to be established and all the providers connected to the dissolved exchange have to connect to the new exchange. 7 Conclusions Strata-based routing information aggregation may be used as part of CIDR to further improve scaling properties of the Internet routing system. Essential to the stratum-based aggregation are two preconditions: - stratum-based address allocation; - presence of equal access inter-stratum providers. Routing information reduction due to the stratum-based address allocation presuppose the existence of equal access inter-stratum providers. It is the equal access inter-stratum providers that are expected to gain most out of the stratum-based address allocation. Inter-stratum providers that don't provide equal access are likely to derive little or no benefits from the stratum-based address allocation. In the absence of equal access inter-stratum providers the usefulness of stratum-based address allocation is questionable -- forming a stratum with no equal access inter-stratum providers attached to the stratum may bring little or no reduction in the volume of routing information. Use of stratum-based address allocation for hierarchical routing is not a panacea for renumbering. Use of stratum-based address allocation should be carefully balanced against possible long-term instabilities of the exchanges that are part of a stratum. Such instabilities may cause dissolvement of the stratum. Dissolving a stratum may either create additional routing information, or would require massive renumbering that spawns multiple providers with all of their subscribers. Expiration Date September 1995 [Page 6] - 7 - Strata-based aggregation described in this document could be applied both to IPv4 and IPv6 [3]. 8 Security Considerations Security issues are not discussed in this document. 9 Acknowledgments [TBD] 10 Authors' Addresses Yakov Rekhter T.J. Watson Research Center, IBM Corporation 30 Saw Mill River Road, Hawthorne, NY 10532 Phone: (914) 784-7361 email: yakov@watson.ibm.com Tony Li cisco Systems, Inc. 1525 O'Brien Drive Menlo Park, CA 94025 Phone: (408) 526-8186 email: tli@cisco.com 10 References [1] Fuller, V., Li, T., Yu, J., and Varadhan, K., `Supernetting: an Address Assignment and Aggregation Strategy', RFC1519, September 1993 [2] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation with CIDR", RFC1518, September 1993 [3] Rekhter, Y., Li, T., "An Architecture for IPv6 Unicast Address Expiration Date September 1995 [Page 7] - 8 - Allocation" Internet Draft, October 1994 Expiration Date September 1995 [Page 8] ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 6 09:08:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16196; Mon, 6 Mar 95 09:08:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16190; Mon, 6 Mar 95 09:08:26 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10575; Mon, 6 Mar 1995 09:01:03 -0800 Received: from alink-gw.apple.com by Sun.COM (sun-barr.Sun.COM) id AA28924; Mon, 6 Mar 95 09:01:02 PST Received: from federal-excess.apple.com by alink-gw.apple.com with SMTP (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA21788; Mon, 6 Mar 95 09:01:00 -0800 for ipng@sunroof.eng.sun.com Received: from lilith.lansys.apple.com by federal-excess.apple.com (5.0/1-Nov-1994-eef) id AA11182; Mon, 6 Mar 1995 08:59:36 +0800 for ipng@sunroof.eng.sun.com Received: (justin@localhost) by lilith.lansys.apple.com (8.6.9/A/UX 3.1) id JAA11323; Mon, 6 Mar 1995 09:01:06 -0800 Date: Mon, 6 Mar 1995 09:01:06 -0800 From: "Justin C. Walker" Message-Id: <199503061701.JAA11323@lilith.lansys.apple.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: Steve Deering's message of Mon, 27 Feb 1995 11:29:38 PST <95Feb27.112949pst.12174@skylark.parc.xerox.com> Subject: (IPng) IPng Working Group Last Calls Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM A couple of minor comments on: An Architecture for IPv6 Unicast Address Allocation draft-ietf-ipngwg-arch-addr-01.txt 1) Reference [1] in this doc is to the SIPP version of the addressing architecture document (and an I-D, at that!). 2) In the recommendations (6.1) a *strong* recommendation is made to allocate based on prefixes assigned to TRD's. In the discussion on multi-homed domains (5.4.2), it is pointed out that this can be a problem when renumbering. Since the ability to change providers at the drop of a hat seems to be important, is this a conflict? Overall, I support moving this document along. Regarding An IPv6 Global Unicast Address Format draft-ietf-ipngwg-address-format-01.txt I support moving this along as well, although, since it is specifically defining an architecture for the provider realm, it would be nice to see an out-pouring of support fromt the providers :-}. Regards, Justin Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | They sentenced me to 20 years Apple Business Systems | of boredom Apple Computer, Inc. | For trying to change the system 10500 North De Anza Blvd | from within Cupertino, CA 95014 | LC *---------------------------------------*------------------------------------* ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 6 09:59:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16227; Mon, 6 Mar 95 09:59:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16221; Mon, 6 Mar 95 09:58:58 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16519; Mon, 6 Mar 1995 09:51:37 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA10365; Mon, 6 Mar 95 09:51:37 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 7 Mar 95 02:50:12 +0900 From: Masataka Ohta Message-Id: <9503061750.AA09042@necom830.cc.titech.ac.jp> Subject: re: Re: (IPng) National Registry of Routing is Har To: ipng@sunroof.Eng.Sun.COM Date: Tue, 7 Mar 95 2:50:10 JST In-Reply-To: ; from "Alan.Lloyd@datacraft.com.au" at Mar 4, 95 12:34 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan; > begin 600 attach.Z > M'YV0:=R,>7/&31HZ;URTF7,&@,.'$"-*G$BQHL6+&"N"V&BC(P@`&T'$H$'C > M8\B1)4&&##FCQLB--6[(B$F2QDN1,D;"`+DSH\^?0(,*E5AG#ITP M3!@V0RDR=0HUJM6K6+-JW"\87HF39DY(!"F15,&!)LT1D&8>9.T > M:,`S:]O>H4L&A(@A4H)`$0$B((@V>=R&B2O6J`L02>B`N+,8A)LWDA4,=&-4 > M3ITQ=-+8*>/BJVD%5-B"J.-FKAPZK,/0:6LF#&@0;\R`>,IF+=S":.F@D9T7 > M!!PT;]RTG9/':)DVD^FN02LFL?#?"MS(3I/\*0@Y9 M>OLT;&27D>,]S!GPS\NXH4.]#)T[9>@'@E-RR&&6'&@I@`(< Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16291; Mon, 6 Mar 95 10:31:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16285; Mon, 6 Mar 95 10:31:44 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20758; Mon, 6 Mar 1995 10:24:21 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA18179; Mon, 6 Mar 95 10:24:20 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-18.dialip.mich.net [141.211.7.154]) by merit.edu (8.6.10/merit-2.0) with SMTP id NAA29212 for ; Mon, 6 Mar 1995 13:24:16 -0500 Date: Mon, 6 Mar 95 17:39:28 GMT From: "William Allen Simpson" Message-Id: <4137.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Strata Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: yakov@watson.ibm.com > Ref: Your note of Mon, 6 Mar 95 13:57:41 GMT > > While on the topic of possible alternatives for address > allocation, here is another proposal (from Tony Li and > myself). Comments are welcomed. I presume this means that you are withdrawing your earlier drafts during the last call? Thank you for an action long overdue. While I am very happy that you are coming around to the MIX view as long espoused by Deering, it seems to me to be too little, too late. I'd say this was intended to confuse, coming in reply to my posting. Indeed, examination shows that it is nearly identical to your IPv4 internet-draft of January. Only the word "strata" has been changed to "stratum". A quick edit, and it's posted to IPv6. The examples are all for IPv4. It is still very hierarchical. It is very complex. Formation of a "stratum" requires cooperation between "set of providers P connected to a set of exchanges E, such that connectivity among the providers in P is achieved solely by the providers in P and the set of exchanges in E." A single Exchange is much easier to understand and manage. It assumes uniform peering agreements, rather than leaving it up to the Administrative Domains. Therefore, it probably won't work in practice. It still assumes only one RDI per Administrative Domain, and thereby only one address per interface. It still assigns everything based on Provider, and thereby gives ownership of addresses to Providers. It still won't scale in a multi-provider "multi-stratum" environment. Yet, this is the most desirable situation. What's the point of having more providers which don't improve your overall connectivity? It has several problems with the decision for when to aggregate, on "entrance" or on "exit" to a link. This problem arises because of attempts to aggregate at backbone links, instead of Exchanges. If a Provider withdraws, every user of the "stratum" has to renumber. This is antithetical to the IX concept, which is non-hierarchical. It provides benefits only to "equal access intra-stratum providers" (backbones), and not to short haul providers and subscribers. It provides no economic incentives for "strata" to form. All of these problems are eliminated by using the IX concept instead. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 6 11:01:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16328; Mon, 6 Mar 95 11:01:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16322; Mon, 6 Mar 95 11:01:08 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24803; Mon, 6 Mar 1995 10:53:43 -0800 Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA24817; Mon, 6 Mar 95 10:53:43 PST Message-Id: <9503061853.AA24817@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 4271; Mon, 06 Mar 95 13:53:40 EST Date: Mon, 6 Mar 95 13:53:40 EST From: yakov@watson.ibm.com To: ipng@sunroof.Eng.Sun.COM, bsimpson@morningstar.com Subject: (IPng) Strata Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Mon, 6 Mar 95 17:39:28 GMT Bill, >I presume this means that you are withdrawing your earlier drafts >during the last call ? Your assumption is incorrect -- I have no plans to withdraw the drafts. Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 6 13:36:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16419; Mon, 6 Mar 95 13:36:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16413; Mon, 6 Mar 95 13:36:08 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14927; Mon, 6 Mar 1995 13:28:47 -0800 Received: from CLYNN.BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA29486; Mon, 6 Mar 95 13:28:46 PST Message-Id: <9503062128.AA29486@Sun.COM> Date: Mon, 6 Mar 95 16:24:37 EST From: Charles Lynn To: ipng@sunroof.Eng.Sun.COM Cc: CLynn@BBN.COM Subject: Re: (IPng) WG last call: v6 ICMP draft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, I do not think that draft-ietf-ipngwg-icmp-01.txt is ready to be advanced. Since ICMP plays a key role in Path MTU Discovery, and since no IPv6 document describing the procedures for MTU discovery, with all the complications introduced by truncation, ESP, ERP, header insertion by security firewalls or routing agents, etc., is available for review, I am not able to conclude that the ICMP as described is adequate. page 4: Header value of in the immediately preceding header. (NOTE: | ICMP(), and the entire ICMP message starting with the ICMP | Fill in TBD with 58. Page 5: (a) If an IPv6 ICMP message of unknown type is received, it MUST be silently discarded. For extensibility, wouldn't it be better to pass all errors (Type < 128) to the transport layer, even if ICMP itself does not understand the Type? (b) Every IPv6 ICMP error message (the first four messages in the above list) includes as much of the IPv6 offending (invoking) "Type < 128" instead of referencing the list. (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. I think that this is inadequate for two reasons. First, truncation as specified in (b) may loose the Extension Header before the transport header making it impossible to determine the appropriate transport layer; note that the transport layer ports would also be missing. The second case is when there is an ESP header that obscures the required demultiplexing information, which may have been truncated due to (b). Note also that the originating system may not have the keys to decrypt the returned packet (fragment). It might be the case that the originator will have to keep state information -- SAID+32 bits, transport session -- to perform the demultiplexing. These problems imply that some other mechanism must be used to perform the demultiplexing. How about something like adding 64 bits (to maintain alignment) of additional header to the error types to be used as follows. a) If there is an ESP header, the first 32 bits contain the SAID and the second 32 bits contain the 32 bits immediately following the SAID. b) If there is no ESP header, the first 32 bits contain 24 bits of zero and 8 bits of transport protocol number. If the transport protocol number is 59, "No Next Header", the second 32 bits are zero, otherwise, they are the first 32 bits of the transport header, presumably the source and destination port numbers. (d.1.)an IPv6 ICMP error message, or | Insert "Types < 128". page 6: (d.5.)a packet whose source address does not uniquely identify a single node -- e.g., the IPv6 Unspecified Address, or an IPv6 multicast address. What about Cluster/Pack addresses? What procedure is used to identify such addresses? (e) Finally, to each sender of an erroneous data packet, an IPv6 Is there any analysis of the impact of limiting error reports on Path MTU Discovery? page 7: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ per comment above, 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | additional demultiplexing ,,,, | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ page 8: Packet Too Big Message | We need procedures for how encapsulators handle these messages. A harder problem is how firewalls or other systems that insert headers get correct information back to the source. Maybe this will be covered in the Path MTU Discovery document. page 10: If a router receives a packet with a Hop Limit of zero, or a router decrements a packet's Hop Limit to zero, it discards the packet and Ought to clarify that the decrement only happens when packets are forwarded; packets received with a zero Hop Limit destined to a higher layer are delivered and the Hop Limit is not decremented. There are interactions between fragmentation/reassembly and ESP that should be described. The case of a Fragmentation Header then an ESP header only requires that the original (encrypted) first fragment be retained for possible inclusion in a Time Exceeded message. The case of an ESP Header then a Fragmentation Header is a little more complex. Each packet containing an ESP header would have to be retained -- either decryption to a second buffer, or a packet copy then decryption in place -- until it can be ascertained that the packet does not contain a Fragmentation Header with offset zero. If it is fragment zero, it should be retained for a possible Time Exceeded message. It sounds like decryption in place to save a packet copy is not consistent with the ICMP requirements. page 11: Parameter Problem Message The same issue of saving a packet with an ESP Header until the decrypted packet has been processed arises here. Is the "leaking" of a pointer into the encrypted portion of the packet a serious threat? page 13: Echo Request Message | & Echo Reply Message | Every node MUST implement an ICMP Echo responder function that | receives Echo Requests and sends corresponding Echo Replies. A node SHOULD also implement an application-layer interface for sending Echo Requests and receiving Echo Replies, for | diagnostic purposes. What procedures should the responder use when the Echo Request: a) contains an Authentication Header but no ESP Header? - Should the reply also contain an Authentication Header? - What if there is no SAID for the reply? Must one be established for the reply? Should an unauthenticated reply be sent if no SAID is available? Should a "well known SAID with well known Key" be used? b) contains an ESP Header? - Should the reply contain an ESP Header? - What if there is no SAID for the reply? - Should the reply ever be sent as cleartext if the request was not? Should a system operating in the "requires authentication/authenticates" and or "confidentiality" mode(s) be required to respond to unauthenticated(cleartext) Echo Requests, presumably for diagnostic purposes? Do we want a SHOULD respond to unauthenticated/cleartext Echo Request with unauthenticated/cleartext Echo Reply unless explicitly configured by system administration to not do so? How serious id the threat to probing for valid SAIDs, etc., using ICMP Echos? Should there be a "well known SAID" with "well known key(s)" to permit interoperability testing, etc.? page 14: The data received in the ICMP Echo Request message MUST be returned | entirely and unmodified in the ICMP Echo Reply message, unless the | Echo Reply would exceed the MTU of the path back to the Echo | requester, in which case the data is truncated to fit that path MTU. | Does this mean that the echo responder MUST have performed Path MTU Discovery to the sending system before sending the Echo Reply? Must the responder retain the Echo Reply message in case it subsequently receives a Packet Too Big message? Is it explicitly improper for the included message to be used for the Echo Reply (as it might be shorter than path MTU)? page 16: typo The address if the multicast group about which the "of" Charlie ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 6 15:48:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16485; Mon, 6 Mar 95 15:48:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16479; Mon, 6 Mar 95 15:48:30 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01133; Mon, 6 Mar 1995 15:41:08 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA27566; Mon, 6 Mar 95 15:41:07 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13695; 6 Mar 95 17:23 EST 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 Subject: (IPng) I-D ACTION:draft-ietf-ipngwg-sec-00.txt Date: Mon, 06 Mar 95 17:23:19 -0500 Message-Id: <9503061723.aa13695@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPv6 Security Architecture Author(s) : R. Atkinson Filename : draft-ietf-ipngwg-sec-00.txt Pages : 15 Date : 03/03/1995 The Internet community is making a transition from version 4 of the Internet Protocol (IPv4) to version 6 of the Internet Protocol (IPv6). [Hi94] This memo describes the security mechanisms integrated into version 6 of the Internet Protocol (IPv6) and the services that they provide. Each security mechanism is specified in a separate document. It also describes key management for the IPv6 security mechanisms. 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-sec-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-sec-00.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) 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-sec-00.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: <19950306171943.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-sec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-sec-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950306171943.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 6 15:47:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16478; Mon, 6 Mar 95 15:47:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16472; Mon, 6 Mar 95 15:47:38 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01045; Mon, 6 Mar 1995 15:40:16 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA27333; Mon, 6 Mar 95 15:40:08 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13681; 6 Mar 95 17:23 EST 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 Subject: (IPng) I-D ACTION:draft-ietf-ipngwg-auth-00.txt Date: Mon, 06 Mar 95 17:23:09 -0500 Message-Id: <9503061723.aa13681@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPv6 Authentication Header Author(s) : R. Atkinson Filename : draft-ietf-ipngwg-auth-00.txt Pages : 10 Date : 03/03/1995 The Internet community is working on a transition from version 4 of the Internet Protocol (IPv4) to version 6 of the Internet Protocol (IPv6). This memo describes the IPv6 Authentication Header. This optional header provides strong integrity and authentication for IPv6 datagrams. Non-repudiation might be provided by an authentication algorithm used with the Authentication Header, but it is not provided with all authentication algorithms that might be used. Confidentiality, and protection from traffic analysis are not provided by the Authentication Header. Users desiring confidentiality should consider using the IPv6 Encapsulating Security Protocol (ESP) either in lieu of or in conjunction with the Authentication Header. [Atk95b] This document assumes the reader has previously read and understood the related IPv6 Security Architecture document which defines the overall security architecture for IPv6 and provides important background information for this specification. [Atk95a] 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-auth-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-auth-00.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) 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-auth-00.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: <19950303111617.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-auth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-auth-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950303111617.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 6 21:23:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16664; Mon, 6 Mar 95 21:23:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16658; Mon, 6 Mar 95 21:22:58 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28462; Mon, 6 Mar 1995 21:15:36 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA04851; Mon, 6 Mar 95 21:15:36 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA17298; Tue, 7 Mar 95 00:15:30 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503070515.AA17298@wizard.gsfc.nasa.gov> Subject: (IPng) Base IPv6 Specification: Robust Service vs Lack of Header Checksum To: ipng@sunroof.Eng.Sun.COM Date: Tue, 7 Mar 1995 00:15:29 -0500 (EST) Cc: bill@wizard.gsfc.nasa.gov X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I am seriously concerned about the lack of a header checksum in IPv6 and the potentially significant negative impact this lack could have on the Internet. >From RFC 1726, "Technical Criteria for Choosing IP The Next Generation (IPng)", Section 5.4, Robust Service: > CRITERION > The network service and its associated routing and control > protocols must be robust. > > DISCUSSION > Murphy's Law applies to networking. Any proposed IPng protocol > must be well-behaved in the face of malformed packets, mis- > information, and occasional failures of links, routers and hosts. > IPng should perform gracefully in response to willful management > and configuration mistakes (i.e., service outages should be > minimized). > > Putting this requirement another way, IPng must make it possible > to continue the Internet tradition of being conservative in what > is sent, but liberal in what one is willing to receive. > > We note that IPv4 is reasonably robust and any proposed IPng must > be at least as robust as IPv4. Given that we expect IPv6 to be at least as robust as IPv4, and hopefully much more so, it would seem that the removal of any robustness features from IPv4, such as the header checksum, would have a detailed rationale section in either the IPng Overview document or the IPv6 Specification, but I could not find any such discussion. There is a short explanation later in the IPng Technical Criteria document, namely in Section 6, Things We Chose Not to Require: > 6.2 IP Header Checksum > > There has been discussion indicating that the IP Checksum does not > provide enough error protection to warrant its performance impact. > The argument states that there is almost always a stronger datalink > level CRC, and that end-to-end protection is provided by the TCP > checksum. Therefore we believe that an IPng checksum is not required > per-se. This argument was reaffirmed in a mail message from Craig Partridge to the big-internet e-mail list: > It [the paragraph above] says that local address integrity is sufficiently > protected by the link CRC and that end-to-end integrity of the IP datagram > is ensured by the end-to-end TCP checksums. Simple engineering. I heard this same basic argument repeated by Steve Deering at a recent interim IPng Working Group meeting. However, I think there is an architectural flaw in this argument. This argument maintains that we are protected by: 1. Data link CRC 2. End-to-end TCP/transport checksum The data link CRC protects the individual link layer while the end-to-end TCP/transport checksum protects the end host/process recipient of IP datagrams, but there does not appear to be any protection whatsoever for the Internet itself, namely the collection of all connected routers and networks that make up the Internet. A full analysis of the impact to the Internet as an entity would need to be done that could be caused by corruption to the various IPv6 header fields that might be introduced by broken data link layers or broken routers (either due to outright hardware failures or possibly caused by flaky experimental or prototype data links or routers). As an illustration of some of the possible failure scenarios, although certainly not exhaustive since the failures that actually occur that we never conceived of can be just as damaging or even more damaging than those we did anticipate, I'll list the following (for the sake of argument, I'm considering the worst case where the data link or router is hard broken in a consistent manner): 1. Multicast group ID corruption A very high bandwidth transmission with global scope is being sent to a small membership group over high performance data links. One of these data links is broken and causes the multicast group ID to be changed to a different, but still valid multicast group ID, which also has a global scope but has a very large membership with a much larger geographic coverage. Basically, this causes the small, very high bandwidth transmission to be erroneously grafted onto the more geographically distributed session with its very large membership. Note that in general the originating source (whose address might also be corrupted) won't receive any kind of notification that something is wrong (specifically ICMP error messages are not generated for multicast addresses). In particular, in the case of television, movie, or other video transmission, it may be strictly a transmit only channel with no return path. IMPACT: Possibly major traffic impact on all the routers and data links, including possibly international links, that make up the multicast distribution tree for the session with the very large membership, even though they really should never be bothered with the traffic from the very high bandwidth transmission. This bogus traffic may be sufficient to effectively wipe out the legitimate use of the session with the very large membership (or other unrelated sessions that are using the same routers and data links). 2. Multicast scope corruption This is similar to the first case, except that the scope field becomes corrupted, for example effectively being changed to a larger value/scope, e.g. a global scope. This is probably most problematic with well known multicast group IDs for particular services, since the same multicast group ID is likely to exist at different scope levels. IMPACT: What should be localized traffic effectively becomes non-localized, affecting other routers and data links that should not be affected. 3. Unicast destination address corruption This simply causes misdelivery of packets and would mostly be covered by the end-to-end TCP/transport checksum. IMPACT: Some routers and data links along the erroneous data path would have to carry some unnecessary traffic, although this case is not nearly as serious as the multicast address corruption case. 4. Source address corruption Although not as serious, this would prevent notifications from being able to be sent to a malfunctioning host. It would seem prudent to allow filtering of such packets at an early point in the path, since the ultimate destination would not have a valid address to send error messages or other notifications to. Consider the cases we have seen on the MBone with people sending unattended, high bandwidth video. If we can insure that the source address has not been corrupted, we can easily determine the source of the bogus transmissions and take corrective action. Without the protection of an IP header checksum, if the source address were to become corrupted in such cases, it would be much more difficult to locate the source of the problem, and the problem would continue unabated since there would be no mechanism available to filter out the corrupted packets. IMPACT: When other malfunctioning or misbehaving activity was being inflicted by a broken or anti-social host, this might greatly increase the length of time that the damage being inflicted to the Internet would continue. I consider this a secondary level impact, since its main effect is only in conjunction with some other error condition. 5. Flow ID corruption This is similar to the multicast group ID corruption case, in that corruption of the flow ID field may cause the traffic from one data flow to be erroneously grafted onto an unrelated traffic flow with possibly dire consequences. For example, a given host may have both a high bandwidth, unicast flow and a low bandwidth, multicast flow that happen to share part of their data path. If one of the shared data links causes the unicast flow ID to be transformed into the multicast flow ID, the high bandwidth transmission may be grafted onto the otherwise low bandwidth, multicast flow, given that the IPv6 specification does not require that the destination address be matched against the flow ID. IMPACT: This is basically analogous to the multicast group ID corruption case. 6. Traffic class corruption This could cause flow-controlled traffic to become non-flow-controlled (or vice versa) or to cause lower priority traffic to become higher priority traffic (or vice versa). IMPACT: Beside the direct affect on the traffic encountering the corruption, this could also steal resources from other traffic by either effectively claiming a higher priority or by being treated as one class of traffic even though the source of traffic (actually being in the other class) wouldn't understand the flow and congestion control mechanisms of that class of traffic (I admit to being a little hazy on the exact ramifications of such a mismatch between the actual traffic class of a source and a router believing the source was in the opposite traffic class). 7. Hop Limit corruption If the hop limit were effectively reduced by corruption, this could cause a destination to become unreachable. In the case of a multicast destination, this could potentially blackhole a transmission. If the hop limit were effectively increased, it could possibly cause a routing loop to be perpetuated indefinitely. IMPACT: In the case of the hop limit being reduced, the only impact is wasting bandwidth that accomplishes no productive purpose. In the case of the hop limit being increased, additional bandwidth is wasted in the presence of a routing loop (which may build to fill the data links in the loop if it is a non-transient routing loop). 8. Payload length and next header corruption This case is mostly covered by the end-to-end TCP/transport checksum. However, corruption to the payload length could have an impact on Path MTU discovery, and corruption to either the payload length or next header fields could cause difficulties to routers in parsing a routing header or hop-by-hop options header, especially if the payload was not in fact a routing header or hop-by-hop options header, i.e. it was in actuality some other kind of payload. IMPACT: The impact would mostly be in checking the robustness of router sofware when confronted with a bogus payload in a routing header or hop-by-hop options header. I have not analyzed the consequences of what would happen if the bogus data actually appeared to be valid data. 9. Routing header and hop-by-hop options header corruption It is not clear to me what all the possible consequences are of corrupting the routing header (source route list), other than obviously misrouted traffic, or of corrupting the hop-by-hop options header, not having specific knowledge of any possible future use of this feature, such as for carrying a flow spec. IMPACT: Unknown 10. Corruption to fragment header, authentication header, or end-to-end options header Even though these headers are end-to-end in nature, they are not protected by the end-to-end TCP/transport checksum. It is not clear to me what all the possible consequences are of corrupting one of these headers, with special concern for corrupting the fragment header. IMPACT: Unknown As you can see, there are many possible failure scenarios described with varying degrees of impact to the Internet infrastructure. Murphy's Law is indeed very apt as it applies to networking. Since we are designing for an extremely large Internet, it's quite probable that even very low probability events are bound to happen to someone sometime, and none of us will be able to predict how much of an impact these local events will have on the overall Internet or large parts of the Internet when they do occur. It is therefore our responsibility to take appropriate precautions such as a header checksum, especially since the cost is relatively minor relative to the potential risk. Also, the types of problems I outlined above due to the lack of a header checksum may not manifest themselves in the early testing and deployment of IPv6, and may only crop up much later when the scale of the IPv6 Internet begins to rival that of the current IPv4 Internet, at which point it might be next to impossible to change the IPv6 packet format. I am especially concerned about the major impact on the Internet caused by the expected proliferation of new applications such as real-time, high-bandwidth, multimedia conferencing using multicasting and on-demand multimedia servers, if there isn't an IP header checksum to protect the Internet's routers and data pathways. I believe that flows, due to their inherent volume of traffic, may eventually predominate the overall traffic mix in the Internet. It thus might make sense to make certain optimizations for checking the checksum for flows. For example, to protect the Internet, the base IPv6 checksum could cover the following fields of the base IPv6 header: the version, flow label, hop limit, source and destination address fields. The payload length and next header fields would be protected by the end-to-end TCP/transport checksum, and I would also recommend that the routing header and hop-by-hop options header include their own pseudo-header checksum to protect these headers. In the above scheme, the checksum would be invariant for a particular flow, except of course for the hop limit. When a router received the first packet for a flow, it would compute the checksum and compare it against the checksum in the packet. If they match, it would adjust the checksum to what it would be if the hop limit were 0, and store this checksum with the soft state for the flow. It would decrement the hop limit by 1, and adjust the checksum in the packet accordingly via an incremental update computation. Then, when subsequent packets arrived for the same flow, all that would need to be done is to extract the checksum and hop limit, adjust the checksum by the hop limit, and compare it to the stored value. If they match, then the checksum is good, the hop limit is decremented by 1, the checksum in the packet is adjusted accordingly, and the packet is forwarded. If they don't match, the checksum is bad, and the packet is dropped. To make things even more efficient, it might (and I am only saying might) be reasonable to consider excluding the hop limit from the base IPv6 checksum, since the failure modes for corruption of the hop limit field don't appear to have nearly as dire consequences as there are for corruption of some of the other header fields. In that case, all that would be required would be to compute, compare, and store the initial checksum for a flow and then compare that against future checksums. All the above is meant to show that it is not necessarily true that efficiency/performance has to be majorly at odds with steps to protect the integrity of the Internet infrastructure. Continuing on down in the discussion of Robust Service in RFC 1726, the IPng Technical Criteria document: > Hostile attacks on the network layer and Byzantine failure modes > must be dealt with in a safe and graceful manner. > > We note that Robust Service is, in some form, a part of security > and vice-versa. > > The detrimental effects of failures, errors, buggy > implementations, and misconfigurations must be localized as much > as possible. For example, misconfiguring a workstation's IP > Address should not break the routing protocols. in the event of > misconfigurations, IPng must to be able to detect and at least > warn, if not work around, any misconfigurations. This is an extremely important architectural principle. The effect of errors SHOULD be localized as much as practical and there MUST be a mechanism available to allow localization of errors should one choose to do so, assuming one is willing to pay the cost of having this protection. Specifically, bad packets, i.e. packets corrupted by a broken data link layer or broken router, SHOULD be stopped at the earliest possible oppurtunity, to prevent their ill effects from being propagated any further than necessary. This is especially critical in the case of high-bandwidth muticast distributions to a very large, possibly global, multicast distribution tree. We do not want to waste enormous amounts of bandwidth on corrupted packets which can never be used. To accomplish this, the originator of data packets MUST compute and set the base IPv6 header checksum (for flows, it can use the same optimization discussed above for routers, i.e. computing/setting/storing the checksum for the first packet in a flow and then simply reusing the same checksum for subsequent packets). Routers in the path between the source and destination MAY check the checksum but wouldn't be required to do so. I think we should recommend that routers at entry and exit to routing domains SHOULD check the checksum to prevent corrupt packets from being propagated across routing domains. Specifically, sites MAY choose to enable this function at their border router(s) to insure that worthless (and possibly harmful) traffic neither enters or leaves their site. The destination host MAY check the checksum if it wants to, but this is not required if it is felt that the end-to-end TCP/transport checksum provides sufficient protection for the host. All of the above provides necessary protection for the Internet infrastructure, but doesn't require that it be turned on except where desired, and thus the cost to performance is minimal. Only the source host MUST set the base IPv6 header checksum to enable this ability (and there is an optimization for flows that makes the performance hit minimal). Everyone else then has the option of whether or not to make use of the ability. One place where it would certainly make sense to turn on the checksum checking would be in an Internet router that had a connection to an experimental or prototype data link layer. Another, which has already been mentioned, might be border routers between routing domains. Having the IPv6 header checksum doesn't make everyone use it (other than requiring the source to set it). However, not having it precludes anyone from ever being able to reject totally bogus, useless, and possibly harmful traffic that they don't want to pollute their network. The only other argument that I can see against having a checksum is that it would require a few extra bytes to carry it around in every packet. However, since going to 16 byte addresses I don't find this as compelling an argument, plus I fundamentally believe it's worth the tradeoff to carry a little more baggage to protect the Internet. > Due to its size, complexity, decentralized administration, error- > prone users and administrators, and so on, The Internet is a very > hostile environment. If a protocol can not be used in such a > hostile environment then it is not suitable for use in the > Internet. > > Some predictions have been made that, as the Internet grows and as > more and more technically less-sophisticated sites get connected, > there will be more failures in the network. These failures may be > a combination of simple size; if the size of the network goes up > by a factor of n, then the total number of failures in the network > can be expected to increase by some function of n. Also, as the > network's users become less sophisticated, it can be assumed that > they will make more, innocent and well meaning, mistakes, either > in configuration or use of their systems. > > The IPng protocols should be able to continue operating in an > environment that suffers more, total, outages than we are > currently used to. Similarly, the protocols must protect the > general population from errors (either of omission or commission) > made by individual users and sites. I am in agreement with this and it just reinforces why I feel so strongly we need an IPv6 header checksum. > Time Frame > We believe that the elements of Robust Service should be available > immediately in the protocol with two exceptions. > > The security aspects of Robust Service are, in fact, described > elsewhere in this document. > > Protection against Byzantine failure modes is not needed > immediately. A proposed architecture for it should be done > immediately. Prototype development should be completed in 12-18 > months, with final deployment as needed. Given all the above, the IPv6 Specification should be modified to include a header checksum before it becomes a Proposed Standard. -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 6 22:01:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16704; Mon, 6 Mar 95 22:01:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16698; Mon, 6 Mar 95 22:01:06 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00926; Mon, 6 Mar 1995 21:53:43 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA09656; Mon, 6 Mar 95 21:53:45 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA17382; Tue, 7 Mar 95 00:53:43 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503070553.AA17382@wizard.gsfc.nasa.gov> Subject: (IPng) Re: Base IPv6 Specification: Robust Service vs Lack of Header Checksum To: ipng@sunroof.Eng.Sun.COM Date: Tue, 7 Mar 1995 00:53:43 -0500 (EST) Cc: bill@wizard.gsfc.nasa.gov X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I forgot something. > Routers in the path between the source and destination MAY check the > checksum but wouldn't be required to do so. I think we should recommend > that routers at entry and exit to routing domains SHOULD check the > checksum to prevent corrupt packets from being propagated across > routing domains. The router obviously needs to decrement the hop limit, and if the base IPv6 checksum does include the hop limit field, then the router also needs to adjust the checksum accordingly. In this case, if the router did not check the base IPv6 checksum, then the router MUST NOT recompute the entire base IPv6 checksum, but MUST rather use the incremental update mechanism to simply modify the checksum of the incoming packet. If the base IPv6 checksum does not include the hop limit field, then the checksum of the incoming packet MUST NOT be changed. This is required to insure that the router does not pass on corrupted packets that would then have good checksums (if the packet was part of a flow, and it wasn't the first packet that was corrupted, the corruption could still be detected by another router downstream when it compared the checksum against its stored checksum for the flow). This is basically common sense but I still thought it was worth stating explicitly. -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 03:03:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16939; Tue, 7 Mar 95 03:03:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16933; Tue, 7 Mar 95 03:03:16 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12485; Tue, 7 Mar 1995 02:55:55 -0800 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA26930; Tue, 7 Mar 95 02:55:49 PST Received: by mitsou.inria.fr (8.6.10/8.6.10) id LAA19421; Tue, 7 Mar 1995 11:55:46 +0100 Message-Id: <199503071055.LAA19421@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Cc: bill@wizard.gsfc.nasa.gov Subject: Re: (IPng) Base IPv6 Specification: Robust Service vs Lack of Header Checksum In-Reply-To: Your message of "Tue, 07 Mar 1995 00:15:29 EST." <9503070515.AA17298@wizard.gsfc.nasa.gov> Date: Tue, 07 Mar 1995 11:55:44 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, Your arguments regarding header checksum were presented and debated at length during the two years of debate which preceded the IPng decision. They were overruled then. You are not presenting any new facts. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 05:35:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16970; Tue, 7 Mar 95 05:35:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16964; Tue, 7 Mar 95 05:34:07 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20341; Tue, 7 Mar 1995 05:25:34 -0800 Received: from sg543689.eng.chrysler.com by Sun.COM (sun-barr.Sun.COM) id AA10572; Tue, 7 Mar 95 05:25:15 PST Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id IAA24194 for ; Tue, 7 Mar 1995 08:25:12 -0500 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id IAA07796 for ; Tue, 7 Mar 1995 08:25:10 -0500 Received: from bobsgrid.is.chrysler.com by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA15567; Tue, 7 Mar 95 08:41:03 EST Message-Id: <9503071341.AA15567@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 07 Mar 1995 08:25:02 -0500 To: ipng@sunroof.Eng.Sun.COM From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: (IPng) apology and comment on performance impacts Cc: Ran Atkinson Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 04:01 PM 2/24/95 -0500, Ran Atkinson wrote: >All, > >I apologise publically to Jim Bound. > >This position seems entirely appropriate to me given the recurring >and quite serious security problems reported widely, for example >the recent CERT advisory on active attacks on terminal connections. >Further, non-governmental customers such as Boeing and Chrysler >have indicated that they would like to have security be implemented >and available for their use in IPv6. The requirement for real >IP security is being driven largely by non-government customers. I would like to point out that I am desparate for an IPSP implementation this year. This will be used for remote access workstations over public networks to a firewall. The performance hit is not too much an issue as the connect speed will be 14.4 to 28.8. Modem compression will be meaningless, for the most part, as I expect the IPSP implementation to do compression before encryption... I have some limited need for IPSP right now internally. I have DES hardware that I can use ($200 per seat, list). I hope there is some 'standard' for calling DES hardware by an application, though for some reason I don't think so :(. So when IPv6 comes along, I expect that things will be at least as good as with IPSP. Robert Moskowitz Chrysler Corporation (810) 758-8212 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 08:18:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17029; Tue, 7 Mar 95 08:18:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17023; Tue, 7 Mar 95 08:18:49 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29196; Tue, 7 Mar 1995 08:10:33 -0800 Received: from bastion.sware.com by Sun.COM (sun-barr.Sun.COM) id AA00209; Tue, 7 Mar 95 08:10:27 PST 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 KAA02336 for ; Tue, 7 Mar 1995 10:54:25 -0500 Received: by shlep.sware.com (5.65/2.0) from wanda.sware.com id AA01295; Tue, 7 Mar 95 11:10:25 -0500 Received: by wanda.sware.com.sware.com (1.38.193.4/2.0) id AA09856; Tue, 7 Mar 1995 11:11:49 -0500 Date: Tue, 7 Mar 1995 11:11:49 -0500 From: Ed Sale Message-Id: <9503071611.AA09856@wanda.sware.com.sware.com> To: ipng@sunroof.Eng.Sun.COM Cc: sale@sware.com In-Reply-To: <3954.bsimpson@morningstar.com> Subject: Re: (IPng) Gratuitous ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM (A proposed extension to IPng address autoconfiguration follows the discussion of the IPv4 question.) > ... > The quick fix for MacTCP and 4.4BSD is to use 0.0.0.0 as the source, > which hopefully won't update any cache. It does update caches on some systems. Worse, on those systems we encountered, the address 0.0.0.0 was used as the broadcast address and they began sending all their braodcast traffic to the system that last performed the duplicate address check. We ultimately gave our users the ability to turn this feature on or off. I sent a request to the IETF about 5 years ago (just after the Host Requirements doc came out indicating that 0.0.0.0 was an illegal address) asking the same question you did above. There was no consensus one way or the other. Steve Deering told me that he didn't think that this scheme had a prayer of being standardized. That was before there was talk of an IPng... > The question for us: do we want to add Self Solicitation for discovery > of duplicate addresses? I believe that we do. The problem is bad enough that we at least want to detect it so that the situation can be reported as Perry, and Bob Moskowitz have stated earlier. Detecting and avoiding the situation by auto-configuring a unique address would be even better. See below. > We could also separately check for duplicate link addresses, using > 0.0.0.0 as the IP Destination. > That's 2 multicast packets (including Router solicitation), plus a link > unicast, from every node at the initialization of every interface. There is only one EXTRA multicast packet, isn't there, since all nodes perform Router solicitation at interface initialization anyway? > I am of the opinion that it is not worth the bother. KRE has expressed > the opposite view in the Apple Networking Forum. Ok, you say it's not worth the bother. Put yourself into the shoes of a system administrator (you may already be one, I don't know). Two (or more) nodes come up with duplicate duplicate IEEE 802 addresses and therefore duplicate IPng link-local addresses, however you don't know this. All you know is that at one or more of the systems is acting flaky. How would you determine that the problem is in fact a duplicate address error? Besides, it's not much bother, the packet doesn't even have to be multicast if we're talking about the auto-configured link-local address. Since the link-local IP address is just the IEEE 802 address plus a known prefix, the request could be unicast to the local IEEE 802 address. This unicast destination address would reach ALL affected parties and ONLY those parties if an address conflict were present. We could perform duplicate address avoidance if we allowed more than 48 bits for the variable part of the link-local address. Call these extra bits the DLAA (Duplicate Link Address Avoidance) bits. Then use an algorithm like AppleTalk does (except use the unicast address as the destination address) to find a unique DLAA value in the cases where two or more nodes share the same 802 address. This would mean that some number of nodes would share the same link layer address but have unique IPng addresses. Now is the best time to address (pun intended :-) this problem. Seriously, if we don't do it now, the IPng situation will be just like the one I was in 5 years ago with IPv4. Let's do better this time. -- Ed Sale ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 08:20:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17041; Tue, 7 Mar 95 08:20:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17035; Tue, 7 Mar 95 08:19:46 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29217; Tue, 7 Mar 1995 08:10:54 -0800 Received: from atc.boeing.com by Sun.COM (sun-barr.Sun.COM) id AA00269; Tue, 7 Mar 95 08:10:48 PST Received: by atc.boeing.com (5.57) id AA02756; Tue, 7 Mar 95 08:15:26 -0800 Received: from commanche.ca.boeing.com. (commanche.ca.boeing.com) by splinter.boeing.com with SMTP (1.37.109.14/16.2) id AA084302587; Tue, 7 Mar 1995 08:09:47 -0800 Received: by commanche.ca.boeing.com. (AIX 3.2/UCB 5.64/4.03) id AA20430; Tue, 7 Mar 1995 08:10:41 -0800 Message-Id: <9503071610.AA20430@commanche.ca.boeing.com.> To: namedroppers@internic.net, ipng@sunroof.Eng.Sun.COM Subject: (IPng) DNS-DynUpd, ICMP Domain Name Messages, and IPv6 DNS Comments. Date: Tue, 07 Mar 95 08:10:41 -0800 From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I apologize for the length of time this post covers, I've been working on it for about 10 days (when not fighting production problems that far too often include DNS). This post covers a number of questions that have been asked within the DNSIND and IPng groups. bound@zk3.dec.com wrote: > I question whether the caching is actually being used to the degree > suggested and would like some operation folks to please respond to this > mail so we can get expert operations input on this one not just > engineering projections (steve d. this time I think the engineer > should listen). Examples are John Curran, Brian Carpenter, Robert Elz > (who also wear engineering hats but can get this data for in.arpa real > use).. Alan at OZ what about you? I am going to check how much Digital > does it too. Sun, HP, IBM, etc....how about you folks? We should also hear > from Chrysler (Bob can you connect with friends maybe at GM and Ford and ask > them). Eric at Boeing. We have a lot of folks out here using DNS. I think > Perry Metzger also can get some real data. Folks we need real data on > this one not guesses. Or just tech weenine wishes for the world. We maintain all of our 85,000+ IP addresses in a database system. It takes DHCP (approximately 50% coverage of our PC devices, 90% by year end) and administrator input. It builds both forward and reverse translation tables and automatically reloads the DNS primaries. We are also actively working DHCP support into almost "ALL" of our future contracts and anticipate most of our major vendors will deliver DHCP support in the near future. >From the Boeing perspective we use "caching" and "caching only servers" extensively. This we do for several reasons: 1) If a critical LAN(s) becomes isolated due to a power failure or circuit loss, even for the time of network convergence(about three minutes), the UNIX based processes like NFS, NIS, X, etc begin die, even though the resource they need is still alive and well on the LAN, if LOCAL DNS support is not available. Somehow, most of the vendors implemented longer timeouts on "gethostbyname" than they did on most of the major UNIX processes. We also allow the local admins to hot-load the cache with critical systems. Yes, we are still on 4.8.3 and looking at how to work around the fixes preventing this in BIND 4.9.x 2) With 1500 LAN's and about 200 of these critical, placing full secondaries on them instead of "caching only servers"; aside from totally consuming a primary on every refresh; simply couldn't be managed. 3) With our large UNIX application servers, we find that they hit the local campus servers several thousand times an hour if they aren't running as a "caching server" rather than a "stub resolver". A broken printer name still hits the campus server 300 to 400 times per SECOND since we haven't yet got negative caching widely implemented. Christian Huitema wrote: > On the whole, however, the best analysis was put up by Steve Bellovin. Host > addresses should not be used for security, nor in fact identification. Period. > Which leaves us with only one blessed usage for "gethostbyaddress", i.e. > statistics. I believe that relying on portable PCs to provide on-line > statistics is shortsighted. > I have to disagree here, Christian. We have had UNIX in Boeing for over ten years and unfortunately that means we have a very deep legacy. Right or wrong we still have groups and applications that make extensive use the "r-commands". Some of our vendors saw fit to log into or attempt to log into "utmp" the name of the "telnet" or "ftp" client. If reverse translation is not available for these systems, it can take the user 90 seconds to login. Understand that I don't claim, it's right or wrong only that we are stuck with it. With this proposal, I'll be supporting BIND 4.8.3 servers till I retire in 2015 (Yuck!). I would be very nice if the IPv6 services had backward extensions so we could move to the new generation and allow the older implementations to die a slow death. Christian also wrote: > Defining a "what is your name" ICMP has some value. But we should not come to > a point where *only* the host can give this information. > Here I agree with him. Even with DHCP, the units don't change addresses unless they have been off the air for an extended period or are moved to a different subnet. There's been some discussion of the dial-in tracking and that does seem to remain a problem though I know of a number of "operators" that do maintain separate connection logs to ensure that they can track who used an IP when. I have several specific comments on the your discussions: First on the ICMP "Domain Name Request" for IPv6: 1) I have a philosophic problem with referencing DNS within an ICMP call if DNS implementation remains "optional" (as I think it must.) I don't think ICMP is an appropriate vehicle for checking the status of an "optional" network service. I have no problem with a "what is your name" ICMP which may ALLOW return of a fully qualified name in the optional fields. ( See #3 under DYN-UPD below.) 2) Regardless what you name it, the call must be designed accept the fact that not all IP devices are "intelligent" and allow an alternate response. It is very difficult to get a device with only a ten key pad to have a fully qualified domainname. We have a growing number of what are becoming referred to as "network appliances"; (time-servers, LAN printers, LAN FAX's, Security badge readers, etc) many, if not most, of these devices have no concept of "DNS". It would seem that an alternate reply of just the IP address or "unknown" would have to be acceptable from these devices unless IPv6 doesn't want to support this type of device. From a large users point-of-view, these devices are VERY important because you just plug them in an leave them for literally years without touching them. If you accept that these devices do not have DNS, then the current draft stating: "Every host and router MUST implement an ICMP Domain Name server function that receives Domain Name Requests and sends corresponding Domain Name Replies." will need some work. 3) Unless IPv6 denies multiple name mappings it MUST also figure out how the name returned to maps to the original request. In our case, the user or applications may have asked for the "hostname", the fully qualified DNS name, the "interface" name, LU-NETID MPTN mapping, or the "service" name being accessed through that address. We map and use them all currently via DNS. My personal workstation currently has seven names. Those servers using our MPTN DNS reverse addressing kludge may have thirty or more aliases, a mainframe would have hundreds or thousands(I said it was a kludge). The current draft states: "When more than one name is known, all such names SHOULD be listed." I understand that a system will know its own "hostname" through system services but at present there is no way for a system to "know" its interface names, service names, or fully qualified "LU-NETID" name all of which may be registered with DNS. We also do extensive cross-zone aliasing which would seem even more difficult to track. On the "DYN-UPD with NOTIFY" 1) Some realization must be given to allow existing legacy systems and applications to continue to use a "gethostbyname" (pseudo-)function. Discontinuing "in-addr.arpa" is a very great leap if the reverse translation function is not replaced. Our "in-addr.arpa" domains are fully populated and by the way as Perry Metzger pointed out, you can't reach a lot us due to firewalling nor will the new ICMP until some basic security issues are fixed. 2) As Robert Moskowitz pointed out, multi-adapter systems are a problem. We are currently working with four different vendors on "load balancing" issues. "ALL" of their current solutions, require customized use of DNS. If "DYN-UPD with NOTIFY" succeeds; I would anticipate a rush to use it for "load balancing". It fits the needs to well to go unnoticed. In this case, unless controls are imposed, you may actually have to deal with 1000's of updates per second. A hundred clusters or "service apps" running with balancing set at once per second (I wouldn't suggest that rate but it will be done) would create that easily. 3) Finally I would suggest and hope that IPv6 should not continue to allow stub resolvers to be supported in DNS. At a minimum, end systems that require DNS support should have a basic resolver capability to include a minimal "fresh" cache (oldest and least used out first). This would require minimal code but would greatly unload DNS. I also would suggest that the current functionality of the ICMP "Domain Name Request", if located within this minimal frame, and given a correct "multicast" or perhaps broadcast (needs more thought here) function, could provide a very robust, low-maintenance DNS fall-back unlike our current "hosts" fallback. This type of end-system resolver functioning would also be compatible with DCHP and might go a long ways to reliving our dependence on "local LAN resources" like our "cache servers" to provide DNS reliability. Given our great success in getting the system vendors to offer anything more intelligent than a "stub resolver" on end-systems so far, I would like to hear whether any of the system vendors have views on the current drafts. Take care | Terry L. Davis | Boeing Computer Services, Bellevue, WA | | 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. | | INTERNET EMAIL: tld5032@atc.boeing.com. | -------------- Tuesday March 07,1995 07:44 AM PST ------------- == As always, should the above be construed as representing BOEING, == == the COMPANY will dis-avow any knowledge of me or my actions. == ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 09:01:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17065; Tue, 7 Mar 95 09:01:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17059; Tue, 7 Mar 95 09:00:52 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03005; Tue, 7 Mar 1995 08:53:29 -0800 Received: from mutton.csv.warwick.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA08940; Tue, 7 Mar 95 08:53:26 PST Date: Tue, 7 Mar 1995 16:53:20 GMT From: Ian Dickinson Message-Id: <19786.199503071653@mutton.csv.warwick.ac.uk> Received: by mutton.csv.warwick.ac.uk id QAA19786; Tue, 7 Mar 1995 16:53:20 GMT In-Reply-To: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" "(IPng) DNS-DynUpd, ICMP Domain Name Messages, and IPv6 DNS Comments." (Mar 7, 8:10am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.Eng.Sun.COM, namedroppers@internic.net Subject: Re: (IPng) DNS-DynUpd, ICMP Domain Name Messages, and IPv6 DNS Comments. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM We are an altogether smaller entity than Boeing, but the list of concerns addressed by Terry here match ours very closely. We have a well populated in-addr tree, and it works well. Some work will be required to match DHCP and DNS Dynamic Update to this model (perhaps by mandating DHCP use within the org, rather than letting stateless addrconf and ICMP domain name break things) but it should be doable. I can't see how ICMP domain name can be any sort of improvement for us - it may be for others, but I haven't heard a good discussion of why yet that convinced me. Cheers, -- Ian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 10:27:01 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17154; Tue, 7 Mar 95 10:27:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17148; Tue, 7 Mar 95 10:26:53 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14626; Tue, 7 Mar 1995 10:19:31 -0800 Received: from zephyr.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA29737; Tue, 7 Mar 95 10:19:31 PST Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Tue, 7 Mar 1995 10:19:12 -0800 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199503071819.AA16646@zephyr.isi.edu> Subject: Re: (IPng) National Registry of Routing is Harmful To: ipng@sunroof.Eng.Sun.COM Date: Tue, 7 Mar 1995 10:19:12 -0800 (PST) Cc: yakov@watson.ibm.com, brian@dxcoms.cern.ch, deering@parc.xerox.com In-Reply-To: <95Mar2.120802pst.12174@skylark.parc.xerox.com> from "Steve Deering" at Mar 2, 95 12:07:55 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > > ...since there should be only one FIX per city, this creates a bonafide > > monopoly that is introduced by the FIX. > > This does not contradict your point, but note that you can (and probably > should, for robustness sake) have multiple, redundant FIXes within a city > (or, rather "MIXes", for "metropolitan internet exchanges"). > > This is very interesting. To create such an environment will require a very high degree of 'net aware end-nodes and a varity of AUP's. A case in point is the SF Bay Area. The CIX, its adjucnt SMDS cloud, the ATM NAP, its FDDI brother, the MAE-WEST FDDI (at AMES and MFS) and the FIX. It is useful to note that the FDDI NAP and the MAE-WEST sites may join into a single, level 2 media. This would seem to be based on the AUP issues and the desire to gain critical mass. -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 10:29:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17169; Tue, 7 Mar 95 10:29:33 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17163; Tue, 7 Mar 95 10:29:26 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id KAA02419; Tue, 7 Mar 1995 10:21:59 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id KAA01274; Tue, 7 Mar 1995 10:21:50 -0800 Date: Tue, 7 Mar 1995 10:21:50 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503071821.KAA01274@elrond.Eng.Sun.COM> To: ipng@sunroof, ipsec@ans.net Subject: (IPng) Proposed message on perfect forward security X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM These mailing lists have witnessed a significant amount of commentary on the usefulness of certain key management protocols. One argument that has arisen several times is that some proposed protocols do not provide "perfect forward security." This property is the inabilitiy of an intruder who has recorded past traffic between a sender and receiver to decrypt that traffic if and when the long-term keying material of one or both correspondents is compromised. While perfect forward security is a useful property and even may be required for some applications, it is not always necessary and can introduce certain inefficiencies that adversely affect application performance. For example, perfect forward security may be necessary in an application that deals with information of long-time value, such as certain intelligence traffic, privileged client/attorney communications, and even commuications that may provide embarassment well after they have taken place (e.g., the now widely publicized telephone conversation between the Prince of Wales and his girlfriend). On the other hand, many other applications have no strong requirement for perfect forward security. Examples of these fall generally into that class of communications that are in some sense "tactical." For example, communications between a commander an his forward units probably have no need for perfect forward security. The directions he gives will become apparent to the enemy well before they can use any captured keys they might obtain to decrypt these. Other examples are communications to meet someone at a public place, blind auction bids in which all bids are later revealed in order to assure the participants of fairness, and large stock exchange purchases/sales by corporate officers of their own company's stock, for which the law requires public disclosure. Consequently, to require all key management protocols to provide perfect forward security simply because it is a useful property in some circumstances is unreasonable. The argument supporting this view is similar one that might be made about wearing SCUBA gear. If you intend to dive deeply in the ocean outside of a vessel, then wearing SCUBA gear is a necessity. Since it is such a strong requirement in this situation, we should always wear SCUBA gear, i.e., when we go shopping, are driving our cars or are playing tennis. ;-) For this reason I believe arguing against a key management protocol because it fails to provide perfect forward security would only be appropriate if that were the only protocol being proposed. In the case of IPv6, this is not true and so, I believe the argument is specious. Given the limited amount of experience we have in internet-wide deployed key management protocols, I don't believe this is the time to preclude key management options, especially based on questionable arguments. It is precisely for this reason that we should not exclude various key management protocols so that we may gain experience in this imperfectly understood area. In regards to in-band keying, two companies, Sun and DEC have devised key management protocols that use it, which provides a prima facie case for allowing its optional use in IPv4 and IPv6. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 11:20:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17249; Tue, 7 Mar 95 11:20:47 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17243; Tue, 7 Mar 95 11:20:39 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id LAA06727; Tue, 7 Mar 1995 11:11:06 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id LAA01373; Tue, 7 Mar 1995 11:10:50 -0800 Date: Tue, 7 Mar 1995 11:10:50 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503071910.LAA01373@elrond.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM, perry@imsi.com Subject: Re: (IPng) Proposed message on perfect forward security X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From perry@imsi.com Tue Mar 7 11:02:52 1995 > To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net > Subject: Re: (IPng) Proposed message on perfect forward security > X-Reposting-Policy: redistribute only with permission > > > Dan Nessett says: > [Stuff that I'm going to ignore on IPng and am going to reply to on ipsec] > > Dan: > > This stuff really belongs on ipsec and only on ipsec. It does NOT > belong on IPng. I understand that you are a SKIP partisan and like to > take every possible opportunity to promote SKIP, but crossposting > thinly veiled messages to IPng which has nothing to do with these > discussions is increasingly alienating me and others who are mildly > sympathetic. I would suggest that you restrict your commentary to the > ipsec list -- it doesn't do your friends any good to alienate people > this way. > > Perry > Perry, Could you clarify why you believe this discussion does not also belong on the IPng list? There is an on-going discussion there about the security I-Ds that Ran has written, which do not permit the use of in-band signalling. One of the arguments against in-band signalling is it may not provide perfect forward security. I think the IPng people interested in IPng security need to be apprised of this issue and consequently, I believe it does belong on the IPng list. By the way, when I asked if others were bothered about these discussions appearing on both lists, the only responses I received were from those who said they felt carrying them on both lists was appropriate. Once again, if anyone other than Perry and Bill feel this is an inappropriate topic for this list, please speak up. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 12:06:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17460; Tue, 7 Mar 95 12:06:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17454; Tue, 7 Mar 95 12:06:21 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27437; Tue, 7 Mar 1995 11:58:57 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA20224; Tue, 7 Mar 95 11:58:54 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17308; Wed, 8 Mar 1995 05:58:37 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Cc: sale@sware.com Subject: Re: (IPng) Gratuitous ARP In-Reply-To: Your message of "Tue, 07 Mar 1995 11:11:49 CDT." <9503071611.AA09856@wanda.sware.com.sware.com> Date: Wed, 08 Mar 1995 06:58:18 +1100 Message-Id: <6657.794606298@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Tue, 7 Mar 1995 11:11:49 -0500 From: Ed Sale Message-ID: <9503071611.AA09856@wanda.sware.com.sware.com> I agree with everything you say, except... Besides, it's not much bother, the packet doesn't even have to be multicast if we're talking about the auto-configured link-local address. Since the link-local IP address is just the IEEE 802 address plus a known prefix, the request could be unicast to the local IEEE 802 address. Its not just the link-local address that matters, its every address, and for the others we really don't want to assume that the 802.2 address is built in there somehow necessarily. Eg: if an address comes from a DHCP server, that server could be configured badly, or the response might come from a server that wasn't meant to be running and contained old data, or ... A duplicate address in any of those circumstances is just as bad as any other. We only need worry much about duplicates on the local link, as duplicates elsewhere will be isolated by the routing system, which should only forward packets to one of the local links, but we do need to worry about possible duplicate global addresses on a local wire. Once we build a general mechanism to handle that case, which we should certainly do, we may as well use it for link-local addresses as well, there's no point treating them differently, that just complicates the code. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 12:33:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17550; Tue, 7 Mar 95 12:33:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17544; Tue, 7 Mar 95 12:33:39 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01601; Tue, 7 Mar 1995 12:26:15 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA28078; Tue, 7 Mar 95 12:26:10 PST Received: from relay.imsi.com by wintermute.imsi.com id OAA18016; Tue, 7 Mar 1995 14:27:14 -0500 Received: from snark.imsi.com by relay.imsi.com id OAA07900; Tue, 7 Mar 1995 14:27:13 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA21523; Tue, 7 Mar 95 14:25:31 EST Message-Id: <9503071925.AA21523@snark.imsi.com> To: Danny.Nessett@Eng (Dan Nessett) Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Proposed message on perfect forward security In-Reply-To: Your message of "Tue, 07 Mar 1995 11:10:50 PST." <199503071910.LAA01373@elrond.Eng.Sun.COM> X-Reposting-Policy: redistribute only with permission Date: Tue, 07 Mar 1995 14:25:30 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan Nessett says: > Perry, > > Could you clarify why you believe this discussion does not also belong on > the IPng list? Because key management is an ipsec working group issue. There was a very, very slight reason to discuss the issue of using IPSP packets to convey key management information on the IPng list since IPng will have its own IPSP like protocol, the AH and ESP headers. There is nothing about the IPng effort, however, that involves key management per se. There is no IPng working group on this -- only a security area working group. Admittedly, some people on IPng might be interested -- but then again, some people on IPng might be interested in SMTP issues and you don't discuss that here, either. Yes, IPng will carry key management -- but its also going to carry SMTP. > By the way, when I asked if others were bothered about these discussions > appearing on both lists, the only responses I received were from those who > said they felt carrying them on both lists was appropriate. You obviously didn't see Bill Simpson's postings, then. > Once again, if anyone other than Perry and Bill feel this is an inappropriate > topic for this list, please speak up. Dan, if you want to alienate me, go right ahead. The behavior of the SKIP partisans has, in less than two weeks, turned me from mildly inclined towards SKIP to rapidly becoming less and less interested in having anything to do with SKIP. Bogus claims and bad behavior don't make me happy. Just keep behaving badly and I'm sure you will achieve everything that your opponents desire. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 12:37:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17568; Tue, 7 Mar 95 12:37:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17562; Tue, 7 Mar 95 12:37:27 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02156; Tue, 7 Mar 1995 12:30:04 -0800 Received: from by Sun.COM (sun-barr.Sun.COM) id AB28078; Tue, 7 Mar 95 12:26:20 PST Received: from relay.imsi.com by wintermute.imsi.com id NAA17840; Tue, 7 Mar 1995 13:44:19 -0500 Received: from snark.imsi.com by relay.imsi.com id NAA07532; Tue, 7 Mar 1995 13:44:19 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA21456; Tue, 7 Mar 95 13:42:36 EST Message-Id: <9503071842.AA21456@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Proposed message on perfect forward security In-Reply-To: Your message of "Tue, 07 Mar 1995 10:21:50 PST." <199503071821.KAA01274@elrond.Eng.Sun.COM> X-Reposting-Policy: redistribute only with permission Date: Tue, 07 Mar 1995 13:42:36 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan Nessett says: [Stuff that I'm going to ignore on IPng and am going to reply to on ipsec] Dan: This stuff really belongs on ipsec and only on ipsec. It does NOT belong on IPng. I understand that you are a SKIP partisan and like to take every possible opportunity to promote SKIP, but crossposting thinly veiled messages to IPng which has nothing to do with these discussions is increasingly alienating me and others who are mildly sympathetic. I would suggest that you restrict your commentary to the ipsec list -- it doesn't do your friends any good to alienate people this way. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 14:52:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17795; Tue, 7 Mar 95 14:52:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17789; Tue, 7 Mar 95 14:52:46 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18847; Tue, 7 Mar 1995 14:45:24 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA03825; Tue, 7 Mar 95 14:45:17 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA19101; Tue, 7 Mar 95 17:45:05 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503072245.AA19101@wizard.gsfc.nasa.gov> Subject: Re: (IPng) Base IPv6 Specification: Robust Service vs Lack of Header Checksum To: Christian.Huitema@sophia.inria.fr (Christian Huitema) Date: Tue, 7 Mar 1995 17:45:05 -0500 (EST) Cc: ipng@sunroof.Eng.Sun.COM, bill@wizard.gsfc.nasa.gov In-Reply-To: <199503071055.LAA19421@mitsou.inria.fr> from "Christian Huitema" at Mar 7, 95 11:55:44 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Bill, > > Your arguments regarding header checksum were presented and debated at length > during the two years of debate which preceded the IPng decision. They were > overruled then. You are not presenting any new facts. > > Christian Huitema Christian, I remember that some of this was discussed quite a while ago in the SIP Working Group, and I will also admit that there was general consensus within the SIP working group that the IP header checksum was not needed. I personally was not completely convinced by the arguments. I do not believe it has been seriously discussed since then (about 2 or 3 years ago). However, SIP, which merged with IPAE which merged with PIP to become SIPP which became SIPP (128 bit version), has now been selected to be IPv6. It thus now has to achieve consensus within this larger context, not just within the original SIP group. To achieve this consensus, it is necessary for the new people within the larger context of IPng to understand the rationale for decisions made by the original SIP group. In the case of the removal of the IP header checksum, there is no such rationale presented in either the IPng Overview document or the IPv6 Specification document. The only rationale permanently documented anywhere is in the IPng Technical Criteria document and that does not address the issues I raised. Since this issue was presented and debated at length in the SIP working group, it should not be difficult for any of the proponents of removing the IP header checksum to write up a few paragraphs explaining why the issues I raised are not something to be concerned about. This explanation should then be included in either the IPng Overview or the IPv6 Specification. Something this potentially important should be recorded for posterity. Those people who were not part of the original SIP working group should not have to take it on faith that this is a closed issue, and should be able to see both sides of the argument. Are you saying that the proponents of removing the IP header checksum need not document their rationale for such an important decision? -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 17:17:49 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18015; Tue, 7 Mar 95 17:17:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18009; Tue, 7 Mar 95 17:17:41 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07566; Tue, 7 Mar 1995 17:10:18 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA05217; Tue, 7 Mar 95 17:10:17 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm036-10.dialip.mich.net [141.211.7.52]) by merit.edu (8.6.10/merit-2.0) with SMTP id UAA13066 for ; Tue, 7 Mar 1995 20:10:11 -0500 Date: Tue, 7 Mar 95 23:18:15 GMT From: "William Allen Simpson" Message-Id: <4165.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) perpetual debate Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: bill@wizard.gsfc.nasa.gov (Bill Fink) > I remember that some of this was discussed quite a while ago in the > SIP Working Group, and I will also admit that there was general consensus > within the SIP working group that the IP header checksum was not needed. > I personally was not completely convinced by the arguments. I do not > believe it has been seriously discussed since then (about 2 or 3 years > ago). > ... > It thus now has to achieve consensus within this larger context, > not just within the original SIP group. > Really? Every feature or lack of a feature has to be re-debated, every time a new set of people come along? Personally, I've tired of the perpetual re-hashing of every design decision. If people want a tutorial, they should go _pay_ for a tutorial. > To achieve this consensus, it is necessary for the new people within > the larger context of IPng to understand the rationale for decisions > made by the original SIP group. In the case of the removal of the > IP header checksum, there is no such rationale presented in either > the IPng Overview document or the IPv6 Specification document. That's because it wasn't removed, it is simply not there. It is a non-feature. > Since this issue was presented and debated at length in the SIP working > group, it should not be difficult for any of the proponents of removing > the IP header checksum to write up a few paragraphs explaining why the > issues I raised are not something to be concerned about. If you remember it, why don't you just look at your archives? And when can we expect to see your implementation? Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 17:33:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18037; Tue, 7 Mar 95 17:33:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18031; Tue, 7 Mar 95 17:33:38 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09380; Tue, 7 Mar 1995 17:26:15 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA07731; Tue, 7 Mar 95 17:26:15 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA19396; Tue, 7 Mar 95 20:26:12 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503080126.AA19396@wizard.gsfc.nasa.gov> Subject: Re: (IPng) WG last call: v6 ICMP draft To: ipng@sunroof.Eng.Sun.COM Date: Tue, 7 Mar 1995 20:26:12 -0500 (EST) Cc: deering@parc.xerox.com, bill@wizard.gsfc.nasa.gov In-Reply-To: <95Feb28.210914pst.12174@skylark.parc.xerox.com> from "Steve Deering" at Feb 28, 95 09:09:02 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM First, please pardon me if some of this has already been covered by others, as I haven't read all my backlogged e-mail, but I wanted to make sure and get my comments and concerns registered before tomorrow. I have the following technical and editorial comments on the IPv6 ICMP specification. I cannot support moving this document to Proposed Standard until some of the technical concerns discussed below have been addressed. -Bill Technical: 1. I agree with other comments that the value for the next header field that identifies an IPv6 ICMP payload should be specified rather than being listed as TBD, prior to making this a Proposed Standard. 2. On Page 5, in the section on selection of a source address to use for generating an ICMP message, I do not agree with the choice specified for the otherwise section. Rather than choosing an address on the transmit interface that the ICMP message will be sent via, this needs to depend on the type of ICMP packet: A. For time exceeded, hop limit exceeded, the source address of the ICMP packet should definitely be a unicast address belonging to the interface on which the packet was received. This is required so traceroute will report meaningful information even in the presence of asymmetric routing. We want to know the actual path a data packet is traversing through a set of routers, and not the return paths from those intermediary routers. If it is necessary to know the return path from a particular router, we can use traceroute with a source route option. Time exceeded, fragment reassembly time exceeded, should not be applicable to a transit router. B. For destination unreachable, no route, the source address of the ICMP packet should probably be the router ID (defined in Router Requirements). Another alternative would be to choose a unicast address belonging to the interface on which the packet was received. C. For destination unreachable, communication administratively prohibited, the source address of the ICMP packet should be a unicast address belonging to the interface on which the packet would have been transmitted had the communication not been administratively prohibited. If this is considered a security concern, then the router ID could be used instead, or simply not send an ICMP packet at all. D. For destination unreachable, address unreachable, the source address of the ICMP packet should be a unicast address belonging to the interface on which the packet could not be transmitted due to a data link problem. Destination unreachable, port unreachable, should not be applicable to a transit router. E. For packet too big, the source address of the ICMP packet should be a unicast address belonging to the interface on which the packet could not be transmitted because the data link MTU was too small. F. For parameter problem, the source address of the ICMP packet should probably be the router ID. Another alternative would be to choose a unicast address belonging to the interface on which the packet was received. 3. In the same section on selection of a source address for an ICMP packet, regarding responding to a message sent to a multicast group in which the node is a member, I would also add some words to cover the case of a cluster address, i.e.: If the message is a response to a message sent to a multicast group or cluster address for which the node is a member, the Source Address of the reply must be a unicast address belonging to the interface on which the multicast or cluster addressed packet was received. 4. Still in the same section, I would add a paragraph stating that if the interface chosen for picking the unicast source address of the ICMP packet is an unnumbered interface, then the router ID should be used for the source address instead. 5. On Page 6, regarding timer-based rate limiting of ICMP packets, I have no problem with limiting this for a given source, but allowing this to be limited to at most one per second for any source might put a significant crimp in network troubleshooting in certain situations. Editorial: 1. I think the ICMP type values for neighbor discovery should be included in the table on Page 4, with a reference to the IPv6 Neighbor Discovery document. 2. There's a typo in Section 2 on Page 6. In paragraph (e), there's a "the the". 3. In the Description section of Section 3.1 on page 7, the part that says "by the IPv6 layer in the originating node" should say "receiving node". 4. In Section 4.1 on Page 12, for the Destination Address field, I agree with another comment that this should say "Any legal IPv6 address including a multicast or cluster address" rather than just say "Any legal IPv6 address". 5. In Section 4.2 on Pages 13 and 14, I would move the paragraph: The source address of an Echo Reply sent in response to a unicast Echo Request message MUST be the same as the destination address of that Echo Request message. to the IPv6 Fields part, after a new field labeled Source Address, right before the Destination Address field. 6. On page 14, in the Upper layer notification section, I agree with the comment about not understanding the reference "unless the corresponding Echo Request originated in the IP layer". It is not clear to me how this could occur. 7. In section 4.3 on Page 16, under the Multicast Address field, there is a typo. It should read "The address of the multicast group" instead of "The address if the multicast group". Comment/Question: 1. Are RFCs 1112, "Host Extensions for IP Multicasting", and RFC 1191, "Path MTU Discovery", on the list for review by the IPng Working Group for the first set of base documents for the full IPv6 specification? If not, I think they should be. 2. Are there any cases where ICMP packets should not be sent in response to cluster addresses? If so, that should be documented. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 17:59:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18061; Tue, 7 Mar 95 17:59:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18055; Tue, 7 Mar 95 17:59:27 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11861; Tue, 7 Mar 1995 17:52:04 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA12237; Tue, 7 Mar 95 17:52:05 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA19436; Tue, 7 Mar 95 20:52:01 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503080152.AA19436@wizard.gsfc.nasa.gov> Subject: Re: (IPng) perpetual debate To: bsimpson@morningstar.com Date: Tue, 7 Mar 1995 20:52:00 -0500 (EST) Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <4165.bsimpson@morningstar.com> from "William Allen Simpson" at Mar 7, 95 11:18:15 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > From: bill@wizard.gsfc.nasa.gov (Bill Fink) > > I remember that some of this was discussed quite a while ago in the > > SIP Working Group, and I will also admit that there was general consensus > > within the SIP working group that the IP header checksum was not needed. > > I personally was not completely convinced by the arguments. I do not > > believe it has been seriously discussed since then (about 2 or 3 years > > ago). > > ... > > It thus now has to achieve consensus within this larger context, > > not just within the original SIP group. > > > Really? Every feature or lack of a feature has to be re-debated, every > time a new set of people come along? Personally, I've tired of the > perpetual re-hashing of every design decision. If people want a > tutorial, they should go _pay_ for a tutorial. Bill, Certainly not every feature or lack of a feature has to be re-debated, but one of this importance should be documented for posterity, and not just in a mailing list archive. And yes new people do need to be educated, and there needs to be a basis for that education, and the best place for that in this particular case would be the IPng Overview document. > > To achieve this consensus, it is necessary for the new people within > > the larger context of IPng to understand the rationale for decisions > > made by the original SIP group. In the case of the removal of the > > IP header checksum, there is no such rationale presented in either > > the IPng Overview document or the IPv6 Specification document. > > That's because it wasn't removed, it is simply not there. It is a > non-feature. It was in IPv4, presumably for a reason. It's not in IPv6. That sounds like being removed to me. Non-features can have just as major an impact as features, and in some cases even more so. > > Since this issue was presented and debated at length in the SIP working > > group, it should not be difficult for any of the proponents of removing > > the IP header checksum to write up a few paragraphs explaining why the > > issues I raised are not something to be concerned about. > > If you remember it, why don't you just look at your archives? It should not be necessary for every other person who wants to understand this issue to have to find, dig through, and extract the information from 2 or 3 year old e-mail archives. > And when can we expect to see your implementation? I suppose you are inferring that only implementors can have any possible insight into the protocol operation of IP, and that users or network managers couldn't possibly have any useful inputs. I don't happen to believe that. I believe that implementors have particular insights from their perspective and that users and network managers have other insights from their perspective. I'm very interested in beta testing IPv6 code once the implementors say that it's ready to be released. > Bill.Simpson@um.cc.umich.edu -Bill P.S. I hate having to do documentation too. It can be a real drag and does take away from more interesting activities. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 18:01:18 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18074; Tue, 7 Mar 95 18:01:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18068; Tue, 7 Mar 95 18:01:10 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12046; Tue, 7 Mar 1995 17:53:47 -0800 Received: from church.cse.ogi.edu (cse.ogi.edu) by Sun.COM (sun-barr.Sun.COM) id AA12698; Tue, 7 Mar 95 17:53:46 PST Received: from admin.ogi.edu by church.cse.ogi.edu with smtp (Smail3.1.29.1 #2) id m0rmAwb-000KlSC; Tue, 7 Mar 95 17:53 PST Received: by admin.ogi.edu (4.1/SMI-4.1) id AA22515; Tue, 7 Mar 95 17:53:44 PST Date: Tue, 7 Mar 1995 17:53:44 -0800 (PST) From: Dan Revel Subject: Re: (IPng) perpetual debate To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <4165.bsimpson@morningstar.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM How about a pointer to the SIP archives then? Dan Revel On Tue, 7 Mar 1995, William Allen Simpson wrote: > > From: bill@wizard.gsfc.nasa.gov (Bill Fink) > > I remember that some of this was discussed quite a while ago in the > > SIP Working Group, and I will also admit that there was general consensus > > ... > Really? Every feature or lack of a feature has to be re-debated, every > time a new set of people come along? Personally, I've tired of the > perpetual re-hashing of every design decision. If people want a > tutorial, they should go _pay_ for a tutorial. > ... > > ... > If you remember it, why don't you just look at your archives? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 18:30:46 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18100; Tue, 7 Mar 95 18:30:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18094; Tue, 7 Mar 95 18:30:39 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14041; Tue, 7 Mar 1995 18:23:16 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA17051; Tue, 7 Mar 95 18:23:17 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA19514; Tue, 7 Mar 95 21:23:16 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503080223.AA19514@wizard.gsfc.nasa.gov> Subject: Re: (IPng) WG last call: v6 ICMP draft To: ipng@sunroof.Eng.Sun.COM Date: Tue, 7 Mar 1995 21:23:15 -0500 (EST) Cc: deering@parc.xerox.com, bill@wizard.gsfc.nasa.gov X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM One more question: 3. Do we need to specify the path that an ICMP error or reply packet will take in the presence of a routing header? I am inclined to say that it must reverse the portion of the source route that has been used up to that point. -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 19:06:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18188; Tue, 7 Mar 95 19:06:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18182; Tue, 7 Mar 95 19:06:18 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16031; Tue, 7 Mar 1995 18:58:55 -0800 Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA20675; Tue, 7 Mar 95 18:58:56 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id WAA18478 for ipng@sunroof.Eng.Sun.COM; Tue, 7 Mar 1995 22:01:49 -0500 (EST) Date: Tue, 7 Mar 1995 22:01:49 -0500 (EST) From: Scott Bradner Message-Id: <199503080301.WAA18478@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) WG last call: v6 ICMP draft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, --- One more question: 3. Do we need to specify the path that an ICMP error or reply packet will take in the presence of a routing header? I am inclined to say that it must reverse the portion of the source route that has been used up to that point. --- there has been some level of discussion on this topic, at this time the ball is the sdrp's court. the general idea is that one way to deal with this is to add a bit to the routing header to give the intermediate router a hit that the most reliable way to get back to the source is via reversing the source route. There are people who feel that mandating source route reversal is a Bad Thing since the router at the error point might actually be able to get back via flat routing or that the paths are not the same in each direction and a reversed source route would fail. In any case the topic needs to be worked through with the source route people and included in the source route writeup. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 7 23:05:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18266; Tue, 7 Mar 95 23:05:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18260; Tue, 7 Mar 95 23:04:58 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24591; Tue, 7 Mar 1995 22:57:33 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA11578; Tue, 7 Mar 95 22:57:35 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA19901; Wed, 8 Mar 95 01:57:19 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503080657.AA19901@wizard.gsfc.nasa.gov> Subject: Re: (IPng) IPng Working Group Last Calls To: ipng@sunroof.Eng.Sun.COM Date: Wed, 8 Mar 1995 01:57:18 -0500 (EST) Cc: bill@wizard.gsfc.nasa.gov X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > An Architecture for IPv6 Unicast Address Allocation > draft-ietf-ipngwg-arch-addr-01.txt > > An IPv6 Global Unicast Address Format > draft-ietf-ipngwg-address-format-01.txt I support moving these two documents to Proposed Standard as one possible Architecture for IPv6 Unicast Address Allocation and one possible IPv6 Global Unicast Address Format, although I happen to personally favor geographic based addressing. -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 02:11:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18314; Wed, 8 Mar 95 02:11:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18308; Wed, 8 Mar 95 02:11:40 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01411; Wed, 8 Mar 1995 02:04:18 -0800 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA29905; Wed, 8 Mar 95 02:04:08 PST Received: by mitsou.inria.fr (8.6.10/8.6.10) id LAA22744; Wed, 8 Mar 1995 11:04:01 +0100 Message-Id: <199503081004.LAA22744@mitsou.inria.fr> To: bill@wizard.gsfc.nasa.gov (Bill Fink) Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Base IPv6 Specification: Robust Service vs Lack of Header Checksum In-Reply-To: Your message of "Tue, 07 Mar 1995 17:45:05 EST." <9503072245.AA19101@wizard.gsfc.nasa.gov> Date: Wed, 08 Mar 1995 11:03:58 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, The basic rationales for removing the checksums were the followings: 1) Hop by hop errors are usually detected with media-level checksums. 2) End to end checksums, such as TCP's or UDP's, are designed to catch the residual errors. These errors are generally caused by the misbehaviour of relays, e.g. memory faults or software faults. 3) Header checksums are ill suited to catch the misbehaviour of relays, as header checksums tend to be recomputed by each relay. 4) Checking and recomputing the checksum for each packet imply a large performance penalty. The cost/advantage analysis shows too much cost and too little benefit. A header checksum would not catch any of the problems you quoted if these are caused by a faulty relay that erroneously alters the header, and then recomputes the header. In fact, you will note that all the errors you quote can be turned into deliberate denial of service attacks. Protection against such attacks would be necessary for a very robust service; it requires much more than a header checksum. I note that you seem to advocate a "fixed checksum" approach, i.e. one that is computed by the source and only checked by the relays. The problem here is that source routing may cause the destination to change. In fact, one could argue that we already have this "fixed checksum" built in, as the flow-id. The flow-id is supposed to be taken at random, which result in the same entropy as a checksum. All packets send by the a given route on a given flow are suppose to floow the same route. An intermediate relay can thus cache the flow/source/dest tuple. When processing a packet, it can look at this cache, detect a mismatch, and an error. Now, what is the opinion of this list? Should a router destroy a packet if the flow id is not null, and already cached for a different destination? What ICMP code shall we use? Shall it keep the cache entry or remove it? How long shall a flow info be kept in a cache? Christian Huitema PS. I append a detailed analysis of your remarks. 1) Multicast group ID corruption: The address space for multicast groups is very sparse. That a random error transforms one valid group is unlikely - in fact, one can estimate that the probability of this occuring is less than having a random checksum being right. The "major traffic impact" only occurs if this error is repeated consistently. Such errors are more likely to be caused by a misbehaving source, sending to the wrong group, or by a misbehaving router, incorrectly rewriting the header. A header checksum would not help. 2. Multicast scope corruption Similar problem to previous one. In fact, this has to be analysed in conjonction with multicast routing algorithms. Sparse-mode PIM, for example, has implicit protection. 3. Unicast destination address corruption A random error causes the misdelivery of one packet. This is an acceptable risk, already taken into account by inclusion of a pseudo-error in TCP and UDP checksum. As systematic error would probably not be caught by the header checksum. 4. Source address corruption Same analysis as (3). 5. Flow ID corruption Again, you have to distinguish random errors, which affect isolated packets and have acceptable consequences, from systematic errors, which would probably not be caught by the header checksum. Note that the consequences of systematic errors would depend a lot of what you use the flows for. You are quoting a very extreme case. 6. Traffic class corruption This is very similar to Flow ID corruption. Same remarks apply. 7. Hop Limit corruption Random reduction causes a random packet loss, which is deemed acceptable. Random increases will be a problem if occuring in conjunction with a network loop. Systematic errors would indeed be a worse problem, but, again, the likely cause is a software fault, e.g. failing to recognize 0 and count down from 255. This will not be caught by a header checksum, as header checksum are systematically recomputed after updating the hop count. 8. Payload length and next header corruption As you note, this is mostly an end-to-end problem. Code have to be robust. 9. Routing header and hop-by-hop options header corruption A header checksum would not help in the case of the "routing header". The very design of IPv6 is "intermediate" routers will not even look at the routing header. You cannot expect them to compute a checksum over the routing header payload. You may want to consider a checksum of the routing header itself. There is however an implicit protection through the fixed relation between flow-id and routing header - same flow should imply same loose route. 10. Corruption to fragment header, authentication header, end-to-end options header This is an end-to-end problem, to be catched by end-to-end solutions. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 06:15:49 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18469; Wed, 8 Mar 95 06:15:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18463; Wed, 8 Mar 95 06:15:12 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12792; Wed, 8 Mar 1995 06:06:55 -0800 Received: from LABS-N.BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA23122; Wed, 8 Mar 95 06:06:49 PST Message-Id: <9503081406.AA23122@Sun.COM> To: ipng@sunroof.Eng.Sun.COM Cc: ipsec@ans.net, solo@BBN.COM Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of Mon, 27 Feb 95 09:17:38 -0500. <9501277939.AA793905458@spysouth.spyrus.com> Date: Wed, 08 Mar 95 09:00:54 -0500 From: solo@BBN.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I, too, believe that the solutions we offer should be capable of accomodating both in-band and out-of-band KM (or key distribution). As with other topics, it seems that there are three options (probably more, but so it goes) for doing this: negotiation that includes IPSP format; structured SAIDs that connote IPSP format and semantics; and multiple protocol IDs. Essentially, the second option is a way to extend the protocol ID space without consuming additional IP next protocol numbers. I believe Russ's suggestion below has merit; but if we can't reach agreement on adding such structure to the SAID field, then I would suggest we consider adopting two protocol IDs, one for the fixed format structure Bill and Perry have espoused and one with comparable syntax but with the SAID based extensible option Russ describes. This argument seems to reduce to the efficiency of where "protocol" demultiplexing takes place. I believe it is critical that we leave Danvers with stable documented proposals (and agreement :-)). Dave > Date: Mon, 27 Feb 95 09:17:38 EST > From: "Housley, Russ" > Subject: (IPng) Re: out-of-band key management is like virtual circuits > > Hi Dan. > > In IEEE 802.10, when we were developing the Secure Data Exchange (SDE) > Protocol, this same "in-line" key issue surfaced. It was resolved in a > manner that has not been considered by the IETF. The solution has pros and > cons, but I think that it should be considered before a decision is made. > > SDE has a 32-bit SAID that is followed by an optional field, called the > Management Defined Field (MDF). DEC pushed very hard for this field > because they wanted the SAID to identifiy a Master Key that would be used > to decrypt the contents of the MDF. The MDF carried the key or keys to > decrypt and/or check the integrity of the payload. > > SKIP is the same idea. SKIP sderives the Master Key using D-H key > agreement instead of out-of-band master key distribution. > > This alternative would permit the approach advocated by DEC, and it would > accompdate the SKIP approach. > > Using a bit in the SAID to indicate the presence/absence of the MDF (or > whatever we call it for IPSP) would avoid the need for a key management > protocol to negotiate the attributes for the security association. Perhaps > a reserved SAID would indicate that the key management technique used by > SKIP should be used to generate the key to decrypt the MDF. > > I just do not see why we cannot architect an IP layer security protocol > that permits both types of key management. > > More food for thought.... > > Russ > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 06:50:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18485; Wed, 8 Mar 95 06:50:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18479; Wed, 8 Mar 95 06:49:32 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14491; Wed, 8 Mar 1995 06:41:14 -0800 Received: from CLYNN.BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA27445; Wed, 8 Mar 95 06:41:08 PST Message-Id: <9503081441.AA27445@Sun.COM> Date: Wed, 8 Mar 95 9:40:06 EST From: Charles Lynn To: ipng@sunroof.Eng.Sun.COM Cc: Scott Bradner , CLynn@BBN.COM Subject: Re: (IPng) WG last call: v6 ICMP draft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Scott, > In any case the topic needs to be worked through > with the source route people and included in the source route writeup. I think it is too easy, given the number of documents relating to IPv6, for implementor(s) to either overlook or not be aware of one, or assuming awareness to not see the implied interactions between the services offered by IPv6. How about having each IPv6 document contain a section listing all other IPv6 documents that place requirements on things in this document? When IPv6 becomes a STD #, all documents that place requirements on an implementation should be explicitly listed in one "entry". Charlie ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 07:10:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18502; Wed, 8 Mar 95 07:10:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18496; Wed, 8 Mar 95 07:09:18 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15605; Wed, 8 Mar 1995 07:01:00 -0800 Received: from emvax1.mainz.dk by Sun.COM (sun-barr.Sun.COM) id AA00222; Wed, 8 Mar 95 07:00:26 PST Received: from KW.mainz.dk by EMVAX1.MAINZ.DK (PMDF V4.3-10 #7874) id <01HNWDI06M8W000XV2@EMVAX1.MAINZ.DK>; Wed, 08 Mar 1995 15:59:40 +0100 (WET) Date: Wed, 08 Mar 1995 15:59:57 +0100 From: Kim.Wohlert@mainz.dk (Kim Wohlert) Subject: (IPng) Comments on -ipngwg-arch-addr-01.txt X-Sender: kw@emvax1.mainz.dk To: yakov@watson.ibm.com, tli@cisco.com Cc: ipng@sunroof.Eng.Sun.COM Message-Id: <01HNWDI0BPHU000XV2@EMVAX1.MAINZ.DK> Mime-Version: 1.0 X-Mailer: Windows Eudora Version 1.4.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Yakov and Tony I have read your proposed Architecture for IPv6 Unicast Address Allocation and I have some comments. My comments center around the assumption that it is possible and desirable to allocate IPv6 prefixes in a hierarchical manner. This assumption is in my opinion false and likely to diminish the deployment rate of IPv6. The proposition is to have a hierarchy as: Continent - Country - National registry - provider - subscriber There are two flaws in this scheme, 1) it forces a tie-in between provider and subscriber and 2) it assumes that traffic flows along the same lines. 1) assumes that I as a customer will connect to one provider and that that provider will satisfy my needs for all eternity. While this has been true for the Telco industry in many countries for many years, these barriers are tumbling down everywhere. Many new provides are coming in to the market, are driving the development. It would be foolish for the Internet to adopt a strategy that essentially has been done away with be other similar industries. I would not want to be tied into the same provider just because that provider some years ago was the best (or even the only) provider in my region. 2) Traffic does not flow along the same lines as your hierarchy suggests. At present there are two major providers in Denmark. If I send to my next door neighbor who happens to use that other provider, traffic flows from Copenhagen, over Amsterdam in the Netherlands and Oslo in Norway and back to the other provider in here in Copenhagen. Some days the traffic even crosses the Atlantic twice. A country or regional prefix would do nothing in terms of aggregating routes in this case. You might argue that the two providers should get their act together and start exchanging traffic directly, but I don't think that that is realistic. With the increasing liberalization among Telco's, at least in Europe, it is not a valid assumption that traffic within one country will always be less expensive than between countries. Thus it is highly likely that the way the two current providers in Denmark are doing business will be valid from an economic viewpoint in many countries around the world. The solution? I don't know. One might guess that technology (faster cheaper hardware) will solve the problem by allowing us to handle ever increasing router table sizes, but I assume that people wiser than me was looked into that. However it remains certain that the plan you have proposed will break down at certain points in the hierarchy and will have unpleasant effects on the free development of the Internet provider industry. Comments invited. -Kim =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Kim Wohlert |Internet:Kim.Wohlert@mainz.dk erik mainz a/s |X.400: c=DK a=DK400 p=Minerva Dortheavej 7 |o=mainz s=Wohlert g=Kim DK-2400 Copenhagen |Phone: +45 38 34 77 88 Denmark |Fax: +45 31 19 16 25 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- (This place reserved for future expansion) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 08:19:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18551; Wed, 8 Mar 95 08:19:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18545; Wed, 8 Mar 95 08:18:58 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21219; Wed, 8 Mar 1995 08:11:34 -0800 Received: from CLYNN.BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA13554; Wed, 8 Mar 95 08:11:34 PST Message-Id: <9503081611.AA13554@Sun.COM> Date: Wed, 8 Mar 95 11:02:42 EST From: Charles Lynn To: solo@BBN.COM Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual ... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, > Without such a designator, how do you expect to handle these > cases? Maybe what would be useful would be to allot part of the SAID space for "not assigned by the destination system" (but not implying any particular "structure"). I think this would make assignment easier. Whether or not such an allocation is made, an implementation should be able to solve the collision problem by making the key, instead of simply . Then multicast address(es) and locally assigned unicast address(es) could have the same 32-bit SAID without "collision". One might also want some wildcard address that would match any of the system's unicast addresses (but not any multicast address); a question for the security experts. Charlie ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 08:48:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18593; Wed, 8 Mar 95 08:48:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18587; Wed, 8 Mar 95 08:47:35 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23511; Wed, 8 Mar 1995 08:38:47 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA19209; Wed, 8 Mar 95 08:38:33 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14506(1)>; Wed, 8 Mar 1995 08:38:12 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12175>; Wed, 8 Mar 1995 08:37:59 -0800 To: Kim.Wohlert@mainz.dk (Kim Wohlert) Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) Comments on -ipngwg-arch-addr-01.txt In-Reply-To: Kim.Wohlert's message of Wed, 08 Mar 95 06:59:57 -0800. <01HNWDI0BPHU000XV2@EMVAX1.MAINZ.DK> Date: Wed, 8 Mar 1995 08:37:53 PST From: Steve Deering Message-Id: <95Mar8.083759pst.12175@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Yakov and Tony > > I have read your proposed Architecture for IPv6 Unicast Address Allocation > and I have some comments. Kim, I am not Yakov or Tony, but let me give you my comments on your comments; Yakov or Tony may well offer different opinions. Your concerns about provider-oriented addressing are well known and understood by the IPng working group and the Internet community at large, and are a matter of great concern to many of us. Alternatives to provider-oriented addressing are being studied and have been proposed, but are not yet ready to be submitted to the standards track, in my opinion. One possibility is flat routing among all sites, but that would require significantly more routing resources than are currently available, or a fundamental change in the way routing is done (e.g., keeping only cached routes in the routers, and full tables in separate databases). Another possibility is to impose (perhaps by consumer demand or "provider requirements" pressure) topological constraints on the Internet that allow a site to have a provider-independent address prefix that is still amenable to hierarchical aggregation, e.g., requiring that your two Danish service providers interconnect somewhere in Denmark so that (a) you can have addresses that say "Denmark" rather than "Provider X", and (b) you get the low latency packet delivery that you ought to get between two nearby sites, rather than having your packets routed half way around the world and back. Or maybe someone will come up with a better idea. However, the fact is that we do not *currently* have the resources or new technology to do very large-scale flat routing, and we do not *currently* have an interconnection topology that allows large-scale, provider-independent route aggregation (except in a small number of locations, like Washington DC). The current CIDR-based address allocation for IPv4 is following the same guidelines as in Yakov and Tony's IPv6 addressing drafts, so we are gaining experience with that style of addressing, learning both the problems and possible work-arounds. It may be possible to live within the limitations of provider-oriented addressing if we make the hosts smart enough to support multiple address for themselves and rapid, automatic, transparent changing of those addresses; that is one direction that is being pursued in the IPng working groups. Note that multiple, disjoint addressing hierarchies may exist concurrently in the IPv6 address space. Even if we come up with a workable provider- independent addressing approach (as I hope), we will probably still want to have the routers support a provider-based hierarchy as well, for use in IPv6 Route Headers to allow traffic to be routed explicitly via particular providers. That is, we would have provider-based addresses that are not actually assigned to any customers, only to provider assets. Note also that alternative addressing hierarchies can be deployed incrementally, so that starting out with the currently proposed scheme does not imply the need for a future "flag day" to convert to a different scheme. In the geographical approach, for example, individual locales may arrange for provider interconnection and then gradual migration of customers to the locale-based addresses, independent of other customers or other locales. To summarize: the current proposal describes what we currently know how to do. People are working on alternative proposals. Even if we end up adopting one or more alternative approaches, we would probably retain the current approach as well. Migrating to other approaches is feasible. These are the reasons that I support the submission of Yakov and Tony's draft as a Proposed Standard at this time. This is most assuredly *not* intended to inhibit the development of alternative proposals and their subsequent submission as additional Proposed Standards. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 09:09:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18631; Wed, 8 Mar 95 09:09:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18625; Wed, 8 Mar 95 09:08:40 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25641; Wed, 8 Mar 1995 09:00:22 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA23762; Wed, 8 Mar 95 09:00:16 PST Received: from relay.imsi.com by wintermute.imsi.com id LAA21699; Wed, 8 Mar 1995 11:59:59 -0500 Received: from snark.imsi.com by relay.imsi.com id LAA18348; Wed, 8 Mar 1995 11:59:59 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA23007; Wed, 8 Mar 95 11:58:04 EST Message-Id: <9503081658.AA23007@snark.imsi.com> To: Charles Lynn Cc: solo@BBN.COM, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) out-of-band key management is like virtual ... In-Reply-To: Your message of "Wed, 08 Mar 1995 11:02:42 EST." <199503081611.AA45978@interlock.ans.net> X-Reposting-Policy: redistribute only with permission Date: Wed, 08 Mar 1995 11:58:03 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Charles; As has been repeatedly noted, this discussion belongs only on IPSEC. That is where I have answered you. The basic answer to your comments is "please read the drafts; we weren't imbeciles; we already dealt with all of this." Perry Charles Lynn says: > Folks, > > > Without such a designator, how do you expect to handle these > > cases? > > Maybe what would be useful would be to allot part of the SAID space > for "not assigned by the destination system" (but not implying any > particular "structure"). I think this would make assignment easier. > > Whether or not such an allocation is made, an implementation should be > able to solve the collision problem by making address> the key, instead of simply . Then multicast > address(es) and locally assigned unicast address(es) could have the > same 32-bit SAID without "collision". One might also want some > wildcard address that would match any of the system's unicast > addresses (but not any multicast address); a question for the security > experts. > > Charlie ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 10:08:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18726; Wed, 8 Mar 95 10:08:55 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18720; Wed, 8 Mar 95 10:08:47 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id KAA10569; Wed, 8 Mar 1995 10:01:15 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id KAA02270; Wed, 8 Mar 1995 10:01:01 -0800 Date: Wed, 8 Mar 1995 10:01:01 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503081801.KAA02270@elrond.Eng.Sun.COM> To: ipng@sunroof, ipsec@ans.net Subject: (IPng) user-to-user vs. host-to-host keying X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM One of the issues that is debated about keying requirments for IPv4 and IPv6 is how to thwart cryptoanalytic threats. The IPv6 security I-Ds specify that user-to-user keying must be supported to meet these (I couldn't find this called out in the IPSEC drafts of Metzger and Simpson, but I thought this issue is of sufficiently wide-spread interest that I am also posting this message to the IPSEC mailing list). I asked Burt Kaliski to comment on how much text is needed by the best techniques published in the open literature to cryptoanalyze DES. Here is his response. === From burt@RSA.COM Wed Mar 8 09:45:29 1995 To: Danny.Nessett@Eng Subject: Quantity of plaintext/ciphertext required for DES crypto Dan -- It is somewhat counterintuitive that the known plaintext attack requires less data than the chosen plaintext attack, and a little surprising, but not contradictory, since every known plaintext attack is a chosen plaintext attack as well. I think 2^32 is a better bound than 2^43, at least for certain modes of DES. For instance, after 2^32 blocks in CBC mode, you expect to see two identical ciphertext blocks, say c[i] and c[j]; the difference between their predecessors will match the difference between the corresponding plaintext blocks, i.e., p[i] xor p[j] = c[i-1] xor c[j-1] Information thus starts to leak after 2^32 blocks (square root of the message space). I would recommend 2^32 blocks as the limit for the lifetime of a key, and that takes care of the 2^43/2^47 attacks as well. Feel free to summarize or repost my comments. -- Burt ======= This suggests that another way to meet the cryptoanalytic threat to host-to-host keying is to change the session key well before 2^32 plaintexts have been encrypted. Consequently, I think that requiring IPv6 security implementations to support user-to-user keying is too limiting. They can adequately meet this threat by judicious session key management. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 11:10:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18897; Wed, 8 Mar 95 11:10:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18891; Wed, 8 Mar 95 11:09:55 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10481; Wed, 8 Mar 1995 11:02:29 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA22092; Wed, 8 Mar 95 11:02:16 PST From: Ran Atkinson Message-Id: <9503081400.ZM1436@bodhi.itd.nrl.navy.mil> Date: Wed, 8 Mar 1995 14:00:25 -0500 In-Reply-To: Danny.Nessett@Eng.Sun.COM (Dan Nessett) "user-to-user vs. host-to-host keying" (Mar 8, 10:01) References: <199503081801.AA28611@interlock.ans.net> X-Mailer: Z-Mail (3.0.0 15dec93) To: Dan Nessett , ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: (IPng) Re: user-to-user vs. host-to-host keying Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan, Your analysis was limited to DES. The specifications are algorithm-independent and NEED to support other algorithms such as RCx, IDEA, etc. The need for user-to-user keying remains clear. Handwaving about "judicious key management" is not a meaningful answer even for DES. Did you miss Jeff Schiller's comments on this at the Open IPng Directorate meeting in San Jose ? I can't do justice to his remarks but think they were well put. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 11:26:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18965; Wed, 8 Mar 95 11:26:22 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18959; Wed, 8 Mar 95 11:26:15 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id LAA14887; Wed, 8 Mar 1995 11:18:42 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id LAA02311; Wed, 8 Mar 1995 11:18:28 -0800 Date: Wed, 8 Mar 1995 11:18:28 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503081918.LAA02311@elrond.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net, atkinson@itd.nrl.navy.mil Subject: (IPng) Re: user-to-user vs. host-to-host keying X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From rja@bodhi.itd.nrl.navy.mil Wed Mar 8 11:02:39 1995 > To: Dan Nessett , ipng@sunroof.Eng.Sun.COM, ipsec@ans.net > Subject: Re: user-to-user vs. host-to-host keying > Mime-Version: 1.0 > > Dan, > > Your analysis was limited to DES. The specifications are > algorithm-independent and NEED to support other algorithms > such as RCx, IDEA, etc. The need for user-to-user keying > remains clear. Handwaving about "judicious key management" > is not a meaningful answer even for DES. > > Did you miss Jeff Schiller's comments on this at the Open IPng > Directorate meeting in San Jose ? I can't do justice to his > remarks but think they were well put. > > Ran > atkinson@itd.nrl.navy.mil > > Ran, Yes I did miss Jeff's remarks. However, I wouldn't characterize my suggestion of "judicious key management" as handwaving. According to your architecture I-D, DES-CBC is the default encryption algorithm for the global Internet, so I believe the analysis I presented is pertinent for the default case. If another algorithm is being used, then a similar analysis would apply in order to discover the maximum amount of plaintext that should be encrypted by one key. Note that this value should also be known when user-to-user keying is employed, for the same cryptoanalytic threat exists in that case as well. That is, the user-to-user session key should be changed when a significant amount of plaintext has been encrypted with it. I am not saying that user-to-user keying shouldn't be allowed to thwart the threat you mention. I am saying it isn't the only way to combat this threat and therefore IPv6 implmentations should not be required to support it. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 12:21:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19193; Wed, 8 Mar 95 12:21:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19177; Wed, 8 Mar 95 12:14:53 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17516; Wed, 8 Mar 1995 12:07:28 -0800 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU) by Sun.COM (sun-barr.Sun.COM) id AA05916; Wed, 8 Mar 95 12:07:30 PST Received: from [18.172.1.4] by MIT.EDU with SMTP id AA16639; Wed, 8 Mar 95 15:07:11 EST Received: by dcl.MIT.EDU (5.0/4.7) id AA00627; Wed, 8 Mar 1995 15:06:50 +0500 Date: Wed, 8 Mar 1995 15:06:50 +0500 From: Theodore Ts'o Message-Id: <9503082006.AA00627@dcl.MIT.EDU> To: solo@BBN.COM Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net, solo@BBN.COM In-Reply-To: solo@BBN.COM's message of Wed, 08 Mar 95 09:00:54 -0500, <199503081406.AA32074@interlock.ans.net> Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Cc: ipsec@ans.net, solo@BBN.COM Date: Wed, 08 Mar 95 09:00:54 -0500 I, too, believe that the solutions we offer should be capable of accomodating both in-band and out-of-band KM (or key distribution). As with other topics, it seems that there are three options (probably more, but so it goes) for doing this: negotiation that includes IPSP format; structured SAIDs that connote IPSP format and semantics; and multiple protocol IDs. Essentially, the second option is a way to extend the protocol ID space without consuming additional IP next protocol numbers. I believe Russ's suggestion below has merit; but if we can't reach agreement on adding such structure to the SAID field, then I would suggest we consider adopting two protocol IDs, one for the fixed format structure Bill and Perry have espoused and one with comparable syntax but with the SAID based extensible option Russ describes. This argument seems to reduce to the efficiency of where "protocol" demultiplexing takes place. There is a forth option --- which is to reserve a single SAID to mean "we're initiating a new connection, and we're going to do the in-band keying thing". The first part of the packet payload would then contain information describing the type of the in-band keying, and any in-band keying specific data. I believe this is far superior than cedeing a large chunk of the SAID space --- it's more flexible. In addition, the whole concept of a "structured SAID" is a real perversion of the original meaning of a Secure Association ID. A structured SAID isn't really an ID. It's stealing 50% of the SAID space, and using a bit to indicate that the rest of the SAID is an escape for a particular in-band keying system. But it's extremely wasteful of the SAID space, and insufficiently flexible. After all, we only get to define the structure of the "structure SAID" once; and if we get it wrong, then that's it; we're stuck. This is why I still maintain that a "structured SAID" is really all about stealing one half of the SAID space for SKIP. There's no guarantee that no matter what scheme you use, that it will be good enough for the next in-band keying system. - Ted ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 12:37:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19230; Wed, 8 Mar 95 12:37:45 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19224; Wed, 8 Mar 95 12:37:35 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id MAA17907; Wed, 8 Mar 1995 12:29:52 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id MAA02342; Wed, 8 Mar 1995 12:29:42 -0800 Date: Wed, 8 Mar 1995 12:29:42 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503082029.MAA02342@elrond.Eng.Sun.COM> To: tytso@MIT.EDU Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net, solo@BBN.COM X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ted, I agree with you that : > There is a forth option --- which is to reserve a single SAID to mean > "we're initiating a new connection, and we're going to do the in-band > keying thing". The first part of the packet payload would then contain > information describing the type of the in-band keying, and any in-band > keying specific data. > > I believe this is far superior than cedeing a large chunk of the SAID > space --- it's more flexible. In addition, the whole concept of a > "structured SAID" is a real perversion of the original meaning of a > Secure Association ID. A structured SAID isn't really an ID. It's > stealing 50% of the SAID space, and using a bit to indicate that the > rest of the SAID is an escape for a particular in-band keying system. > But it's extremely wasteful of the SAID space, and insufficiently > flexible. After all, we only get to define the structure of the > "structure SAID" once; and if we get it wrong, then that's it; we're > stuck. In fact Ashar Aziz and I have been working on a proposal along these lines for IPv6, which I am planning on sending out this afternoon. However, when you say > This is why I still maintain that a "structured SAID" is really all > about stealing one half of the SAID space for SKIP. I must disagree. SKIP is just one possible in-band keying method. At least one other exists, that designed by DEC. So I would say that using a bit in the SAID for in-band keying is not the most judicious use of the SAID identifier space. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 12:55:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19250; Wed, 8 Mar 95 12:55:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19244; Wed, 8 Mar 95 12:55:24 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22361; Wed, 8 Mar 1995 12:48:00 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA16655; Wed, 8 Mar 95 12:47:55 PST From: Ran Atkinson Message-Id: <9503081547.ZM1577@bodhi.itd.nrl.navy.mil> Date: Wed, 8 Mar 1995 15:47:27 -0500 In-Reply-To: Danny.Nessett@Eng.Sun.COM (Dan Nessett) "Re: (IPng) Re: out-of-band key management is like virtual circuits" (Mar 8, 12:29) References: <199503082030.AA27510@interlock.ans.net> X-Mailer: Z-Mail (3.0.0 15dec93) To: Dan Nessett , tytso@MIT.EDU Subject: Re: (IPng) Re: out-of-band key management Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, I find it REALLY fascinating that Dan Nessett and Ashar Aziz now agree that they in fact don't need a Structured SAID and that they can get along fine with having a single SAID dedicated to mean that "what comes next is a special in-band thingy". I note that this capability is -- and has for many months -- been in the IPv6 specs. There is an entire block of reserved SAIDs for IANA to allocate as IANA sees fit. No changes to the specs are needed for this as the hook was ALREADY present in the IPv6/IPv4 security specs. Ted T'so suggested the single magic SAID to mean "next comes an in-band thingy" over a week ago. Bill Simpson pointed it out at least that far back, though in his usual inimitable style. :-) Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 13:04:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19276; Wed, 8 Mar 95 13:04:13 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19270; Wed, 8 Mar 95 13:04:05 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id MAA18689; Wed, 8 Mar 1995 12:56:30 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id MAA02359; Wed, 8 Mar 1995 12:56:19 -0800 Date: Wed, 8 Mar 1995 12:56:19 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503082056.MAA02359@elrond.Eng.Sun.COM> To: atkinson@itd.nrl.navy.mil Subject: (IPng) Re: user-to-user vs. host-to-host keying Cc: ipsec@ans.net, ipng@sunroof X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, I am copying your original message to me to ipng, since my response below specifically addresses issues in the IPng security drafts. I am not sure why you sent your message only to ipsec. You write : > From rja@bodhi.itd.nrl.navy.mil Wed Mar 8 12:38:00 1995 > To: Dan Nessett > Subject: Re: user-to-user vs. host-to-host keying > Cc: ipsec@ans.net > Mime-Version: 1.0 > > Dan > > You confuse my "illustrative examples" for "sole justifications" > very consistently. My text includes a fair number of illustrative > examples. It does not include voluminous justifications for every > item that has been discussed either on the IPng list or the IPsec > list or at past IETF meetings in order to remain readably short. > > There are a number of reasons for user-to-user keying to be mandatory > to implement. One remains the desire to reduce risk of chosen > plaintext attacks. The only key management _mandated_ by IPv6 > is manual key distribution. Because development of a scalable > key management protocol is outside the charter of the IPng working > group and no such standards-track RFC exists now, this is all that > can be mandated at this time. Phil Karn and others are working hard > on developing such a scalable key management protocol and I am > optimistic that the Internet will have one in the future, but we > do not have one now. > > Regards, > > Ran > atkinson@itd.nrl.navy.mil > > When you argue that : > The only key management _mandated_ by IPv6 is manual key distribution. you mislead. Allow me to quote from the current IPv6 security architecture draft (page 7): "4.3 Automated Key Distribution Widespread deployment and use of IPv6 security will require an Internet-standard scalable key management protocol ... ... Hence, support for user-to-user keying must be present in all IPv6 implementations, as is described in the "IPv6 Key Management Requirements" section below." This is a requirement that all IPv6 implementations support user-to-user keying. This is what I am objecting to. User-to-user keying should not be required of conformant IPv6 implementations. It is unnecessary to deal with the threats you call out. You suggest in your message that there may be other reasons for using user-to-user keying. If so, I think these should be given in the I-Ds, since the ones you do give are to weak to justify the mandatory requirement. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 13:11:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19306; Wed, 8 Mar 95 13:11:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19300; Wed, 8 Mar 95 13:11:00 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24007; Wed, 8 Mar 1995 13:03:36 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA20119; Wed, 8 Mar 95 13:03:25 PST From: Ran Atkinson Message-Id: <9503081601.ZM1624@bodhi.itd.nrl.navy.mil> Date: Wed, 8 Mar 1995 16:01:01 -0500 In-Reply-To: Danny.Nessett@Eng.Sun.COM (Dan Nessett) "Re: user-to-user vs. host-to-host keying" (Mar 8, 12:56) References: <199503082056.MAA02359@elrond.Eng.Sun.COM> X-Mailer: Z-Mail (3.0.0 15dec93) To: Dan Nessett , atkinson@itd.nrl.navy.mil Subject: (IPng) Re: user-to-user vs. host-to-host keying Cc: ipsec@ans.net, ipng@sunroof.Eng.Sun.COM Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan, I did a "reply-all" to your note. My response went wherever your original note went. As far as I'm concerned, this can be discussed wherever. Ran ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 13:13:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19322; Wed, 8 Mar 95 13:13:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19316; Wed, 8 Mar 95 13:13:36 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24339; Wed, 8 Mar 1995 13:06:13 -0800 Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA20757; Wed, 8 Mar 95 13:06:08 PST Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id NAA17313; Wed, 8 Mar 1995 13:05:33 -0800 Date: Wed, 8 Mar 1995 13:05:33 -0800 From: Tony Li Message-Id: <199503082105.NAA17313@lager.cisco.com> To: Kim.Wohlert@mainz.dk Cc: yakov@watson.ibm.com, tli@cisco.com, ipng@sunroof.Eng.Sun.COM In-Reply-To: Kim Wohlert's message of Wed, 08 Mar 1995 15:59:57 +0100 <01HNWDI0BPHU000XV2@EMVAX1.MAINZ.DK> Subject: (IPng) Comments on -ipngwg-arch-addr-01.txt Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Kim, Thank you for your note. Yes, we realize that it is imperfect. Yes, we realize that this scheme (and indeed all others known in the state of the art) will break down at some point or in some worst-case scenario. All of the ones that we've seen constrain the "free development of the Internet provider industry" in some manner as well. While I disagree with some of the specifics in your note, the bottom line is that this is the best solution that exists today to a very hard problem. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 14:00:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19380; Wed, 8 Mar 95 14:00:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19349; Wed, 8 Mar 95 13:57:23 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28841; Wed, 8 Mar 1995 13:49:57 -0800 Received: from optima.cs.arizona.edu by Sun.COM (sun-barr.Sun.COM) id AA29169; Wed, 8 Mar 95 13:49:08 PST Received: from uncial.CS.Arizona.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP id AA21608; Wed, 8 Mar 1995 14:44:33 MST Received: by uncial.CS.Arizona.EDU; (5.65/1.1.8.2/08Nov94-0446PM) id AA16612; Wed, 8 Mar 1995 14:44:31 -0700 Date: Wed, 8 Mar 1995 14:43:33 -0700 From: Hilarie Orman Message-Id: <9503082144.AA16612@uncial.CS.Arizona.EDU> To: Danny.Nessett@Eng Cc: atkinson@itd.nrl.navy.mil, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net In-Reply-To: Yourmessage <199503082056.AA32235@interlock.ans.net> Subject: (IPng) Re: user-to-user vs. host-to-host keying Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > You suggest in your message that there may be other reasons for using > user-to-user keying. If so, I think these should be given in the I-Ds, > since the ones you do give are to weak to justify the mandatory requirement. I'd like to say that I concur with this request. We are in the process of prototyping this code (for ipv4), and it is difficult to motivate the design without a better understanding of the requirements of the use environment (more than "some people really want this"). ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 14:18:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19392; Wed, 8 Mar 95 14:18:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19386; Wed, 8 Mar 95 14:18:09 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01494; Wed, 8 Mar 1995 14:10:44 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA04277; Wed, 8 Mar 95 14:10:28 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm037-23.dialip.mich.net [141.211.7.96]) by merit.edu (8.6.10/merit-2.0) with SMTP id RAA05024 for ; Wed, 8 Mar 1995 17:10:23 -0500 Date: Wed, 8 Mar 95 21:17:40 GMT From: "William Allen Simpson" Message-Id: <4190.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: out-of-band key management Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Ran Atkinson > I find it REALLY fascinating that Dan Nessett and Ashar Aziz now > agree that they in fact don't need a Structured SAID and that they > can get along fine with having a single SAID dedicated to mean > that "what comes next is a special in-band thingy". > ... > Ted T'so suggested the single magic SAID to mean "next comes an > in-band thingy" over a week ago. Bill Simpson pointed it out at > least that far back, though in his usual inimitable style. :-) > Inimitable style, indeed. Since the postings were on the ipsec list, those IPng members who wish to read them will find them as the first of each series named: # Date: Thu, 23 Feb 95 00:57:12 GMT # From: "William Allen Simpson" # Subject: "in-band" is wrong idea/terminology Wherein I described why the use of the word "parasitic" would be an appropriate name, and requested: # You are certainly welcome to write up alternative security transforms # for our enlightenment. # Date: Tue, 28 Feb 95 21:33:26 GMT # From: "William Allen Simpson" # Subject: the silly bit # ... # A reserved bit is not "independent". It requires understanding by other # management schemes. What is to prevent a 3rd .. 20th contender to need # a bit of their own? # # I have suggested that you could write up a new transform draft showing # how your key management proposal would use the common header in a new # way. A reserved SAID number could be assigned for your proposal. 254 # of them are available. (#0 means no key, and #1 is for RSA.) # # Instead, you have chosen to argue endlessly. # ... Some people it just takes a little longer to get used to a new idea.... (never applies to me :-) Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 16:01:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19544; Wed, 8 Mar 95 16:01:13 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19537; Wed, 8 Mar 95 16:01:05 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id PAA26224; Wed, 8 Mar 1995 15:53:43 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id PAA02434; Wed, 8 Mar 1995 15:53:31 -0800 Date: Wed, 8 Mar 1995 15:53:31 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503082353.PAA02434@elrond.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng) Proposed modifications to IPv6 Security Architecture I-D (long) X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I propose the following changes to the current version of the IPv6 Security Architecture I-D [draft-ietf-ipngwg-sec-00.txt]. At those places where text is to be changed (as opposed to being simply deleted), I provide a suggested wording. Of course, the exact phrasing of the change is a matter for the editor to decide. I provide suggested wording only to make clear the substantive changes I am suggesting. Page 6, first para., section 4 - delete the text "IPv6 is not intended to support so-called "in-band" key management, where the key management data is carried in a distinct IPv6 header. Instead it will primarily use so-called "out-of-band" key management, where the key management data will be carried by an upper layer protocol such as UDP or TCP on some specific port number. This permits clear decoupling of the key management mechanism from the other security mechanisms, and thereby permits one to substitute new and improved key management methods without having to modify the implementations of the other security mechanisms. This is clearly wise given the long history of subtle flaws in published key management protocols. [NS78, NS81] What follows in this section is a brief discussion of a few alternative approaches to key management." Reasons for this change - There is no significant justification for prohibiting the use of in-band key management. This text was added after debate began on whether in-band key management should be allowed and before any resolution of that question. page 6-7, para. 2, section 4.3 - modify the text : 'When host-to-host keying is used and mutually suspicious users exist, it is possible for user A to determine the host-to-host key via well known methods, such as a Chosen Plaintext attack. Once user A has improperly obtained the key in use, user A can then either read user B's encrypted traffic or forge traffic from user B. When user-to-user keying is used, this kind of attack from one user onto another user's traffic is not possible. Hence, support for user-to-user keying must be present in all IPv6 implementations, as is described in the "IPv6 Key Management Requirements" section below.' to read 'When host-to-host keying is used and mutually suspicious users exist, it is theoretcially possible for user A to determine the host-to-host key via well known methods, such as a Known or Chosen Plaintext attack. These methods require a very large amount of plaintext/ciphertext pairs, the best method known in the public literature requiring 2^43 such data pairs. Conservatively, one may not feel comfortable using the same key to encrypt more than around 2^32 plaintexts. If user A has improperly obtained the key in use, user A can then either read user B's encrypted traffic or forge traffic from user B. This threat may be thwarted by either changing the encrypting key well before the required amount of text has been encrypted or by using user-to-user keying. Hence, support for user-to-user keying may be present in an IPv6 implementation, as is described in the "IPv6 Key Management Requirements" section below.' Reasons for this change - User-to-user keying may be useful in some situations, but given the state-of-the-art in cryptanalysis, more efficient and convenient methods exist for addressing the rationale for it given in the existing I-D. Rekeying the communications key well before the amount of ciphertext generated approaches the necessary volume is an attractive alternative. Requiring IPv6 implementations to support user-to-user keying is onerous and unnecessary. page 8, 2nd para., section 4.5 - - modify the text : 'All IPv6 implementations MUST support manual key management. All IPv6 implementations SHOULD support an Internet standard key management protocol once the latter is defined. All IPv6 implementations MUST permit the configuration and use of user-to-user keying for traffic originating at that system and MAY additionally permit the configuration of host-to-host keying for traffic originating at that system as an added feature to make manual key distribution easier and give the system administrator more flexibility.' to read 'All IPv6 implementations MUST support manual key management. All IPv6 implementations SHOULD support an Internet standard key management protocol once the latter is defined. All IPv6 implementations MAY permit the configuration and use of user-to-user keying for traffic originating at that system and MAY additionally permit the configuration of host-to-host keying for traffic originating at that system as an added feature to make manual key distribution easier and give the system administrator more flexibility.' Reasons for this change - see reasons given above. Regards, Dan Nessett ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 16:01:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19556; Wed, 8 Mar 95 16:01:25 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19543; Wed, 8 Mar 95 16:01:12 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id PAA26233; Wed, 8 Mar 1995 15:53:50 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id PAA02436; Wed, 8 Mar 1995 15:53:39 -0800 Date: Wed, 8 Mar 1995 15:53:39 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503082353.PAA02436@elrond.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng) Suggested modifications to the AH I-D (long) X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I propose the following changes to the current version of the IPv6 Authentication Header I-D [draft-ietf-ipngwg-sec-00.txt]. I acknowledge that the exact phrasing of the change is a matter for the editor to decide. I provide suggested wording only to make clear the substantive changes I am suggesting. In addition, I am open to other proposals, such as the one suggested by Russ Housley, that would allow the use of in-band keying with IPv6. I am sending this out now so that we have at least one concrete proposal to discuss in Danvers. page 3, 1st para., section 2 - modify to read - 'Key management is an important part of the IPv6 security architecture. IPv6 tries to decouple the key management mechanisms from the security protocol mechanisms. The only coupling between the key management protocol and the security protocol is with the Security Association Identifier (SAID) and with optional fields within the authentication data, which are described in more detail below. This decoupling permits several different key management mechanisms to be used. More importantly, it permits the key management protocol to be changed or corrected without unduly impacting the security protocol implementations.' Reasons for this change - to support in-band keying, the coupling between the security protocol and the key management protocol could also depend on data carried by the packet in the authentication field. page 4, para. 1, section titled "Security Association Identifier (SAID) - modify to read: A 32-bit pseudo-random value identifying the security association for this datagram. If no security association has been established, the value of this field shall be 0x00000000. If in-band keying is employed, this field shall be 0x00000001. The set of SAID values in the range 0x00000002 through 0x000000FF are reserved for future use. A security association is normally one-way. An authenticated communications session between two hosts will normally have two SAIDs in use (one in each direction). The combination of SAID value, optional fields within the authentication data, and destination address uniquely identifies the security association. The destination address may, of course, be a multicast group address. Reason for this change - To indicate in-band keying requires an SAID that is not a legal pre-established value. I chose the value 1 arbitrarily and would be open to some other value that is now reserved. page 6, para. 1, section 4 - modify the first sentence to read : When not carrying in-band data, the authentication data is usually calculated using a message digest algorithm (e.g. MD5) either encrypting that message digest or keying the message digest directly. Reason for this change - the conditional at the beginning of the sentence clarifies that the authentication data field may carry additional key management specific information. page 7, after para. 6, section 4 - insert the following text. 'When the SAID value indicates in-band keying, the format of the authentication header is as follows : +--------------+-----------------+----------------+------------+ | Next Payload | Length | RESERVED | +--------------+-----------------+----------------+------------+ | Security Association Identifier (=0x00...1) | +--------------+---------------+----------------+--------------+ |Key Management| Key Management Info | | ID | | +--------------+-----------------+----------------+------------+ | Key Management Info (variable length) | +--------------+---------------+----------------+--------------+ The key management ID specifies the format of the remaining data in the Authentication Header. Key management IDs are allocated by the Internet Assigned Numbers Authority (IANA). The remaining information in the authentication data field is formated according to rules specific to the indicated Key Management protocol. Each Key Management protocol is defined in a separate RFC.' Reason for the change - This additional format information is necessary to support in-band keying within the AH. It allows the specification of new in-band key management protocols as they are developed by only specifying a Key Management ID and leaving the format of the remaining information to be specified in a separate RFC. page 7, para. 1, section 5 - modify to read Implementations that claim conformance or compliance with this specification MUST fully implement the option described here, and MUST support the use of keyed MD5 as described in Appendix A of this document. Either host-to-host manual key distribution or user- to-user manual key distribution MAY be used with this option. Support for other authentication algorithms is not mandatory to comply or conform with this specification. Implementors should consult the most recent version of the IAB Official Standards document for further guidance on the status of this document. Reason for the change - Requiring all implementations to support user-to-user key distribution is onerous and unnecessary. Threats against encrypted communications based on widely know cryptanalytic techniques, such as differential or linear cryptanalysis can be thwarted by judicious rekeying of the communications key variables. User-to-user key distribution is another way to achieve protection in this regard, but is difficult to implement for some key management schemes. Dan Nessett ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 16:01:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19557; Wed, 8 Mar 95 16:01:36 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19550; Wed, 8 Mar 95 16:01:19 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id PAA26242; Wed, 8 Mar 1995 15:53:57 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id PAA02438; Wed, 8 Mar 1995 15:53:45 -0800 Date: Wed, 8 Mar 1995 15:53:45 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503082353.PAA02438@elrond.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng) Modifications to the ESP I-D (long) X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I propose the following changes to the current version of the IPv6 Encapsulating Security Payload I-D [draft-ietf-ipngwg-esp-0a.txt]. I acknowledge that the exact phrasing of the change is a matter for the editor to decide. I provide suggested wording only to make clear the substantive changes I am suggesting. In addition, I am open to other proposals, such as the one suggested by Russ Housley, that would allow the use of in-band keying with IPv6. I am sending this out now so that we have at least one concrete proposal to discuss in Danvers. page 4, para. 2, section 3.1 - change to read : A 32-bit pseudo-random value identifying the security association for this datagram. If no security association has been established, the value of this field shall be 0x00000000. If in-band keying is employed, this field shall be 0x00000001. The set of SAID values in the range 0x00000002 through 0x000000FF are reserved for future use. A security association is normally one-way. An authenticated communications session between two hosts will normally have two SAIDs in use (one in each direction). Reason for this change - To indicate in-band keying requires an SAID that is not a legal pre-established value. I chose the value 1 arbitrarily and would be open to some other value that is now reserved. page 4, para. 4, section 3.1 - change to read : Senders to a multicast group may share a common SAID for all communications if all communications are authenticated using the same security configuration parameters (e.g. algorithm, key, security classification level, etc.). In this case, the receiver only knows that the message came from a host knowing the security association data for the group and cannot authenticate which member of the group sent the datagram. Multicast groups may also use a separate SAID for each sender. In any event, the combination of Destination Address, optional fields within the synchronization data and the SAID is used to determine the correct security association data. If each sender is keyed separately and asymmetric algorithms are used, data origin authentication is also a provided service. Reason for this change - The presence of the optional in-band keying fields within the synchronization data would be additional information necessary to determine the correct security association data. page 5, para. 5, section 3.1 - change to read : Each SAID value, optional fields within the synchronization data and the destination address imply the key(s) used to encrypt and decrypt the encrypted portion of the ESP payload, the sensitivity level (e.g. Secret, Unclassified) of the user data in the ESP payload, the encryption algorithm being used, the block size (if any) of the encryption algorithm, the authentication algorithm being used (if separate from the encryption algorithm), the block size (if any) of the authentication algorithm, and the presence/absence and size of a cryptographic synchronisation or initialisation vector field at the start of the encrypted portion of the ESP (if no such field is present, then the size is of course zero). Reason for this change - same as those given in the previous callout. page 5, para. 5, section 3.1 - change to read : The sending host uses the sending userid and destination host to select an appropriate Security Association (and hence SAID value). The receiving host uses the combination of SAID value, optional fields within the synchronization data, and originating address to distinguish the correct association. Reason for this change - same as those givin in the previous two callouts. Also, the last sentence is removed since it is redundant. page 5, para. 6, section 3.1 - change to read : This field is present only for algorithms which require a cryptographic synchronisation field for each packet and for carrying in-band keying information, if present. The value of this field is arbitrary. The length of this field is variable, though for any given algorithm it has a particular known length. It is considered to be plaintext in this document, though most users will not be able to make sense of its contents. Its presence or absence are constant for all secure datagrams of any given SAID value. The ESP specification includes this field so that the payload specification will be independent of the cryptographic algorithm that is being used by the communicating systems. If present, the field contains cryptographic synchronisation data, such as a DES Initialisation Vector, for whichever algorithm is in use [ISO92b] or it contains in-band keying data. An ESP implementation will normally use the Security Association Identifier value for the payload being processed to determine whether this field is present and to determine the field's size and use if present. Reason for this change - The text indicates that the synchronization data may carry in-band keying data. page 5, after para. 6, section 3.1 - add the following text : When the SAID value indicates in-band keying, the synchronization data field carries Key Management method specific information, In that case the format of the Encapsulating Security Payload is as follows : +--------------+---------------+----------------+--------------+ | Security Association Identifier (=0x00...1) | +--------------+---------------+----------------+--------------+ |Key Management| Key Management Info | | ID | | +--------------+-----------------+----------------+------------+ | Key Management Info (variable length) | +--------------+---------------+----------------+--------------+ | Encrypted Data | +--------------+---------------+----------------+--------------+ The key management ID specifies the format of the remaining data in the Encapsulating Security Payload. Key management IDs are allocated by the Internet Assigned Numbers Authority (IANA). The remaining information in the synchronization data is formated according to rules specific to the indicated Key Management protocol. Each Key Management protocol is defined in a separate RFC. Reason for the change - This additional format information is necessary to support in-band keying within the ESP. It allows the specification of new in-band key management protocols as they are developed by only specifying a Key Management ID and leaving the format of the remaining information to be specified in a separate RFC. page 7, para. 2, section 4.1 - change to read : The receiver strips off the cleartext IPv6 header and cleartext optional IPv6 payloads (if any) and discards them. It then uses the combination of Destination Address, optional information within the synchronization data and SAID value to obtain the correct decryption key to use for this packet. Then, it decrypts the ESP using the session key that has been established for this traffic. Reason for this change - The presence of the optional in-band keying fields within the synchronization data would be additional information necessary to determine the correct decryption key. page 8, para. 2, section 4.2 - change to read : The receiver processes the cleartext IPv6 header and cleartext optional IPv6 headers (if any) and temporarily stores pertinent information (e.g. source and destination addresses, Flow ID, Routing Header). It then decrypts the ESP using the session key that has been established for this traffic, using the combination of the destination address, optional information within the synchronzation data and the packet's Security Association Identifier (SAID) to locate the correct key. Reasons for this change - same as those given in the previous callout. page 10, para. 4, section 7 - change to read : If user-to-user keying is not in use, then the algorithm in use should not be vulnerable to any kind of Chosen Plaintext attack. A Chosen Plaintext attack on DES is described in [BS93]. Use of user-to-user keying is one way to preclude any sort of Chosen Plaintext attack and to generally make cryptanalysis more difficult. Another is to change the session key with sufficient frequency that deprives the cryptoanalyst of enough plaintext/ ciphertext pairs to carry out an effective attack. Reasons for this change - Since user-to-user keying is only one way to address problems arising from cryptoanalytic attacks, alternative methods should be mentioned. Dan Nessett ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 16:05:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19580; Wed, 8 Mar 95 16:05:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19574; Wed, 8 Mar 95 16:05:47 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16020; Wed, 8 Mar 1995 15:58:23 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA01986; Wed, 8 Mar 95 15:58:23 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA21219; Wed, 8 Mar 95 18:58:21 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503082358.AA21219@wizard.gsfc.nasa.gov> Subject: Re: (IPng) WG last call: v6 ICMP draft To: ipng@sunroof.Eng.Sun.COM Date: Wed, 8 Mar 1995 18:58:20 -0500 (EST) In-Reply-To: <199503080301.WAA18478@newdev.harvard.edu> from "Scott Bradner" at Mar 7, 95 10:01:49 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > there has been some level of discussion on this topic, at this time > the ball is the sdrp's court. the general idea is that one way > to deal with this is to add a bit to the routing header to give the > intermediate router a hit that the most reliable way to get back to the > source is via reversing the source route. There are people who feel that > mandating source route reversal is a Bad Thing since the router at the > error point might actually be able to get back via flat routing or that > the paths are not the same in each direction and a reversed source > route would fail. In any case the topic needs to be worked through > with the source route people and included in the source route writeup. > > Scott After mulling this over some more, I have the following observations: If we consider a simple source route: source host A -> intermediate source router B -> destination host C In general, I believe it is true that routing is commutative in the sense that if there is a route from A to B, then most likely there is also a route from B to A (and yes I'm sure there are exceptions), and also recognizing that the routes may not be the same, i.e. in the case of asymmetric routing. Thus, in my example above, if there was a route from A to B, one could also presume that there would be a route from B to A, and likewise if there was a route from B to C, one could presume that there also was a route from C to B. However, it is not as safe an assumption to assume that routing is transitive, i.e. just because there is a route from A to B and a route from B to C does not imply that there is a route from A to C or a route back from C (or any transit router in the path from B to C) to A. One common case of this is where B is a firewall router and the network between A and B is not directly visible to the Internet. The following discussion assumes this scenario. Of course, I made an oversimplification in my simple source route. The actual path would be: source host A -> input interface B1 on intermediate source router B -> output interface B2 on intermediate source router B -> destination host C And A might specify the source route as A -> B1 -> C. In this case, my commutativity assumption falls apart, since when C reverses the route to get C -> B1 -> A, it discovers there is no route to B1 since that address is on the hidden network connecting A and B. However, there is a way to fix this. If we change the way the routing header is processed as follows: If a router is the intermediate destination of a source routed packet where the intermediate destination is a unicast address, then have the router change its entry in the source route to be the primary unicast address associated with the logical interface on which it will transmit the packet to forward it on to the next destination in the source route. In my example, this means B would change the source route to A -> B2 -> C. C would reverse the route to get C -> B2 -> A. C would most likely have a route back to B2 (the Internet side of B) and B would have a route back to A, so packets from C (or any transit router in the path from B to C) could be successfully delivered to A. If the change I am suggesting was made, I think reversed source routes would work in the vast majority of cases, and would be the optimal choice for the default behavior in the sense that it would probably function correctly in more cases than simply flat routing back to the original source. In any case, we need to define in the specification what the default behavior of ICMP should be in the presence of a routing header. I guess you are saying this will be documented in the SDRP spec. Given this, we need a short explanation and reference to the SDRP spec in a suitable place in the ICMP spec. Finally, it is probably going to be required to allow local policy to be able to override whatever is specified as the default behavior. -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 16:08:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19599; Wed, 8 Mar 95 16:08:59 PST Received: from eunuchs.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19593; Wed, 8 Mar 95 16:08:47 PST Received: by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA14050; Wed, 8 Mar 1995 16:01:26 -0800 Received: from snail.Sun.COM by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA14032; Wed, 8 Mar 1995 16:01:23 -0800 Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AB07875; Wed, 8 Mar 95 16:01:22 PST Received: from ns.incog.com by Sun.COM (sun-barr.Sun.COM) id AA02529; Wed, 8 Mar 95 16:01:19 PST Received: by ns.incog.com (8.6.10/94082501) id QAA18170; Wed, 8 Mar 1995 16:01:50 -0800 Received: from osmosys.incog.com by ns.incog.com (8.6.10/94082501) id QAA18155; Wed, 8 Mar 1995 16:01:48 -0800 Received: from miraj.incog.com by osmosys.incog.com (5.x/SMI-SVR4) id AA02085; Wed, 8 Mar 1995 16:01:40 -0800 Received: by miraj.incog.com (5.x/SMI-SVR4) id AA06685; Wed, 8 Mar 1995 15:58:37 -0800 Date: Wed, 8 Mar 1995 15:58:37 -0800 From: ashar@icgmail.Eng.Sun.COM (Ashar Aziz) Message-Id: <9503082358.AA06685@miraj.incog.com> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net X-Sun-Charset: US-ASCII X-Icg-Mailfrom: ashar@icgmail.eng.sun.com Subject: Re: (IPng) Re: out-of-band key management Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Ran Atkinson > > I find it REALLY fascinating that Dan Nessett and Ashar Aziz now > agree that they in fact don't need a Structured SAID and that they > can get along fine with having a single SAID dedicated to mean > that "what comes next is a special in-band thingy". > > I note that this capability is -- and has for many months -- > been in the IPv6 specs. There is an entire block of reserved > SAIDs for IANA to allocate as IANA sees fit. No changes to the > specs are needed for this as the hook was ALREADY present in > the IPv6/IPv4 security specs. Ran, Does this mean that you agree that the following text should be taken out from Section 4 of the "IPv6 Security Architecture" document? "IPv6 is not intended to support so-called "in-band" key management, where the key management data is carried in a distinct IPv6 header. Instead it will primarily use so-called "out-of-band" key management, where the key management data will be carried by an upper layer protocol such as UDP or TCP on some specific port number." Regards, Ashar. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 18:49:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19705; Wed, 8 Mar 95 18:49:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19699; Wed, 8 Mar 95 18:49:44 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03051; Wed, 8 Mar 1995 18:42:19 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA29483; Wed, 8 Mar 95 18:42:16 PST Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA21698; Wed, 8 Mar 1995 21:42:13 -0500 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65 EXP 2/22/95 for V3.2/1.1.8.2/18Feb95-1123AM) id AA04577; Wed, 8 Mar 1995 21:42:11 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA09427; Wed, 8 Mar 1995 21:18:05 -0500 Message-Id: <9503090218.AA09427@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) WG last call: v6 ICMP draft In-Reply-To: Your message of "Tue, 07 Mar 95 20:26:12 EST." <9503080126.AA19396@wizard.gsfc.nasa.gov> Date: Wed, 08 Mar 95 21:18:05 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM An important number of comments were received from the mailing list - from Thomas Narten, Charlie Lynn, and Bill Fink - relative to the IPv6 ICMP specifications, which contributes to fulfilling the role of the last call. I thank very much for the attention given to the specifications and I thank for the issues raised or suggestions made for its improvment. The text of the IPv6 ICMP specification was already changed to reflect the feedback. The attached message is a combined response to the three messages received. Thanks, Alex =========================================== From: Thomas Narten Subject: Re: (IPng) WG last call: v6 ICMP draft I have a few questions and some nits. Note also that I haven't always followed all previous discussions closely, so some of my questions may seem obvious. Feel free to direct me to the archived mailings if something has been hashed out in detail previously. "query" is misspelled "qeury"; forget to run the document through spell? :-) Thanks. The spell checker "personal dictionary" was at fault. Corrected. There are still some to be filled in. Do these need to be filled in before going to proposed standard? I note that in draft-ietf-ipngwg-address-format that the entire conclusion section is missing, which somehow doesn't seem quite appropriate. As Steve Deering said earlier, there will be no TBDs in the document submitted as proposed standard. The TBDs have been replaced with the value 58 in the ICMP specifications text sources. > > If the message is a response to a message sent to one of the | > node's unicast address, the Source Address of the reply must be | ^^^^^^^ plural Thanks again. Corrected at your suggestion. > that same address. | > > If the message is a response to a message sent to a multicast | > group in which the node is a member, the Source Address of the | > reply must be a unicast address belonging to the interface on | ^^^ should this be "a" or "the"? That is, can an interface have multiple addresses at the same time? Text is correct as is. There can be multiple addresses per interface. > which the multicast packet was received. | > > Otherwise, the node's routing table must be examined to determine | > which interface will be used to transmit the message to its | > destination, and a unicast address belonging to that interface | > must be used as the Source Address of the message. | > > Implementations MUST observe the following rules when processing IPv6 > ICMP messages (from [RFC-1122]): > > (a) If an IPv6 ICMP message of unknown type is received, it MUST be > silently discarded. > > (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. This statement implies that there may be cases where the returned IP header may be so large that the transport header (with its port numbers) gets omitted. This is true, the transport header may get omitted. A previous incarnation of the document contained text that suggested an algorithm for providing as much useful information as possible, but the feedback from the WG that it is too much work for very little return, and a good chance to not get it right in an implementation, convinced us to remove that text. > A Destination Unreachable message SHOULD be generated by a router, or | > by the IPv6 layer in the originating node, in response to a packet | ^^^^^^^^^^^^^^^^ I think "destination node" is meant. The text is correct as is. The type of "destination unreachable" referred to cannot be generated by the "destination node", since the "destination" node would have no reason to generate such an ICMP message - the packet reached its destination node. > that cannot be delivered to its destination address for reasons other | > than congestion. (If a packet is dropped due to congestion, no ICMP | > error message is generated.) If the reason for the failure to | > deliver is lack of a matching entry in the forwarding node's routing | > table, the Code field is set to 0 (NOTE: this error can occur only in | > > >3.2. | > Packet Too Big Message | > > > MTU The Maximum Transmission Unit of the next-hop link. | This may have been discussed before, but I don't recall the final outcome. What happens when a packet's size increases as it goes through (say) an encapsulating router. If I understand correctly, the intervening router is now considered a new "sender", and its address is now the packet's source address, in which case, any later attempt to forward the packet across an MTU that is too small results in a "packet too big" message being returned to the encapsulating router rather than the original sender. Is this in fact what is supposed to happen now? That is, can the size of a V6 datagram increase (after having left the sending node) *ONLY* if it is re-encapsulated, so that any "path too big" message does not go back to the original sender? Path MTU includes the tunnel Path MTU, so the originating node is informed about the PMTU as many times as needed until the size of the packet is such that no ICMP Packet Too Big is being generated on the packet's path, including the tunnel. The encapsulating node converts ICMP messages from inside the tunnel to ICMP messages sent to the originating node, passing the correct PMTU information in the ICMP message. > >Description > > A Packet Too Big MUST be sent by a router in > response to a packet that it cannot forward because the packet is | > larger than the MTU of the outgoing link. The information in this | > message is used as part of the Path MTU Discovery process [RFC-1191]. | > > Sending a Packet Too Big Message makes an exception to the rules of | > when to send an ICMP error message, in that unlike other messages, it | > is sent in response to a packet received with an IPv6 multicast | ^^ change "is" to "may be"? Text is correct as is. The paragraph above states "MUST be sent", so sending it is mandatory. > destination address, or a link-layer multicast or link-layer | > broadcast address. | > >Upper layer notification > > An incoming Packet Too Big message MUST be passed to the transport > layer. Do we really want to say "transport layer"? What about the case where the originating packet is an ICMP echo request? I note that the wording concerning "upper layer notification" differs in some cases. How about just saying something like "... message MUST be passed to the appropriate upper layer module for processing." Is this not specific enough? Thanks for the suggestion. "Upper layer" will do for any layer that is above ICMP. > > IPv6 systems are expected to avoid fragmentation by implementing Path > MTU discovery. However, IPv6 defines an end-to-end fragmentation > function for backwards compatibility with existing higher-layer | > protocols. All IPv6 implementations are required to support | > reassembly | > of IPv6 fragments. There MUST be a reassembly timeout. The > reassembly timeout SHOULD be a fixed value. It is recommended that > this value lie between 60 and 120 seconds. If the timeout expires, > the > partially-reassembled packet MUST be discarded. If the fragment | > with offset zero was received, the destination host SHOULD also send > an IPv6 ICMP Time Exceeded message with Code 1 to the source of the | > fragment. | I'm not necessarily advocating removing this, but under exactly what scenarios is it in fact useful to get this message? What is a sending node in IPv4 supposed to do when it gets one of these? It seems to me that the message essentially is saying "don't fragment", which v6 senders don't do anyway. v4 senders do this because they have no choice (presumably), in which case they are probably just going to ignore the message. The ICMP message signals that not all IPv6 fragments of a datagram were received for a successful reassembly. The sender of the fragments can interpret that as to send fragments at a slower rate. >Upper layer notification > > An incoming Time Exceeded message MUST be passed to the transport > layer. Again, the "transport layer" wording doesn't seem quite right. If the offending message was an echo request... Has been changed to "Upper layer". >4.1. > Echo Request Message | > Destination Address | > Any legal IPv6 address. | It might help clarify things a bit to add the words "(including a multicast address)". Reading this the first time, I was wondering whether multicast addresses were allowed and concluded they were only by the lack of discussion explicitely forbidding it. We prefer this wording which is flexible to cover multicasting. > > The data received in the ICMP Echo Request message MUST be returned | > entirely and unmodified in the ICMP Echo Reply message, unless the | > Echo Reply would exceed the MTU of the path back to the Echo | > requester, in which case the data is truncated to fit that path MTU. | I'm not sure what to say about this statement other than it makes me a bit uncomfortable. Is there a hidden "gotcha"? I assume that the sending ICMP actually truncates the packet, so the ICMP checksum is at least correct. But the sending host now has to explicitely remember what the original packet size was in order to determine that the response was truncated (probably not a big deal). Would it make sense (or even be useful) to use a code other than 0 to indicate that the packet was truncated for path MTU reasons? IPv6 ICMP will not send fragmented ICMP messages. There is a good chance that the PMTU used for sending the request is identical with that used to send the reply. If that is not the case, then the receiver of the ICMP reply could check that the reply matches the request, or the portion of the request equal to the size of the reply. ===================================== From: Charles Lynn Subject: Re: (IPng) WG last call: v6 ICMP draft Folks, I do not think that draft-ietf-ipngwg-icmp-01.txt is ready to be advanced. Since ICMP plays a key role in Path MTU Discovery, and since no IPv6 document describing the procedures for MTU discovery, with all the complications introduced by truncation, ESP, ERP, header insertion by security firewalls or routing agents, etc., is available for review, I am not able to conclude that the ICMP as described is adequate. page 4: Header value of in the immediately preceding header. (NOTE: | ICMP(), and the entire ICMP message starting with the ICMP | Fill in TBD with 58. This has been done in the document to be submitted. Page 5: (a) If an IPv6 ICMP message of unknown type is received, it MUST be silently discarded. For extensibility, wouldn't it be better to pass all errors (Type < 128) to the transport layer, even if ICMP itself does not understand the Type? Noted and changed the text to reflect the suggestion. (b) Every IPv6 ICMP error message (the first four messages in the above list) includes as much of the IPv6 offending (invoking) "Type < 128" instead of referencing the list. Thanks, this seems a good suggestion, so it was incorporated in to the text. (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. I think that this is inadequate for two reasons. First, truncation as specified in (b) may loose the Extension Header before the transport header making it impossible to determine the appropriate transport layer; note that the transport layer ports would also be missing. As stated in the previous answer, in one of the previous ICMP drafts the attempt made to select the returned information in the ICMP error packet was considered not enough useful for its complexity, and return, and it was removed. The second case is when there is an ESP header that obscures the required demultiplexing information, which may have been truncated due to (b). Note also that the originating system may not have the keys to decrypt the returned packet (fragment). It might be the case that the originator will have to keep state information -- SAID+32 bits, transport session -- to perform the demultiplexing. In case of IPv6 ICMP packet truncation, it is possible that some of the useful information is lost, and so the ICMP message cannot be used 100%. These problems imply that some other mechanism must be used to perform the demultiplexing. How about something like adding 64 bits (to maintain alignment) of additional header to the error types to be used as follows. The WG considered there is too little return to try to fit all the useful information in case of truncated packets. a) If there is an ESP header, the first 32 bits contain the SAID and the second 32 bits contain the 32 bits immediately following the SAID. b) If there is no ESP header, the first 32 bits contain 24 bits of zero and 8 bits of transport protocol number. If the transport protocol number is 59, "No Next Header", the second 32 bits are zero, otherwise, they are the first 32 bits of the transport header, presumably the source and destination port numbers. (d.1.)an IPv6 ICMP error message, or | Insert "Types < 128". Thanks. Done .... page 8: Packet Too Big Message | We need procedures for how encapsulators handle these messages. A harder problem is how firewalls or other systems that insert headers get correct information back to the source. Maybe this will be covered in the Path MTU Discovery document. Encapsulating IPv6 packets is not in the scope of the ICMP specifications. page 10: If a router receives a packet with a Hop Limit of zero, or a router decrements a packet's Hop Limit to zero, it discards the packet and Ought to clarify that the decrement only happens when packets are forwarded; packets received with a zero Hop Limit destined to a higher layer are delivered and the Hop Limit is not decremented. Thanks. The text implies that discarding the packet with a hop limit 0 occurs during the forwarding of the packet by a router. There are interactions between fragmentation/reassembly and ESP that should be described. The case of a Fragmentation Header then an ESP header only requires that the original (encrypted) first fragment be retained for possible inclusion in a Time Exceeded message. The case of an ESP Header then a Fragmentation Header is a little more complex. Each packet containing an ESP header would have to be retained -- either decryption to a second buffer, or a packet copy then decryption in place -- until it can be ascertained that the packet does not contain a Fragmentation Header with offset zero. If it is fragment zero, it should be retained for a possible Time Exceeded message. It sounds like decryption in place to save a packet copy is not consistent with the ICMP requirements. Thanks for pointing this out. I think that fragmentation/reassembly issues related to the ESP header are beyond the scope of the IPv6 ICMP specifications. page 11: Parameter Problem Message The same issue of saving a packet with an ESP Header until the decrypted packet has been processed arises here. Is the "leaking" of a pointer into the encrypted portion of the packet a serious threat? The ICMP error message may be encrypted if necessary. page 13: Echo Request Message | & Echo Reply Message | Every node MUST implement an ICMP Echo responder function that | receives Echo Requests and sends corresponding Echo Replies. A node SHOULD also implement an application-layer interface for sending Echo Requests and receiving Echo Replies, for | diagnostic purposes. What procedures should the responder use when the Echo Request: a) contains an Authentication Header but no ESP Header? - Should the reply also contain an Authentication Header? - What if there is no SAID for the reply? Must one be established for the reply? Should an unauthenticated reply be sent if no SAID is available? Should a "well known SAID with well known Key" be used? The ICMP is layered on top of IPv6 security. So if the ICMP ECHO request gets to the ICMP layer, the ICMP layer will generate a response, and pass the response to the IPv6 layer, which will generate the IPv6 headers. It is the setting of the IPv6 security layer which will decide how to handle the outgoing packet - whether to generate security extension headers or not. The action taken by the IPv6 layer of the ICMP responder depends on how the responder node is set up. If it is setup to generate authentication headers, than one will be generated. If generating authentication headers is ON, but there is no SAID, then this is a problme local to the responder node, which should be reported and resolved locally. b) contains an ESP Header? - Should the reply contain an ESP Header? - What if there is no SAID for the reply? - Should the reply ever be sent as cleartext if the request was not? Same as above (ESP instead of Authentication). Should a system operating in the "requires authentication/authenticates" and or "confidentiality" mode(s) be required to respond to unauthenticated(cleartext) Echo Requests, presumably for diagnostic purposes? No. If a node is set in "requires authentication/authenticates" or "confidentiality" mode(s), the ICMP layer will not get the unauthenticated 'cleartext' Echo Request, and so it will not respond to it, which is IMO the correct behavior. Do we want a SHOULD respond to unauthenticated/cleartext Echo Request with unauthenticated/cleartext Echo Reply unless explicitly configured by system administration to not do so? The IPv6 security sublayer is responsible for building security headers on packet output. The ICMP layer responds to input packets that are passed up (we discuss the ECHO packets) by calling the IPv6 output layer. How serious id the threat to probing for valid SAIDs, etc., using ICMP Echos? Should there be a "well known SAID" with "well known key(s)" to permit interoperability testing, etc.? No, I do not think so. page 14: The data received in the ICMP Echo Request message MUST be returned | entirely and unmodified in the ICMP Echo Reply message, unless the | Echo Reply would exceed the MTU of the path back to the Echo | requester, in which case the data is truncated to fit that path MTU. | Does this mean that the echo responder MUST have performed Path MTU Discovery to the sending system before sending the Echo Reply? Must the responder retain the Echo Reply message in case it subsequently receives a Packet Too Big message? Is it explicitly improper for the included message to be used for the Echo Reply (as it might be shorter than path MTU)? Yes. It is implied that the ICMP sender sends packets that are no larger than the Path MTU. This applies for requests and replies. page 16: typo The address if the multicast group about which the "of" Charlie Corrected. Thanks. ========================= From: bill@wizard.gsfc.nasa.gov (Bill Fink) Subject: Re: (IPng) WG last call: v6 ICMP draft Technical: 1. I agree with other comments that the value for the next header field that identifies an IPv6 ICMP payload should be specified rather than being listed as TBD, prior to making this a Proposed Standard. Thanks, done. 2. On Page 5, in the section on selection of a source address to use for generating an ICMP message, I do not agree with the choice specified for the otherwise section. Rather than choosing an address on the transmit interface that the ICMP message will be sent via, this needs to depend on the type of ICMP packet: A. For time exceeded, hop limit exceeded, the source address of the ICMP packet should definitely be a unicast address belonging to the interface on which the packet was received. This is required so traceroute will report meaningful information even in the presence of asymmetric routing. We want to know the actual path a data packet is traversing through a set of routers, and not the return paths from those intermediary routers. If it is necessary to know the return path from a particular router, we can use traceroute with a source route option. Time exceeded, fragment reassembly time exceeded, should not be applicable to a transit router. B. For destination unreachable, no route, the source address of the ICMP packet should probably be the router ID (defined in Router Requirements). Another alternative would be to choose a unicast address belonging to the interface on which the packet was received. C. For destination unreachable, communication administratively prohibited, the source address of the ICMP packet should be a unicast address belonging to the interface on which the packet would have been transmitted had the communication not been administratively prohibited. If this is considered a security concern, then the router ID could be used instead, or simply not send an ICMP packet at all. D. For destination unreachable, address unreachable, the source address of the ICMP packet should be a unicast address belonging to the interface on which the packet could not be transmitted due to a data link problem. Destination unreachable, port unreachable, should not be applicable to a transit router. E. For packet too big, the source address of the ICMP packet should be a unicast address belonging to the interface on which the packet could not be transmitted because the data link MTU was too small. F. For parameter problem, the source address of the ICMP packet should probably be the router ID. Another alternative would be to choose a unicast address belonging to the interface on which the packet was received. Thanks. I think in 2., entirely or parially, A & B & F coincide with the source address selection mechanism specified in the IPv6 ICMP document. The suggestion in 2., C & D & E, has been included as it follows: If the message is a response to a packet forwarding action that cannot complete successfully, the Source Address must be a unicast address belonging to the interface on which the packet forwarding failed. 3. In the same section on selection of a source address for an ICMP packet, regarding responding to a message sent to a multicast group in which the node is a member, I would also add some words to cover the case of a cluster address, i.e.: If the message is a response to a message sent to a multicast group or cluster address for which the node is a member, the Source Address of the reply must be a unicast address belonging to the interface on which the multicast or cluster addressed packet was received. Noted. The appropriate term will be used. .... Editorial: 1. I think the ICMP type values for neighbor discovery should be included in the table on Page 4, with a reference to the IPv6 Neighbor Discovery document. A previous draft contained text as you suggested, but at the strong suggestion of Bill Simpson, that has been removed. 2. There's a typo in Section 2 on Page 6. In paragraph (e), there's a "the the". Thanks. Corrected. 3. In the Description section of Section 3.1 on page 7, the part that says "by the IPv6 layer in the originating node" should say "receiving node". Thanks. The text is correct as is - explained in previous response. 4. In Section 4.1 on Page 12, for the Destination Address field, I agree with another comment that this should say "Any legal IPv6 address including a multicast or cluster address" rather than just say "Any legal IPv6 address". Thanks. Also explained in previous answer. 5. In Section 4.2 on Pages 13 and 14, I would move the paragraph: The source address of an Echo Reply sent in response to a unicast Echo Request message MUST be the same as the destination address of that Echo Request message. to the IPv6 Fields part, after a new field labeled Source Address, right before the Destination Address field. Thanks. It used to be this way in a previous draft, but it has been simplified since. ... 7. In section 4.3 on Page 16, under the Multicast Address field, there is a typo. It should read "The address of the multicast group" instead of "The address if the multicast group". Thanks. Corrected as consequence of a previous comment. Comment/Question: 1. Are RFCs 1112, "Host Extensions for IP Multicasting", and RFC 1191, "Path MTU Discovery", on the list for review by the IPng Working Group for the first set of base documents for the full IPv6 specification? If not, I think they should be. 2. Are there any cases where ICMP packets should not be sent in response to cluster addresses? If so, that should be documented. ==========================From: bill@wizard.gsfc.nasa.gov (Bill Fink) One more question: 3. Do we need to specify the path that an ICMP error or reply packet will take in the presence of a routing header? I am inclined to say that it must reverse the portion of the source route that has been used up to that point. Thanks. This is beyond the scope of the ICMP document. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 18:56:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19727; Wed, 8 Mar 95 18:56:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19721; Wed, 8 Mar 95 18:56:10 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03520; Wed, 8 Mar 1995 18:48:45 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA00470; Wed, 8 Mar 95 18:48:45 PST Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA22000; Wed, 8 Mar 1995 21:48:43 -0500 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65 EXP 2/22/95 for V3.2/1.1.8.2/18Feb95-1123AM) id AA07081; Wed, 8 Mar 1995 21:48:41 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA28743; Wed, 8 Mar 1995 21:24:36 -0500 Message-Id: <9503090224.AA28743@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) WG last call: v6 ICMP draft In-Reply-To: Your message of "Wed, 08 Mar 95 18:58:20 EST." <9503082358.AA21219@wizard.gsfc.nasa.gov> Date: Wed, 08 Mar 95 21:24:36 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: bill@wizard.gsfc.nasa.gov (Bill Fink) Subject: Re: (IPng) WG last call: v6 ICMP draft Return-Path: owner-ipng@sunroof2.eng.sun.com In-Reply-To: <199503080301.WAA18478@newdev.harvard.edu> from "Scott Bradner" at *** Mar 7, 95 10:01:49 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Reply-To: ipng@sunroof.eng.sun.com > there has been some level of discussion on this topic, at this time > the ball is the sdrp's court. the general idea is that one way > to deal with this is to add a bit to the routing header to give the > intermediate router a hit that the most reliable way to get back to the > source is via reversing the source route. There are people who feel that > mandating source route reversal is a Bad Thing since the router at the > error point might actually be able to get back via flat routing or that > the paths are not the same in each direction and a reversed source > route would fail. In any case the topic needs to be worked through > with the source route people and included in the source route writeup. > > Scott After mulling this over some more, I have the following observations: If we consider a simple source route: source host A -> intermediate source router B -> destination host C ... The example that I have in mind, and which I think has been discussed is: host A -> router B -> router C -> router D -> host E host A <- router F <- router G <- router H <- host E An ICMP packet generated by host E may take a different path A-F-G-H-E than the path A-B-C-D-E. Alex A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 19:48:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19784; Wed, 8 Mar 95 19:48:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19778; Wed, 8 Mar 95 19:48:45 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06241; Wed, 8 Mar 1995 19:41:21 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA07499; Wed, 8 Mar 95 19:41:12 PST Received: from relay.imsi.com by wintermute.imsi.com id WAA24176; Wed, 8 Mar 1995 22:39:54 -0500 Received: from snark.imsi.com by relay.imsi.com id WAA24098; Wed, 8 Mar 1995 22:39:53 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA24298; Wed, 8 Mar 95 22:39:52 EST Message-Id: <9503090339.AA24298@snark.imsi.com> To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management In-Reply-To: Your message of "Wed, 08 Mar 1995 15:58:37 PST." <199503090001.AA25539@interlock.ans.net> X-Reposting-Policy: redistribute only with permission Date: Wed, 08 Mar 1995 22:39:52 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ashar Aziz says: > > Ran, > > Does this mean that you agree that the following text should be > taken out from Section 4 of the "IPv6 Security Architecture" document? > > "IPv6 is not intended to support so-called "in-band" key > management, where the key management data is carried in a > distinct IPv6 header. Instead it will primarily use so-called > "out-of-band" key management, where the key management data will > be carried by an upper layer protocol such as UDP or TCP on some > specific port number." I oppose the removal of the language. IPv6 and IPSP are NOT intended for "in-band" key management. The fact that you can get them to do it against the intentions of the designers does not change the intent and purpose of the original design. You have to live with that. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 8 20:11:46 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19829; Wed, 8 Mar 95 20:11:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19823; Wed, 8 Mar 95 20:11:38 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07337; Wed, 8 Mar 1995 20:04:13 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA09652; Wed, 8 Mar 95 20:04:04 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA21559; Wed, 8 Mar 95 22:57:38 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503090357.AA21559@wizard.gsfc.nasa.gov> Subject: Re: (IPng) WG last call: v6 ICMP draft To: ipng@sunroof.Eng.Sun.COM Date: Wed, 8 Mar 1995 22:57:38 -0500 (EST) In-Reply-To: <199503080301.WAA18478@newdev.harvard.edu> from "Scott Bradner" at Mar 7, 95 10:01:49 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM A couple more comments: 1. Shouldn't the value of the Hop Limit field for ICMP packets be specified, e.g. the maximum value of 255 for ICMP error packets? This is only currently specified for the IGMP flavor ICMP packets. 2. In Section 2 on Page 5, Paragraph (d.1.), which states that an IPv6 ICMP error message MUST NOT be sent as a result of receiving an IPv6 ICMP error message, should some explanatory text be added indicating that this will require scanning through all the Next Header fields to determine if any is an ICMP payload? Also, will it be legal to encrypt ICMP error messages? If so, the above provision may be impossible to check and could lead to some very interesting failure modes. I would think ICMP error packets should never be encrypted but I haven't kept up with all the security aspects of IPv6. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 04:20:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19994; Thu, 9 Mar 95 04:20:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19988; Thu, 9 Mar 95 04:18:30 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB26068; Thu, 9 Mar 1995 04:09:18 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA27122; Thu, 9 Mar 95 04:09:12 PST From: Ran Atkinson Message-Id: <9503090705.ZM2115@bodhi.itd.nrl.navy.mil> Date: Thu, 9 Mar 1995 07:05:49 -0500 In-Reply-To: ashar@osmosys.incog.com (Ashar Aziz) "Re: (IPng) Re: out-of-band key management" (Mar 8, 15:58) References: <199503090001.AA25539@interlock.ans.net> X-Mailer: Z-Mail (3.0.0 15dec93) To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ashar, "not intended to support..." is different from "is intended to prohibit...". There is rough consensus in the IPsec WG, which is the ONLY IETF WG chartered to work on key mgmt, that the primary standards-track key mgmt protocol will and should be a hybrid Diffie-Hellman scheme (such as Photuris). There is nothing resembling consensus in favour of SKIP-style in-band key mgmt as a mandatory-to-implement standards-track approach. My text as it stands is ENTIRELY consistent with the consensus direction in key mgmt. I do not plan any changes to the text you cited at this time. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 04:41:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20006; Thu, 9 Mar 95 04:41:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20000; Thu, 9 Mar 95 04:41:06 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26790; Thu, 9 Mar 1995 04:32:48 -0800 Received: from emvax1.mainz.dk by Sun.COM (sun-barr.Sun.COM) id AA28917; Thu, 9 Mar 95 04:32:36 PST Received: from KW.mainz.dk by EMVAX1.MAINZ.DK (PMDF V4.3-10 #7874) id <01HNXM7MOX4W000ZEA@EMVAX1.MAINZ.DK>; Thu, 09 Mar 1995 13:19:24 +0100 (WET) Date: Thu, 09 Mar 1995 13:19:41 +0100 From: Kim.Wohlert@mainz.dk (Kim Wohlert) Subject: Re: (IPng) Comments on -ipngwg-arch-addr-01.txt X-Sender: kw@emvax1.mainz.dk To: ipng@sunroof.Eng.Sun.COM Message-Id: <01HNXM7MUA1E000ZEA@EMVAX1.MAINZ.DK> Mime-Version: 1.0 X-Mailer: Windows Eudora Version 1.4.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Thank you all for the various responses to my previous mail. I can see that this has been brought up previously (in fact I would have been worried if no-one had thought about this before :-)). I see that there does not seem to be any other way to do it with our current technology and knowledge. But the important question is then if the suggested solution will in fact help. As described in my previous mail, the scheme will break down for the providers in Denmark. If this is true in many other locations, then everybody is worse off: We create provider tie-in, but we don't get the benefit of route aggregation. If 80% of routes end up not being 'aggregateable', then we might as well do nothing i.e. use a flat address space, at least at the country level, if it is only 20%, then it is probably worthwile. Regards Kim =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Kim Wohlert |Internet:Kim.Wohlert@mainz.dk erik mainz a/s |X.400: c=DK a=DK400 p=Minerva Dortheavej 7 |o=mainz s=Wohlert g=Kim DK-2400 Copenhagen |Phone: +45 38 34 77 88 Denmark |Fax: +45 31 19 16 25 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- (This place reserved for future expansion) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 05:02:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20023; Thu, 9 Mar 95 05:02:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20012; Thu, 9 Mar 95 05:00:30 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27368; Thu, 9 Mar 1995 04:51:54 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA00369; Thu, 9 Mar 95 04:51:47 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA26378; Thu, 9 Mar 95 04:45:29 -0800 Received: by xirtlu.zk3.dec.com; id AA18603; Thu, 9 Mar 1995 07:45:25 -0500 Message-Id: <9503091245.AA18603@xirtlu.zk3.dec.com> To: perry@imsi.com Cc: ashar@osmosys.incog.com (Ashar Aziz), ipng@sunroof.Eng.Sun.COM, ipsec@ans.net, bound@zk3.dec.com Subject: Re: (IPng) Re: out-of-band key management In-Reply-To: Your message of "Wed, 08 Mar 95 22:39:52 EST." <199503090341.AA05388@interlock.ans.net> Date: Thu, 09 Mar 95 07:45:19 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Ashar Aziz says: >> >> Ran, >> >> Does this mean that you agree that the following text should be >> taken out from Section 4 of the "IPv6 Security Architecture" document? >> >> "IPv6 is not intended to support so-called "in-band" key >> management, where the key management data is carried in a >> distinct IPv6 header. Instead it will primarily use so-called >> "out-of-band" key management, where the key management data will >> be carried by an upper layer protocol such as UDP or TCP on some >> specific port number." >I oppose the removal of the language. IPv6 and IPSP are NOT intended >for "in-band" key management. The fact that you can get them to do it >against the intentions of the designers does not change the intent and >purpose of the original design. You have to live with that. I think if in-band key management can be used it should be stated so in the spec as any other option would be. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 05:13:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20035; Thu, 9 Mar 95 05:13:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20029; Thu, 9 Mar 95 05:13:05 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27759; Thu, 9 Mar 1995 05:03:59 -0800 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA01260; Thu, 9 Mar 95 05:03:51 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 9 Mar 1995 23:03:02 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Thu, 9 Mar 1995 23:03:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 9 Mar 1995 23:01:40 +1000 Date: Thu, 9 Mar 1995 23:01:40 +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 Mar 09 23:01:40 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 400123090395 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <400123090395*/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) Proposed modifications to IPv6 Security Architect... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >'When host-to-host keying is used and mutually suspicious users >exist, it is theoretcially possible for user A to determine the >host-to-host key via well known methods, such as a Known or Chosen "theoretically" is not reflecting reality. Unless keys change in some random and humanly/machinely unpredicatable way then the potential is not theoretical but definite that someone will steal a key sequence. >Regards, >Dan Nessett Regards Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 06:11:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20056; Thu, 9 Mar 95 06:11:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20050; Thu, 9 Mar 95 06:11:08 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00683; Thu, 9 Mar 1995 06:02:49 -0800 Received: from Bill.Simpson.DialUp.Mich.Net (pm036-13.dialip.mich.net) by Sun.COM (sun-barr.Sun.COM) id AA06901; Thu, 9 Mar 95 06:02:41 PST Date: Thu, 9 Mar 95 13:31:23 GMT From: "William Allen Simpson" Message-Id: <4213.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) WG last call: v6 ICMP draft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > 1. Shouldn't the value of the Hop Limit field for ICMP > packets be specified, e.g. the maximum value of 255 > for ICMP error packets? This is only currently > specified for the IGMP flavor ICMP packets. > Actually, I don't think it should be specified at all. The Hop Limit now is advertised in Router Advertisements. > Also, will it be legal to encrypt ICMP error messages? > If so, the above provision may be impossible to check > and could lead to some very interesting failure modes. > I would think ICMP error packets should never be > encrypted but I haven't kept up with all the security > aspects of IPv6. > I believe it will be legal to encrypt, although I can't think of much use. An error reply to an error would only occur if it wasn't able to decrypt. If it couldn't decrypt, then the ICMP error is probably the Security Violation message. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 06:12:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20068; Thu, 9 Mar 95 06:12:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20062; Thu, 9 Mar 95 06:12:11 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00739; Thu, 9 Mar 1995 06:03:53 -0800 Received: from by Sun.COM (sun-barr.Sun.COM) id AB06901; Thu, 9 Mar 95 06:03:46 PST Date: Thu, 9 Mar 95 13:35:16 GMT From: "William Allen Simpson" Message-Id: <4214.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Modifications to the ESP I-D (long) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Please mark me as opposed to these changes, without recapitulation. It is clear to me that we need no references to "in-band" (endogenous) keying, as they have nothing to do with this transform. They will have their own transforms, which have different format headers. I have repeatedly requested that they provide these transform documents, and they have thus far failed to do so. > From: Danny.Nessett@eng.sun.com (Dan Nessett) > I propose the following changes to the current version of the IPv6 > Encapsulating Security Payload I-D [draft-ietf-ipngwg-esp-0a.txt]. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 06:13:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20080; Thu, 9 Mar 95 06:13:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20074; Thu, 9 Mar 95 06:13:15 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00778; Thu, 9 Mar 1995 06:04:56 -0800 Received: from by Sun.COM (sun-barr.Sun.COM) id AB06901; Thu, 9 Mar 95 06:04:50 PST Date: Thu, 9 Mar 95 13:41:43 GMT From: "William Allen Simpson" Message-Id: <4215.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Proposed modifications to IPv6 Security Architecture I-D (long) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Please mark me as opposed to these changes, without recapitulation. Many of these changes from MUST to MAY weaken the overall security of IPv6. Allowing "weak" security requirements is not in the best interest of the Internet. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 06:19:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20092; Thu, 9 Mar 95 06:19:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20086; Thu, 9 Mar 95 06:19:16 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01156; Thu, 9 Mar 1995 06:11:51 -0800 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA08153; Thu, 9 Mar 95 06:11:40 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 10 Mar 1995 00:10:53 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Fri, 10 Mar 1995 00:11:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 10 Mar 1995 00:08:40 +1000 Date: Fri, 10 Mar 1995 00:08:40 +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 Mar 10 00:08:40 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 400800100395 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <400800100395*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof2.Eng.Sun.COM (Non Receipt Notification Requested) Subject: Re: (IPng) Re: out-of-band key management X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim Following the arguments, I tend to argree with you. What concerns me is how a proliferation of techniques gets implemented. SAIDs etc give the means of determining the technique used but does that mean that I must support them all? At this point we have not got to discussing what the various crypto techniques may or may not be used. Indeed has the most common technique to be used 5 years from now been invented? IMHO it is better to have a limited flexible set of options that are degress apart rather than a number of options that are poles apart. In short pick one and be dammed. >I think if in-band key management can be used it should be stated so in >the spec as any other option would be. >/jim Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 06:32:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20130; Thu, 9 Mar 95 06:32:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20116; Thu, 9 Mar 95 06:32:12 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01802; Thu, 9 Mar 1995 06:24:47 -0800 Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA09875; Thu, 9 Mar 95 06:24:47 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id JAA05243 for ipng@sunroof.Eng.Sun.COM; Thu, 9 Mar 1995 09:27:42 -0500 (EST) Date: Thu, 9 Mar 1995 09:27:42 -0500 (EST) From: Scott Bradner Message-Id: <199503091427.JAA05243@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) WG last call: v6 ICMP draft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > 1. Shouldn't the value of the Hop Limit field for ICMP > > packets be specified, e.g. the maximum value of 255 > > for ICMP error packets? This is only currently > > specified for the IGMP flavor ICMP packets. > > > Actually, I don't think it should be specified at all. The Hop Limit > now is advertised in Router Advertisements. humm, do routers in the middle of a WAN net get these Advertisements? come to think of it - do routers with no LAN connections send the advertisements that include the hop count etc? Scott PS - is the default value for hop-count in the doc for the advertisements? (yes I have read it :-), but don't remember the answer) I'm not sure it should be (should it be in assigned numbers?) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 08:10:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20202; Thu, 9 Mar 95 08:10:03 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20196; Thu, 9 Mar 95 08:09:56 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA26659; Thu, 9 Mar 1995 08:02:32 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA02781; Thu, 9 Mar 1995 08:02:19 -0800 Date: Thu, 9 Mar 1995 08:02:19 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503091602.IAA02781@elrond.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Proposed modifications to IPv6 Security Architect... X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jeff, You say : > "theoretically" is not reflecting reality. Unless keys change in some random > and humanly/machinely unpredicatable way then the potential is not theoretical> but definite that someone will steal a key sequence. I beleive the distinction is not between host-to-host and user-to-user keying, but between proper and improper session key management. If a session key is used to encrypt enough data so that a cryptoanalytic attack becomes possible, then this is a problem whether host-to-host or user-to-user keying is employed. Regards, Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 09:22:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20220; Thu, 9 Mar 95 09:22:33 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20214; Thu, 9 Mar 95 09:22:25 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id JAA29939; Thu, 9 Mar 1995 09:12:55 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id JAA02822; Thu, 9 Mar 1995 09:12:41 -0800 Date: Thu, 9 Mar 1995 09:12:41 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503091712.JAA02822@elrond.Eng.Sun.COM> To: sob@newdev.harvard.edu Subject: (IPng) Clarification Cc: ashar@jurassic, ipng@sunroof, ipsec@ans.net X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Scott, I wonder if you might clear up two points of administration. I and Ashar Aziz have been discussing the use of in-band keying in IPv6 using the IPv6 discussion list. These discussions relate to the 3 security I-Ds that Ran Atkinson is editing. Ran has recently emailed out a reply to us stating, " There is rough consensus in the IPsec WG, which is the ONLY IETF WG chartered to work on key mgmt, ... " In regards to this, I have 2 questions : 1. Are the drafts that Ran is editing for IPv6 the responsibility of the IPng or IPsec WG? 2. After Danvers, will these drafts be transfered to IPsec as part of the IPng area break up? Regards, Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 11:20:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20322; Thu, 9 Mar 95 11:20:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20316; Thu, 9 Mar 95 11:20:00 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29021; Thu, 9 Mar 1995 11:12:33 -0800 Received: from Bill.Simpson.DialUp.Mich.Net (pm038-18.dialip.mich.net) by Sun.COM (sun-barr.Sun.COM) id AA08623; Thu, 9 Mar 95 11:12:15 PST Date: Thu, 9 Mar 95 18:41:13 GMT From: "William Allen Simpson" Message-Id: <4219.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) WG last call: v6 ICMP draft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Scott Bradner > > Actually, I don't think it should be specified at all. The Hop Limit > > now is advertised in Router Advertisements. > > humm, do routers in the middle of a WAN net get these Advertisements? > come to think of it - do routers with no LAN connections send the > advertisements that include the hop count etc? > Routers are configured with the value, but yes, of course they get the advertisements. The advertisements don't know they are in the middle of a WAN. > PS - is the default value for hop-count in the doc for the advertisements? > (yes I have read it :-), but don't remember the answer) I'm not sure it > should be (should it be in assigned numbers?) > It _only_ references Assigned Numbers. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 11:30:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20347; Thu, 9 Mar 95 11:30:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20341; Thu, 9 Mar 95 11:30:25 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00327; Thu, 9 Mar 1995 11:22:57 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA11504; Thu, 9 Mar 95 11:22:54 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA22833; Thu, 9 Mar 95 14:22:46 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503091922.AA22833@wizard.gsfc.nasa.gov> Subject: Re: (IPng) WG last call: v6 ICMP draft To: ipng@sunroof.Eng.Sun.COM Date: Thu, 9 Mar 1995 14:22:45 -0500 (EST) In-Reply-To: <199503091427.JAA05243@newdev.harvard.edu> from "Scott Bradner" at Mar 9, 95 09:27:42 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > > 1. Shouldn't the value of the Hop Limit field for ICMP > > > packets be specified, e.g. the maximum value of 255 > > > for ICMP error packets? This is only currently > > > specified for the IGMP flavor ICMP packets. > > > > > Actually, I don't think it should be specified at all. The Hop Limit > > now is advertised in Router Advertisements. > > humm, do routers in the middle of a WAN net get these Advertisements? > come to think of it - do routers with no LAN connections send the > advertisements that include the hop count etc? Plus, it's not necessarily true, and I wouldn't recommend it, that the Hop Limit for ICMP error packets should be the same as the Hop Limit for normal datagram packets, which I agree should be derived from the Router Advertisements. I think ICMP error packets should just use the maximum legal value of 255. I want to insure being able to get ICMP errors from a remote site, even if their routers happen to be misconfigured with too small a Hop Limit for normal datagram packets. -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 13:07:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20605; Thu, 9 Mar 95 13:07:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20593; Thu, 9 Mar 95 13:07:33 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12517; Thu, 9 Mar 1995 13:13:56 -0800 Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA07027; Thu, 9 Mar 95 13:13:41 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id QAA08135; Thu, 9 Mar 1995 16:16:34 -0500 (EST) Date: Thu, 9 Mar 1995 16:16:34 -0500 (EST) From: Scott Bradner Message-Id: <199503092116.QAA08135@newdev.harvard.edu> To: Danny.Nessett@Eng, sob@newdev.harvard.edu Subject: (IPng) Re: Clarification Cc: ashar@jurassic.Eng.Sun.COM, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan, I've checked this out with Ran, the Security AD, and the Internet ADs they, and I, all agree that the finalization of the security documents will be a responsibility of the IPSEC WG after the IPng area folds. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 13:15:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20619; Thu, 9 Mar 95 13:15:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20613; Thu, 9 Mar 95 13:15:17 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13346; Thu, 9 Mar 1995 13:21:05 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA09212; Thu, 9 Mar 95 13:21:01 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA23007; Thu, 9 Mar 95 16:20:56 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503092120.AA23007@wizard.gsfc.nasa.gov> Subject: Re: (IPng) WG last call: v6 ICMP draft To: ipng@sunroof.Eng.Sun.COM Date: Thu, 9 Mar 1995 16:20:55 -0500 (EST) In-Reply-To: <9503090218.AA09427@brigit.zk3.dec.com> from "conta@zk3.dec.com" at Mar 8, 95 09:18:05 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alex, Thanks for your response. Most of my concerns have been addressed with one important exception, which concerns selection of the source address for ICMP error packets of the type time exceeded, code hop limit exceeded, because of the critical importance to traceroute (see my comments below). -Bill > > A Destination Unreachable message SHOULD be generated by a router, or | > > by the IPv6 layer in the originating node, in response to a packet | > ^^^^^^^^^^^^^^^^ > I think "destination node" is meant. > > The text is correct as is. The type of "destination unreachable" referred to > cannot be generated by the "destination node", since the "destination" node > would have no reason to generate such an ICMP message - the packet reached > its destination node. Huh? I still don't understand this. The type of "destination unreachable" being talked about at this point is not specified. This is the first paragraph immediately following the IPv6 ICMP Fields section, which simply lists all possible "destination unreachable" codes, "port unreachable" being one of the possible codes. Certainly, "port unreachable" may be generated by the destination node, and that's what I thought that part of the sentence was referring to, while the first part of the sentence covered the router case. Could you please elaborate. > Path MTU includes the tunnel Path MTU, so the originating node is informed > about the PMTU as many times as needed until the size of the packet is such > that no ICMP Packet Too Big is being generated on the packet's path, including > the tunnel. The encapsulating node converts ICMP messages from inside the > tunnel to ICMP messages sent to the originating node, passing the correct PMTU > information in the ICMP message. Is it ever allowed to encapsulate ICMP error packets rather than converting them at a tunnel boundary? I would think not. If this is indeed the case, should we explicitly mention anywhere that ICMP error packets MUST NOT ever be encapsulated. > 2. On Page 5, in the section on selection of a source > address to use for generating an ICMP message, I do > not agree with the choice specified for the otherwise > section. Rather than choosing an address on the > transmit interface that the ICMP message will be > sent via, this needs to depend on the type of ICMP > packet: > > A. For time exceeded, hop limit exceeded, the source > address of the ICMP packet should definitely be a > unicast address belonging to the interface on which > the packet was received. This is required so > traceroute will report meaningful information even > in the presence of asymmetric routing. We want to > know the actual path a data packet is traversing > through a set of routers, and not the return paths > from those intermediary routers. If it is necessary > to know the return path from a particular router, > we can use traceroute with a source route option. > > ... > > Thanks. > > I think in 2., entirely or parially, A & B & F coincide with the source > address selection mechanism specified in the IPv6 ICMP document. The A case, time exceeded, hop limit exceeded, was completely different and is the one I am most concerned about since it is what is used by traceroute, which is one of the most critically important network troubleshooting tools available, and we need to insure it continues to operate in an optimal manner in IPv6. The original IPv6 ICMP spec said to use the address of the router corresponding to the return path of the ICMP error packet from the router back to the original source of the packet that caused the ICMP error packet to be generated, while I suggested changing this to the address of the router corresponding to the interface upon which the original packet was received that caused the ICMP error message to be generated. These are not the same in the case of asymmetric routing between the original source and the router generating the ICMP error message, and the change I suggested is what is required to make traceroute most meaningful. Thus, to insure the continued, optimal use of traceroute in IPv6, I think it is critical to have some explicit language in the IPv6 ICMP spec regarding processing of the time exceeded, hop limit exceeded, ICMP error, namely stating that for that case, the source address of the ICMP error packet MUST be set to the primary unicast address of the router generating the ICMP error message which corresponds to the logical interface upon which the original packet arrived that caused the ICMP error message to be generated. As far as B (destination unreachable, no route) and F (parameter problem), the distinction is less important. The original IPv6 ICMP spec said to use the address associated with the return path, while I suggested changing this to the router ID, which is basically the largest unicast IP address associated with the router (either via an interface address or an actual router "address" in the case all the interfaces on the router are unnumbered). No critical information is lost with the original IPv6 ICMP spec, but I still feel the suggested change is cleaner. > The suggestion in 2., C & D & E, has been included as it follows: > > If the message is a response to a packet forwarding action that cannot > complete successfully, the Source Address must be a unicast address belonging > to the interface on which the packet forwarding failed. For C (destination unreachable, communication administratively prohibited), D (destination unreachable, address unreachable), and E (packet too big), and as long as it is made clear that this does not apply to A (time exceeded, hop limit exceeded), this wording is fine. The wording would be ambiguous or wrong for the A case, since it would not be clear whether the referenced interface was the input interface or the output interface, and we need to make it explicit that the input interface MUST be chosen for the source address selection in the A case (for traceroute). > .... I note that you did not respond to either my item 4 (regarding unnumbered interfaces on a router as it relates to selection of a source address for ICMP packets) or my item 5 (regarding timer-based rate limiting of ICMP packets). > 3. In the Description section of Section 3.1 on page 7, > the part that says "by the IPv6 layer in the > originating node" should say "receiving node". > > Thanks. The text is correct as is - explained in previous response. See earlier comments. > ... I note that you did not respond to my item 6 (regarding confusion concerning upper layer notification when an Echo Request originated in the IP layer). ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 14:23:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20796; Thu, 9 Mar 95 14:23:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20790; Thu, 9 Mar 95 14:23:02 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20443; Thu, 9 Mar 1995 14:22:42 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA21451; Thu, 9 Mar 95 14:22:41 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA23130; Thu, 9 Mar 95 17:22:38 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503092222.AA23130@wizard.gsfc.nasa.gov> Subject: Re: (IPng) WG last call: v6 ICMP draft To: ipng@sunroof.Eng.Sun.COM Date: Thu, 9 Mar 1995 17:22:37 -0500 (EST) Cc: conta@zk3.dec.com In-Reply-To: <9503090224.AA28743@brigit.zk3.dec.com> from "conta@zk3.dec.com" at Mar 8, 95 09:24:36 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The example that I have in mind, and which I think has been discussed is: > > host A -> router B -> router C -> router D -> host E > > host A <- router F <- router G <- router H <- host E > > An ICMP packet generated by host E may take a different path A-F-G-H-E than the > path A-B-C-D-E. > > Alex Alex, My last sentence: Finally, it is probably going to be required to allow local policy to be able to override whatever is specified as the default behavior. was intended to cover the case of your example (or were you alluding to something besides the local policy at your host E overriding the source route specification of host A?). My suggestion for changing the processing of the routing header by an intermediate source router was intended to cover the default behavior when there was no explicit policy at host E, and was primarily intended to make an automatically reversed source route have the best chance of actually working in as many cases as possible. I.e, if host E receives the packet A:B:C:D:E, and has no local policy regarding A, it would simply reverse the route and send replies back to A using E:D:C:B:A. I was trying to argue that this would, with my suggested change, actually have the best chance of successfully getting packets back to A, and would cover almost all normal situations I can envision better than simply the flat routing E:A. If E does have local policy regarding A, then it would be free to use the route E:H:G:F:A as you suggest. -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 14:46:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21023; Thu, 9 Mar 95 14:46:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21017; Thu, 9 Mar 95 14:46:47 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23230; Thu, 9 Mar 1995 14:44:17 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA26250; Thu, 9 Mar 95 14:44:16 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA23179; Thu, 9 Mar 95 17:42:45 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503092242.AA23179@wizard.gsfc.nasa.gov> Subject: Re: (IPng) WG last call: v6 ICMP draft To: ipng@sunroof.Eng.Sun.COM Date: Thu, 9 Mar 1995 17:42:45 -0500 (EST) In-Reply-To: <4213.bsimpson@morningstar.com> from "William Allen Simpson" at Mar 9, 95 01:31:23 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > Also, will it be legal to encrypt ICMP error messages? > > If so, the above provision may be impossible to check > > and could lead to some very interesting failure modes. > > I would think ICMP error packets should never be > > encrypted but I haven't kept up with all the security > > aspects of IPv6. > > > I believe it will be legal to encrypt, although I can't think of much > use. An error reply to an error would only occur if it wasn't able to > decrypt. If it couldn't decrypt, then the ICMP error is probably the > Security Violation message. > > Bill.Simpson@um.cc.umich.edu Let me rephrase my question slightly. Will it be legal for routers to encrypt ICMP error messages? E.g., if a transit router discovers there is no route to a destination, is it legal for the router to encrypt the destination unreachable, no route, ICMP error packet when it sends it back to the source of the problem packet (this packet may then encounter some other error condition on its way back to the original source which may require generation of another ICMP error message which may in turn be encrypted, etc)? -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 17:32:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21436; Thu, 9 Mar 95 17:32:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21430; Thu, 9 Mar 95 17:32:31 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11540; Thu, 9 Mar 1995 17:25:04 -0800 Received: from nic1.barrnet.net by Sun.COM (sun-barr.Sun.COM) id AA20578; Thu, 9 Mar 95 17:25:03 PST Received: from ipsilon.com by nic1.barrnet.net (8.6.10/BARRNET-RELAY.1) id RAA07634; Thu, 9 Mar 1995 17:25:02 -0800 Received: from [192.216.126.207] (acacia) by ipsilon.com (4.1/SMI-4.1MDV1.0) id AA03978; Thu, 9 Mar 95 17:23:33 PST X-Sender: hinden@servo.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Mar 1995 17:22:58 -0800 To: ipng@sunroof.Eng.Sun.COM From: hinden@ipsilon.com (Bob Hinden) Subject: (IPng) Last Call for IPng Addressing Architecture Document Cc: hinden@ipsilon.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM A new version of the IPng Addressing Architecture has been posted to the Internet Draft directories. It should appear in the next day or so. It includes the following changes from the previous version: o Added "Addressing Model" section. o Changed "Node ID" to "Interface ID" to reflect the current Addressing Model. o Cluster Address replaced by Region Address. o Geographic Addresses changed to be Neutral-Interconnect Addresses. o Changed multicast scope names from inter-*** to ***-local style. o Added mention that address subfields can be assigned a zero or ones value. o Reduced the amount address space assigned to local use and divided the local use address space into link-local and site- local unicast. o Swapped prefixes for IPv4-compatible and IPv4 mapped addresses. o Changed definition of loopback address. o Added wording about wired in knowledge of address prefixes. o Minor clarification's, corrections, and typos fixed. These changes reflect the outcome of the previous working group meetings. This message constitutes the IPng working group last call for this document. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 20:56:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21750; Thu, 9 Mar 95 20:56:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21744; Thu, 9 Mar 95 20:55:58 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26081; Thu, 9 Mar 1995 20:48:31 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA18388; Thu, 9 Mar 95 20:48:27 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA14082; Tue, 7 Mar 95 12:47:18 -0800 Received: by xirtlu.zk3.dec.com; id AA28302; Tue, 7 Mar 1995 15:02:59 -0500 Message-Id: <9503072002.AA28302@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net, bound@zk3.dec.com Subject: Re: (IPng) Proposed message on perfect forward security In-Reply-To: Your message of "Tue, 07 Mar 95 13:42:36 EST." <199503071850.AA29002@interlock.ans.net> Date: Tue, 07 Mar 95 15:02:53 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The latest specs on IPv6 security now clearly state that in-band cannot be used for IPv6. Seeing how Dan and others are promoting in-band security as a technology we may want in the future, and that the ipng mail list will be asked to do a last call prior to IPv6 Security going to proposed standard, why I think it was very informative and kindly to see Dan's mail on the IPng list. But I also hope that any discussion re: in-band vs out-band be done on IPSEC mail list not both. I will also add that ESP requires DES. Could we select an encryption algorithm that has no export restrictions any where in the world. Also for companies doing development internationally where engineers on teams are located in different geographical locations it makes it tough on software planning. For example I would not be able to give one of my engineering colleagues DES code from the U.S., if they were working in the Ural Mountains doing the IPv6 ESP Security work on my project. This kind of bugs me. Another one for IPSEC I think. thanks Dan, /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 9 23:17:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21768; Thu, 9 Mar 95 23:17:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21762; Thu, 9 Mar 95 23:16:54 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01198; Thu, 9 Mar 1995 23:09:28 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA01074; Thu, 9 Mar 95 23:09:28 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA23667; Fri, 10 Mar 95 02:09:21 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503100709.AA23667@wizard.gsfc.nasa.gov> Subject: Re: (IPng) Base IPv6 Specification: Robust Service vs Lack of Header Checksum To: Christian.Huitema@sophia.inria.fr (Christian Huitema) Date: Fri, 10 Mar 1995 02:09:21 -0500 (EST) Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <199503081004.LAA22744@mitsou.inria.fr> from "Christian Huitema" at Mar 8, 95 11:03:58 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Christian, Thanks for the detailed response providing your insight and analysis related to the issue of the lack of a header checksum in IPv6. It is very useful to me in trying to understand this issue and in trying to determine if it's something to still be concerned about. I have a number of comments below. They are fairly lengthy but I hope you will persevere since I consider this topic extremely important. You went a long way toward addressing my concerns with your suggestion of having routers cache the source/flow/destination tuple for the first packet in a flow and checking subsequent packets in the flow against the cached values. My level of concern regarding the risk to the Internet caused by the lack of a header checksum in IPv6 is now greatly reduced, although there are still a few remaining areas of concern. I realize that many (in the original SIP working group particularly) concluded the risk was minimal a long time ago, and that this must seem old hat and a rehashing of closed issues to some, so I appreciate your patience and thank you again for the time you have taken to respond. -Bill Let me preface my remarks by indicating my biggest areas of concern are long lived flows and multicasting, especially the two in conjunction, since failure modes involving these will probably have the biggest impact on the future Internet. Also, the following summary rationale you gave, or something very much like it, should be included in the IPng Overview document. Many other changes from IPv4 to IPv6 are described in the IPng Overview but the rationale for dropping the header checksum is conspicuously absent. > Bill, > > The basic rationales for removing the checksums were the followings: > > 1) Hop by hop errors are usually detected with media-level checksums. > > 2) End to end checksums, such as TCP's or UDP's, are designed to catch the > residual errors. These errors are generally caused by the misbehaviour of > relays, e.g. memory faults or software faults. > > 3) Header checksums are ill suited to catch the misbehaviour of relays, as > header checksums tend to be recomputed by each relay. I was proposing that transit relays would never recompute the entire base header checksum. They would either not touch it at all (if the checksum did not include the Hop Limit field) or incrementally update it to reflect the decrementing of the Hop Limit (if the checksum did include the Hop Limit field). Thus, it would generally be possible to detect the misbehavior of relays. In fact, in the case of flows, even if a transit relay munged a packet and also improperly recomputed the entire base header checksum giving the packet an apparently legitimate checksum, another downstream transit relay could still catch the error in most cases by comparing it against its cached value for the checksum for that flow (the one exception to this is if the error occurred on the first packet of the flow but for long lived flows the probability of this would be relatively low and I agree that we can't detect and prevent everything). > 4) Checking and recomputing the checksum for each packet imply a large > performance penalty. The cost/advantage analysis shows too much cost and too > little benefit. I proposed an optimization for flows that would make the performance hit relatively minor, which changes the cost/advantage analysis. Specifically, for flows, which I believe will predominate the traffic mix eventually, I showed how it is only necessary to check and cache the base header checksum for the first packet in a flow. All future packets in the flow would only require comparing the packet checksum with the cached checksum, which is a minimal cost. > A header checksum would not catch any of the problems you quoted if these are > caused by a faulty relay that erroneously alters the header, and then > recomputes the header. In fact, you will note that all the errors you quote > can be turned into deliberate denial of service attacks. Protection against > such attacks would be necessary for a very robust service; it requires much > more than a header checksum. As I pointed out earlier, it would in fact be possible in most cases for a downstream transit relay to detect errors introduced by a faulty upstream transit relay, even if that relay was violating the IPv6 specification by recomputing the entire base IPv6 header checksum. Yes, I agree that the header checksum cannot protect against malicious denial of service attacks. The IPv6 authentication and integrity security features would be required to prevent these kinds of attacks, but they obviously have a MUCH higher performance penalty than a single compare instruction for checking the header checksum. The header checksum is only intended to protect against faulty relays or undetected data link errors (I don't think it's safe to assume that all, especially new experimental/prototype, data links that might be part of the Internet will be fully robust and catch all their own errors). > I note that you seem to advocate a "fixed checksum" approach, i.e. one that is > computed by the source and only checked by the relays. The problem here is > that source routing may cause the destination to change. In fact, one could > argue that we already have this "fixed checksum" built in, as the flow-id. The > flow-id is supposed to be taken at random, which result in the same entropy as > a checksum. All packets send by the a given route on a given flow are suppose > to floow the same route. An intermediate relay can thus cache the > flow/source/dest tuple. When processing a packet, it can look at this cache, > detect a mismatch, and an error. I think I might not have explained myself clearly. Let's assume that the base IPv6 header checksum covers the Version, Flow Label, Source and Destination Address fields in the base IPv6 header of the packet, and for the sake of simplifying the following arguments (and to further reduce the performance hit if that is a concern), that it does not include the Hop Limit field. Then for a given flow, the checksum would be invariant for that flow. One thing that might be misunderstood is that the Destination Address that I'm assuming is covered by the base IPv6 header checksum is the current Destination Address in the base IPv6 header and not necessarily the ultimate destination address of the packet if a source Routing Header is present in the packet. I assume that the ultimate destination address is protected by the end-to-end TCP/transport checksum and also by a separate checksum on the Routing Header (which only needs to be checked or incrementally upgraded by routers that are a member of the source route list). Probably all payloads, except security payloads which have a much stronger protection mechanism already, should have a checksum field to protect them against corruption. To make this a little clearer, here's an example. Suppose we have the following path: source A -> transit router T1 -> source router R1 -> transit router T2 -> source router R2 -> transit router T3 -> destination B and A has a flow F to B using the source route A:R1:R2:B. Portion of Path Base IPv6 Header Fields <------------------> ----------------------- A:R1 R1:R2 R2:B Flow Label: F F F Source Address: A A A Destination Address: R1 R2 B Checksum: S1 S2 S3 Routing Header Checksum: RS1 RS2 RS3 Yes, the checksum S1 on the portion of the path A:R1 is different than the checksum S2 for R1:R2 is different than the checksum S3 for R2:B, but each checksum is invariant for all packets belonging to a given flow for that portion of the path. Thus the source A need only compute the checksum once for the flow F and just set it for all subsequent packets belonging to that flow. Routers T1 and R1 only need check the checksum S1 once for packets from A belonging to flow F, cache that value with the soft state for the flow, and then use the cached value to compare against the checksum in subsequent packets belonging to the same flow. Routers T2 and R2 use the same procedure regarding checksum S2, and likewise routers T3 and destination B for checksum S3. Routers R1 and R2 also are responsible for checking and incrementally updating the Routing Header checksum. Since the Routing Header should also be invariant for a particular flow for a given part of the path, the same optimization could also be performed for its checksum. Given this, perhaps it makes sense to merge the two checksums into one covering both the base IPv6 header and the Routing Header, and possibly also the Hop-By-Hop Options Header, which is also supposed to be invariant for a particular flow. Actually, the IPv6 Specification states that: "All packets sent with the same Source Address and same non-zero Flow ID must also be originated with the same Destination Address, same Hop-by- Hop Options header contents (if present), and same Routing header contents (if present). The routers or destinations are permitted, but not required, to verify that this condition is satisfied." If the IPv6 header checksum did in fact cover the Version, Flow Label, Source and Destination Address fields of the base IPv6 header, plus the Routing Header and Hop-By-Hop Options Header, then it would be an extremely quick, very efficient way of checking that this condition was satisfied, i.e. by a single compare of the IPv6 header checksum in the packet against the checksum value cached for the flow (set when processing the first packet in the flow). Your suggestion that: "An intermediate relay can thus cache the flow/source/dest tuple. When processing a packet, it can look at this cache, detect a mismatch, and an error." is something I had not fully considered or thought through before, and may in fact go a long ways toward addressing the most serious concerns I had about the different failure scenarios I raised. Using a header checksum is more efficient than checking the header fields directly since you don't need to check as many bytes. However, if the header checksum only covers the Version, Flow Label, and Source and Destination Address fields of the base IPv6 header, then you're only saving on comparing 2 bytes (the checksum) versus 16 bytes (the Destination Address) since it would already have been necessary to compare against the Version, Flow Label, and Source Address fields. However, if you also want to verify the Routing Header and Hop-By-Hop Options Header with the IPv6 header checksum, then the checksum approach could be a major win over directly checking all the information in these headers. [After rereading my message preparing to send it out, I realized there was a flaw in my argument above. In the example I gave above, it is in fact possible that transit router T2 = T1, i.e. transit router T1 might be in both the A:R1 and R1:R2 portions of the source routed path A:R1:R2:B. To allow for this possibility, it is required to check the Destination Address in addition to the Source Address and Flow Label to distinguish the two different "parts" of the flow. This eliminates any efficiency advantage of caching the header checksum approach over Christian's suggestion of simply caching the flow/source/dest tuple for the flow, at least for the case where the header checksum only covers the Version, Flow Label, and Source and Destination Address fields of the base IPv6 header. There could still be a win if the header checksum also covers the Routing Header and Hop-By-Hop Options Header.] > Now, what is the opinion of this list? Should a router destroy a packet if > the flow id is not null, and already cached for a different destination? I considered this question. This could happen either because the original source of the packet improperly changed the destination address or else the source address, flow label, or most likely the destination address was corrupted in transit. I'd say drop the packet in either case since either the source is behaving illegally or the packet is corrupt and we shouldn't forward corrupt packets. > What > ICMP code shall we use? It should probably be a new type, something like Flow Error, with code Bad Destination Address. The current IPv6 Specification says to simply return a Parameter Problem error pointing to the high-order octet of the Flow ID field if this kind of discrepancy is discovered, but I think a more meaningful ICMP error should be returned, since there are likely to be other kinds of Flow Errors, and it should be possible to differentiate them. > Shall it keep the cache entry or remove it? That's a tough one. It could keep a count of "good" hits and "bad" hits (where the first packet is assumed good) and drop the cache entry if there were proportionally too many "bad" hits. Or it could just drop the cache entry unconditionally which might cause a performance hit to the flow. > How long > shall a flow info be kept in a cache? That's also a tough one. As long as its active? Is there any reason not to allow a flow to last as long as it wants to? > Christian Huitema > PS. > I append a detailed analysis of your remarks. > > 1) Multicast group ID corruption: > > The address space for multicast groups is very sparse. That a random error > transforms one valid group is unlikely - in fact, one can estimate that the > probability of this occuring is less than having a random checksum being > right. The "major traffic impact" only occurs if this error is repeated > consistently. Such errors are more likely to be caused by a misbehaving > source, sending to the wrong group, or by a misbehaving router, incorrectly > rewriting the header. A header checksum would not help. This is one of the cases I was most worried about. I agree that a header checksum would not help for a misbehaving source, although it would insure that the source address was correct to be able to track down the misbehaving source. However, as described earlier, it would help in the case of a misbehaving router, even one which was incorrectly rewriting the header, by allowing a downstream router to detect the error in many cases and drop the packets, thus preventing them from being further propagated. If we are going to rely on the sparseness of the address space for multicast groups for protection, then do we need to specify in the IPng Addressing Architecture document that "transient" multicast addresses MUST be assigned randomly and uniformly across the entire 14 byte Group ID space? And what about "well-known" multicast addresses? These will likely not be assigned randomly or sparsely. And will there be an allocation hierarchy for "well-known" multicast addresses as there currently is one defined for unicast addresses? I suspect there will have to be to avoid a centralized FCC. This allocation structure may significantly reduce the sparsity and randomness of multicast addresses. What if the "well-known" multicast addresses for CNN and MTV just happen to be off by one bit somewhere, and a multicast router sets or drops that bit fairly consistently due to some kind of hardware error? > 2. Multicast scope corruption > > Similar problem to previous one. In fact, this has to be analysed in > conjonction with multicast routing algorithms. Sparse-mode PIM, for example, > has implicit protection. I agree this is similar to the previous one, although since it is recognized that you can use the same "well-known" multicast address within different scope levels, the randomness/sparseness of the multicast address space doesn't help here at all if the multicast scope is increased by corruption. I also don't think we want our basic protection dependent on the multicast routing algorithms, since there may be many different ones, with varying degrees of protection (or are we going to mandate a particular one for an inter-domain multicast routing protocol?). > 3. Unicast destination address corruption > > A random error causes the misdelivery of one packet. This is an acceptable > risk, already taken into account by inclusion of a pseudo-error in TCP and UDP > checksum. As systematic error would probably not be caught by the header > checksum. I agree this is not a major concern. I only included it for completeness. > 4. Source address corruption > > Same analysis as (3). I also agree this is not a major concern. > 5. Flow ID corruption > > Again, you have to distinguish random errors, which affect isolated packets > and have acceptable consequences, from systematic errors, which would probably > not be caught by the header checksum. Note that the consequences of systematic > errors would depend a lot of what you use the flows for. You are quoting a > very extreme case. This was also one of my major concerns. You went a long way toward addressing my concerns with your suggestion of caching the source/flow/destination tuple for the first packet in a flow and checking subsequent packets in the flow against the cached values. One remaining concern is the randomness of the Flow ID. This is a key in avoiding collisions between unrelated flows that could be caused by corruption to the Source Address or Flow ID fields. Since this is set by the host, but of crucial importance to the health of the Internet, it is vital that hosts have very good implementations for randomizing the choice of Flow ID within the 24-bit Flow ID space. This has to be random both temporally and spatially. The next Flow ID that a particular host chooses should have no relationship to the previous Flow ID, and it is even more important that two unrelated hosts that choose Flow IDs at about the same time will wind up with two totally unrelated Flow IDs. > 6. Traffic class corruption > > This is very similar to Flow ID corruption. Same remarks apply. I agree it is similar to Flow ID corruption case, although randomness of Flow ID doesn't help here. > 7. Hop Limit corruption > > Random reduction causes a random packet loss, which is deemed acceptable. > Random increases will be a problem if occuring in conjunction with a network > loop. Systematic errors would indeed be a worse problem, but, again, the > likely cause is a software fault, e.g. failing to recognize 0 and count down > from 255. This will not be caught by a header checksum, as header checksum are > systematically recomputed after updating the hop count. If the Hop Limit were included in the header checksum, I suggested that routers must only incrementally upgrade the checksum to reflect the decrementing of the Hop Limit, and MUST NOT recompute the entire checksum. In this case, the routers would cache a "0-relative" (Hop Limit) checksum for a flow, and when comparing subsequent packet checksums against the cached "0-relative" checksum, they would first adjust the packet checksum by the packet Hop Limit to obtain a "0-relative" packet checksum. I considered this risk somewhere between the unicast cases and the multicast/flow cases. It may be an acceptable risk. The worst case only occurs in conjunction with other errors such as routing loops. > 8. Payload length and next header corruption > > As you note, this is mostly an end-to-end problem. Code have to be robust. I agree. > 9. Routing header and hop-by-hop options header corruption > > A header checksum would not help in the case of the "routing header". The very > design of IPv6 is "intermediate" routers will not even look at the routing > header. You cannot expect them to compute a checksum over the routing header > payload. You may want to consider a checksum of the routing header > itself. There is however an implicit protection through the fixed relation > between flow-id and routing header - same flow should imply same loose route. If you followed my previous discussion, then the scheme I suggested for the header checksum could also protect the Routing Header and Hop-By-Hop Options Header (for flows which is one of my biggest concerns). [another rereading comment: considering the previous rereading comment, a separate Routing Header checksum might be cleanest, and the source routers which are members of the source route list could still use the basic optimization I described for the case of flows, i.e. cache the Routing Header checksums (both input and output sides) for the first packet in a flow and then simply compare or set the Routing Header checksum in the packet for all subsequent packets belonging to that flow as they arrive at the source router or are forwarded on by the source router to the next destination in the source router. The Routing Header checksums would of course be transparent to any transit routers which weren't members of the source route list.] The level of risk here introduced by undetected corruption of the Routing Header is not at all clear to me. > 10. Corruption to fragment header, authentication header, end-to-end options > header > > This is an end-to-end problem, to be catched by end-to-end solutions. I agree. Finally, one last problem I didn't point out earlier with undetected packet corruption is in making network management harder because it is possible to receive bogus ICMP errors that could cause a network manager to misdiagnose an error because the error being reported was instigated by a packet being corrupted which in turn caused a bogus error fault, and of course there might be no visible indication of the corruption of the original packet in the ICMP error message that is received. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 07:39:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21881; Fri, 10 Mar 95 07:39:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21875; Fri, 10 Mar 95 07:39:44 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20271; Fri, 10 Mar 1995 07:31:23 -0800 Received: from zephyr.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA16840; Fri, 10 Mar 95 07:31:17 PST Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Fri, 10 Mar 1995 07:31:16 -0800 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199503101531.AA29018@zephyr.isi.edu> Subject: (IPng) PTR mappings To: ipng@sunroof.Eng.Sun.COM Date: Fri, 10 Mar 1995 07:31:16 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM What was the results of the discussion... Are we goign to proceed w/ ICMP or what? Is there something else other than the B.Simpson RR(tm) draft? *RR - Rapid Return - Internet drafts while U wait. -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 07:58:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21894; Fri, 10 Mar 95 07:58:22 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21888; Fri, 10 Mar 95 07:58:15 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id HAA26380; Fri, 10 Mar 1995 07:48:28 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id HAA03485; Fri, 10 Mar 1995 07:48:16 -0800 Date: Fri, 10 Mar 1995 07:48:16 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503101548.HAA03485@elrond.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net, atkinson@itd.nrl.navy.mil Subject: Re: (IPng) in-band key mgmt, IPV6, export issues, DES hardware X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From rja@bodhi.itd.nrl.navy.mil Fri Mar 10 06:22:03 1995 > To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net > Subject: Re: (IPng) in-band key mgmt, IPV6, export issues, DES hardware > Mime-Version: 1.0 > > Folks, > > 1) The IPv6 specs do NOT "clearly state that in-band cannot be used > for IPv6". > > The IPv6 specs merely state that the IPv6 security specs were "not > intended for use with in-band" key management. In-band clearly works > as has been described by Ted T'so and others. Even the in-band > advocates believe that it will using the technique that Ted has > described. Within an IETF spec, things that are not explicitly > prohibited using "MUST NOT" language are permitted. There is no > language that I am aware of that says one "MUST NOT" use in-band key > management or even says one "SHOULD NOT" use in-band key management. > There is a difference between what the designer intended and what > is possible and permitted. Ran, Given your agreement that IPv6 can be used to support in-band keying, what is your objection to removing the paragraph that states it is "not intended" to do so? Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 08:16:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21910; Fri, 10 Mar 95 08:16:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21904; Fri, 10 Mar 95 08:15:00 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22243; Fri, 10 Mar 1995 08:05:46 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA20566; Fri, 10 Mar 95 08:05:25 PST From: Ran Atkinson Message-Id: <9503100859.ZM2880@bodhi.itd.nrl.navy.mil> Date: Fri, 10 Mar 1995 08:59:58 -0500 References: <199503100448.AA22824@interlock.ans.net> X-Mailer: Z-Mail (3.0.0 15dec93) To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) in-band key mgmt, IPV6, export issues, DES hardware Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, 1) The IPv6 specs do NOT "clearly state that in-band cannot be used for IPv6". The IPv6 specs merely state that the IPv6 security specs were "not intended for use with in-band" key management. In-band clearly works as has been described by Ted T'so and others. Even the in-band advocates believe that it will using the technique that Ted has described. Within an IETF spec, things that are not explicitly prohibited using "MUST NOT" language are permitted. There is no language that I am aware of that says one "MUST NOT" use in-band key management or even says one "SHOULD NOT" use in-band key management. There is a difference between what the designer intended and what is possible and permitted. 2) With regard to the export issues, I can provide some data, but I don't have any legal answers (I'm not a lawyer :-) : I am not an expert on laws in any country, but I have been told repeatedly by folks in France that French law prohibits all USE of all encryption algorithms even by French citizens within France (except under special circumstances where the user has prior permission from the French government). I mention France only to provide a specific example. There are probably other countries at least this restrictive in their laws and regulations. This not withstanding, it is widely known that certain anonymous ftp sites in Finland make DES and other encryption algorithm source code freely available with no technical restrictions on access from outside Finland. I do not know if Finnish law regulates exports or not, but in practice those systems will de facto permit downloading to anyplace on the net. It is my understanding that someone from TIS actually demonstrated this fact to the US Congress during hearings sometime in the past several years (Steve Crocker probably knows the details on this). At least one major router vendor (i.e. Network Systems) now has DES encryption of IP traffic as a commercially available option. They use a hybrid Diffie-Hellman key mgmt technique. This to me indicates that they believe they have a business case to sell such an option. Other businesses might well decide they do not have such a business case. 3) I have some data on DES hardware that some might find interesting and so I'll pass it along for information. This is not and must not be misconstrued as an endorsement of any vendors product : Digital Equipment Corporation made a demonstration to the IPsec working group at the Columbus IETF meeting of fast DES encryption hardware that they were designing/manufacturing in Israel and then exporting to various countries (including the US). If I understood the DEC people correctly, one reason for selecting Israel was that it was less restrictive than the US about exports of DES hardware. I do not recall exactly how fast the DEC DES chip is, but I think it was over 100 Mbps. By the way, the US firm "VLSI Technology" reportedly also has a commercially available DES chip that will process hundreds of megabits per second. I have not actually seen or used such a chip, so this might be vaporware. There might also be other vendors of similar products that I am not aware of at this time. I do not endorse any particular vendors product. I am just trying to note that fast DES encryption appears commercially implementable. I would be interested to hear about any MD5 or SHA hardware that is/will-be commercially available. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 08:37:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21957; Fri, 10 Mar 95 08:37:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21951; Fri, 10 Mar 95 08:37:01 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24862; Fri, 10 Mar 1995 08:29:34 -0800 Received: from wintermute.imsi.com ([192.103.3.10]) by Sun.COM (sun-barr.Sun.COM) id AA25751; Fri, 10 Mar 95 08:29:20 PST Received: from relay.imsi.com by wintermute.imsi.com id LAA00499; Fri, 10 Mar 1995 11:27:49 -0500 Received: from snark.imsi.com by relay.imsi.com id LAA11123; Fri, 10 Mar 1995 11:27:48 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA26736; Fri, 10 Mar 95 11:27:47 EST Message-Id: <9503101627.AA26736@snark.imsi.com> To: Danny.Nessett@Eng (Dan Nessett) Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net, atkinson@itd.nrl.navy.mil Subject: Re: (IPng) in-band key mgmt, IPV6, export issues, DES hardware In-Reply-To: Your message of "Fri, 10 Mar 1995 07:48:16 PST." <199503101548.HAA03485@elrond.Eng.Sun.COM> X-Reposting-Policy: redistribute only with permission Date: Fri, 10 Mar 1995 11:27:47 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan Nessett says: > Ran, > > Given your agreement that IPv6 can be used to support in-band keying, what > is your objection to removing the paragraph that states it is "not intended" > to do so? The designers want it to be clear what their intent was. I, for one, object to any proposal to eliminate information on that intent from the documents. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 08:45:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21973; Fri, 10 Mar 95 08:45:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21967; Fri, 10 Mar 95 08:45:39 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25572; Fri, 10 Mar 1995 08:38:12 -0800 Received: from wintermute.imsi.com ([192.103.3.10]) by Sun.COM (sun-barr.Sun.COM) id AA28036; Fri, 10 Mar 95 08:37:54 PST Received: from relay.imsi.com by wintermute.imsi.com id KAA00388; Fri, 10 Mar 1995 10:56:59 -0500 Received: from snark.imsi.com by relay.imsi.com id KAA10837; Fri, 10 Mar 1995 10:56:56 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA26675; Fri, 10 Mar 95 10:56:55 EST Message-Id: <9503101556.AA26675@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipsec@ans.net, bound@zk3.dec.com Subject: Re: (IPng) Proposed message on perfect forward security In-Reply-To: Your message of "Tue, 07 Mar 1995 15:02:53 EST." <9503072002.AA28302@xirtlu.zk3.dec.com> X-Reposting-Policy: redistribute only with permission Date: Fri, 10 Mar 1995 10:56:54 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM bound@zk3.dec.com says: > I will also add that ESP requires DES. Could we select an encryption > algorithm that has no export restrictions any where in the world. Sure. Use ROT13. There is *no* cryptographic algorithm with is of any use that is acceptable to all governments on earth. I oppose the evisceration of critical internet technologies to appease the short-sighted paranoiacs working for some governments. (Did you know that Pakistan just banned the use of cellphones because their secret police find they are too much of a pain to trace?) I say that we simply behave like engineers and design the best system we can, and leave it to the governments to cripple their own countries by making it impossible for their citizenry to join the internet, or by leaving their citizens open to massive fraud and invasion of privacy. I will not lend my support to a consensus for anything less than the best system I know how to design, and I suspect that others feel the same way. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 09:11:01 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22010; Fri, 10 Mar 95 09:11:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21924; Fri, 10 Mar 95 08:28:16 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23965; Fri, 10 Mar 1995 08:20:50 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA24189; Fri, 10 Mar 95 08:20:48 PST From: Ran Atkinson , Ran Atkinson Message-Id: <9503101118.ZM2959@bodhi.itd.nrl.navy.mil> Date: Fri, 10 Mar 1995 11:18:11 -0500 X-Mailer: Z-Mail (3.0.0 15dec93) To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) minor edit to IPv6 Sec Arch draft Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, In order to increase clarity of the current spec, I have added the following sentence to the end of the paragraph entitled "4. Key Management" in the offline master copy of the "IPv6 Security Architecture". "Mutually consenting systems may additionally use other key management approaches by private agreement." In order not to unduly burden the IETF Secretariat, the online version won't be updated today. I'm waiting for other editorial inputs from the Security AD before I update the online version. The online version WILL be updated far enough ahead of any Last Call so that people can actually see the change was actually made. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 09:13:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22022; Fri, 10 Mar 95 09:13:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21980; Fri, 10 Mar 95 08:55:06 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26211; Fri, 10 Mar 1995 08:46:33 -0800 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU) by Sun.COM (sun-barr.Sun.COM) id AA01146; Fri, 10 Mar 95 08:46:24 PST Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA18859; Fri, 10 Mar 95 11:46:22 EST Received: by dcl.MIT.EDU (5.0/4.7) id AA02465; Fri, 10 Mar 1995 11:46:22 +0500 Date: Fri, 10 Mar 1995 11:46:22 +0500 From: Theodore Ts'o Message-Id: <9503101646.AA02465@dcl.MIT.EDU> To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net, bound@zk3.dec.com In-Reply-To: bound@zk3.dec.com's message of Tue, 07 Mar 95 15:02:53 -0500, <199503100448.AA22824@interlock.ans.net> Subject: Re: (IPng) Proposed message on perfect forward security Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Tue, 07 Mar 95 15:02:53 -0500 From: bound@zk3.dec.com I will also add that ESP requires DES. Could we select an encryption algorithm that has no export restrictions any where in the world. No --- there's no such thing. Well, maybe ROT-13 counts, but technically you still need an export license for it. (Pathetically weak systems like DES with 40 bit keys fall in the same category as ROT-13, for all intents and purposes). This issue has been talked to death many times before, in many different forums. In all such forums that I recall within the IETF, the consensus that has always been reached is that we should design the best system we can, regardless of export issues --- and if certain world governments want to restrict the ability of their companies to compete in the global marketplace, that's those government's business. If we want to avoid export hassles altogether, the only way to do that is to punt on encryption altogether --- and I think we've all agreed that protecting data confidentialty is a good thing. Do we really have to open this for discussion yet again? I really hope not.... - Ted ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 09:19:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22038; Fri, 10 Mar 95 09:19:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22032; Fri, 10 Mar 95 09:18:53 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28804; Fri, 10 Mar 1995 09:11:20 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA06273; Fri, 10 Mar 95 09:10:53 PST From: Ran Atkinson Message-Id: <9503101208.ZM3035@bodhi.itd.nrl.navy.mil> Date: Fri, 10 Mar 1995 12:08:16 -0500 In-Reply-To: Danny.Nessett@Eng.Sun.COM (Dan Nessett) "Re: (IPng) in-band key mgmt, IPV6, export issues, DES hardware" (Mar 10, 7:48) References: <199503101548.HAA03485@elrond.Eng.Sun.COM> X-Mailer: Z-Mail (3.0.0 15dec93) To: ipng@sunroof2.Eng.Sun.COM Subject: Re: (IPng) in-band key mgmt Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan, The designer of IPv6 security never intended for IPv6 to be used with in-band keying. The paragraph will remain as it is entirely factual. Please do note my brief email of earlier today. Ran ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 09:54:26 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22127; Fri, 10 Mar 95 09:54:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22121; Fri, 10 Mar 95 09:54:19 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03288; Fri, 10 Mar 1995 09:46:52 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA15535; Fri, 10 Mar 95 09:45:41 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/24Feb95) id AA18831; Fri, 10 Mar 95 09:25:08 -0800 Received: by xirtlu.zk3.dec.com; id AA08231; Fri, 10 Mar 1995 12:23:49 -0500 Message-Id: <9503101723.AA08231@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipsec@ans.net, bound@zk3.dec.com Subject: Re: (IPng) Proposed message on perfect forward security In-Reply-To: Your message of "Fri, 10 Mar 95 10:56:54 EST." <9503101556.AA26675@snark.imsi.com> Date: Fri, 10 Mar 95 12:23:44 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry, bound@zk3.dec.com says: > I will also add that ESP requires DES. Could we select an encryption > algorithm that has no export restrictions any where in the world. >I oppose the evisceration of critical internet technologies to appease >the short-sighted paranoiacs working for some governments. (Did you >know that Pakistan just banned the use of cellphones because their >secret police find they are too much of a pain to trace?) I am not a paranoiac and object to your tone again. It was a question dude. Lighten up. Ran answered it just fine. >I say that we simply behave like engineers and design the best system >we can, and leave it to the governments to cripple their own countries >by making it impossible for their citizenry to join the internet, or >by leaving their citizens open to massive fraud and invasion of >privacy. I will not lend my support to a consensus for anything less >than the best system I know how to design, and I suspect that others >feel the same way. I see no consensus that you keep saying with phrases like "I suspect that others feel the same way". I do see one hand clapping. Nothing you can say will convince me of not wanting the option of in-band keying in the spec. Because I believe it should be a technology option I as an engineer may build in my products, for the explicit reasons Dan has described consistently. In addition I agree with Dan that the present wording that in-band is not recommended is wrong. I with Dan and others will object at last call to that wording in the document if it is to go to proposed standards before Danvers MA. Done!, and as far as I am concerned there is no consensus to support your views technically on any of the security subjects discussed in this rather extensive mail exchange. You have a view and others have a different view. Your not winning the debate your just sending a lot of mail. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 09:55:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22160; Fri, 10 Mar 95 09:55:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22154; Fri, 10 Mar 95 09:55:14 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03332; Fri, 10 Mar 1995 09:47:47 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA15937; Fri, 10 Mar 95 09:47:14 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/24Feb95) id AA19096; Fri, 10 Mar 95 09:30:21 -0800 Received: by xirtlu.zk3.dec.com; id AA08452; Fri, 10 Mar 1995 12:29:03 -0500 Message-Id: <9503101729.AA08452@xirtlu.zk3.dec.com> To: perry@imsi.com Cc: Danny.Nessett@Eng (Dan Nessett), ipng@sunroof.Eng.Sun.COM, ipsec@ans.net, atkinson@itd.nrl.navy.mil, bound@zk3.dec.com Subject: Re: (IPng) in-band key mgmt, IPV6, export issues, DES hardware In-Reply-To: Your message of "Fri, 10 Mar 95 11:27:47 EST." <199503101629.AA27559@interlock.ans.net> Date: Fri, 10 Mar 95 12:28:56 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Dan Nessett says: >> Ran, >> >> Given your agreement that IPv6 can be used to support in-band keying, what >> is your objection to removing the paragraph that states it is "not intended" >> to do so? > >The designers want it to be clear what their intent was. I, for one, >object to any proposal to eliminate information on that intent from >the documents. > >Perry Perry, Would you give Ran a chance to respond to Dan's mail and be a little courteous. Maybe we can reach a compromise and move forward. Your input is beginning to make me think your being emotional and not logical as an engineer. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 12:54:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22486; Fri, 10 Mar 95 12:54:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22480; Fri, 10 Mar 95 12:54:33 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24890; Fri, 10 Mar 1995 12:47:07 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA29857; Fri, 10 Mar 95 12:47:02 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA24891; Fri, 10 Mar 95 15:47:01 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503102047.AA24891@wizard.gsfc.nasa.gov> Subject: Re: (IPng) WG last call: v6 ICMP draft To: ipng@sunroof.Eng.Sun.COM Date: Fri, 10 Mar 1995 15:47:00 -0500 (EST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alex, Regarding my current concern about the selection of the source address to use for generating an ICMP error message in the case of time limit exceeded, hop limit exceeded (which is used by traceroute), perhaps my wording alone was not sufficiently clear to explain the difference between the original IPv6 ICMP spec and the change I was suggesting. Maybe the following example will help clarify matters. Suppose a source A wants to send a packet to host E, and that the path from A to E includes the transit routers B, C, and D, as illustrated in the following diagram: A -> B1 B B2 -> C1 C C2 -> D1 D D2 -> E /|\ B3 C3 D3 / | \ | | | + | +----F | | | | | | | | | | | +------------------G | | | | | +--------------------------------H B1, B2, B3, C1, C2, C3, D1, D2, and D3 represent interfaces on routers B, C, and D. The data path from A to E is A->B->C->D->E. The path for ICMP error packets from B back to A is B->F->A. The path for ICMP error packets from C back to A is C->G->A. The path for ICMP error packets from D back to A is D->H->A. If a traceroute were done from A to E: 1. The original IPv6 ICMP spec would return the route: B3, C3, D3, E This represents the return paths from the transit routers taken by the ICMP error packets and definitely is not what is desired. 2. If the new wording that indicates: "If the message is a response to a packet forwarding action that cannot complete successfully, the Source Address must be a unicast address belonging to the interface on which the packet forwarding failed." were interpreted to cover the case of hop limit exceeded, then it could be argued that the interface selected to set the source address of the ICMP error packet should be the output interface that would have been used had the hop limit not reached zero. If that interpretation were followed, then traceroute would return the route: B2, C2, D2, E This is also not the desired behavior. 3. My suggested change was to pick the input interface that the original packet arrived on that caused the ICMP hop limit exceeded error message to be generated as the interface to be used for setting the source address of the ICMP error packet. If this is done, then traceroute would return the route: B1, C1, D1, E This is the actual data path (relative to the source A) that packets from A to E would traverse, and thus this is the desired behavior. Of course, the return paths from the transit routers back to the source may happen to coincide with the forward data path, but we should insure that traceroute returns the most meaningful information possible in all cases, even when there is asymmetric routing between the source and any of the transit routers in the path between the source and the destination. We need some explicit language in the IPv6 ICMP spec to make it absolutely clear how to pick the source address for the ICMP hop limit exceeded error message. For anyone who didn't grok my earlier postings on this subject, I hope this helps clarify my technical issue with the current IPv6 ICMP spec regarding selection of the source address for generating ICMP error messages of type time limit exceeded, hop limit exceeded. -Thanks -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 13:23:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22632; Fri, 10 Mar 95 13:23:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22625; Fri, 10 Mar 95 13:22:52 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27424; Fri, 10 Mar 1995 13:15:23 -0800 Received: from VNET.IBM.COM by Sun.COM (sun-barr.Sun.COM) id AA00732; Fri, 10 Mar 95 13:15:21 PST Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 2731; Fri, 10 Mar 95 15:34:24 EST Received: by RTP (XAGENTA 4.0) id 5837; Fri, 10 Mar 1995 15:33:43 -0500 Received: by wchung.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA08705; Fri, 10 Mar 1995 15:34:37 -0500 Message-Id: <9503102034.AA08705@wchung.raleigh.ibm.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Base IPv6 Specification: Robust Service vs Lack of Header Checksum In-Reply-To: (Your message of Fri, 10 Mar 95 02:09:21 EST.) <9503100709.AA23667@wizard.gsfc.nasa.gov> Date: Fri, 10 Mar 95 15:34:36 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM It seems to me that the issue Bill Fink raises can be summed up as: "What is the probability that a mangled packet will be improperly processed by a router"? Christian (and the group as a whole) argue that the probability is low because of the sparseness of flow labels & address bits. Bill then goes on to argue that a checksum is needed to make the probability acceptably low. The essential issue here seems to concern "cache keys", the bits a router extracts from the packet header to locate the state associated with the packet's flow label. Bill's "checksum" actually does the following: it increases the size of the "cache key" and guarantees that cache keys have a certain structure (that routers can verify if they choose). In particular, making a checksum algorithm an explicit part of key generation allows one to generate "cache keys" with a known Hamming Distance. That is, knowing the precise number of bits that would have to be changed (corrupted) before one legal "cache key" gets converted into another. I note that the draft specs talk about flow labels being chosen from a "uniform" distribution. This is done not for Hamming Distance purposes, but to allow a router to use any subset of the flow label bits as a hash key. I think it makes sense to consider the use of flow label generation algorithms that address both concerns. Note that it is NOT enough to look at the flow label part of the key alone. You want the entire "cache key" to have a good Hamming Distance. Since the source (and maybe destination) address is part of the "cache key", you have to look at its structure too (its highly structured in practice). The standard Internet checksum algorithm has a Hamming distance of only 2, which is pretty weak (e.g., it adds less protection than many folks realize). So if one really thinks a checksum is needed, a better algorithm could probably be found that uses fewer check bits (maybe 4??). Even if it were relatively expensive (compared with the Internet checksum), the computation is performed infrequently. It may well be worth specifying the exact algorithm hosts use to generate flow labels. The network ASSUMES that "cache keys" have "good" structure, but what can it do if hosts violate that assumption (some will), causing problems in practice (it might)? Specifying the exact algorithm for generating flow labels would at least leave open the OPTION that routers reject poorly-chosen flow labels should the need arise in the future. Of course, this leads to the question of what an appropriate Hamming Distance should be. Has anyone made a case for specific numbers? From what I've picked up in the draft specs, this issue is not addressed. Also, just how big does the flow label field need to be? It is currently 24 bits. Would it be enough if (say) 20 bits were chosen by the host, and the remaining 4 used for a checksum? What about 16/8? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 14:30:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22738; Fri, 10 Mar 95 14:30:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22732; Fri, 10 Mar 95 14:29:57 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03024; Fri, 10 Mar 1995 14:22:31 -0800 Received: from amdext.amd.com by Sun.COM (sun-barr.Sun.COM) id AA01747; Fri, 10 Mar 95 14:22:17 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA13408 (5.67a/IDA-1.5+AMD for ); Fri, 10 Mar 1995 13:46:16 -0800 Received: from brahms.amd.com by amdint.amd.com with SMTP id AA11258 (5.67a/IDA-1.5+AMD for ); Fri, 10 Mar 1995 13:46:15 -0800 Received: from angelo.amd.com by brahms.amd.com (4.1/AMDSN-1.18) id AA04104; Fri, 10 Mar 95 13:45:39 PST Received: by angelo.amd.com (4.1/AMDC-1.18) id AA02154; Fri, 10 Mar 95 13:46:12 PST From: David.Roberts@amd.com (Dave Roberts) Message-Id: <9503102146.AA02154@angelo.amd.com> Subject: Re: (IPng) Proposed message on perfect forward security To: ipng@sunroof.Eng.Sun.COM Date: Fri, 10 Mar 1995 13:46:12 -0800 (PST) In-Reply-To: <9503072002.AA28302@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Mar 7, 95 03:02:53 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I will also add that ESP requires DES. Could we select an encryption > algorithm that has no export restrictions any where in the world. Also for > companies doing development internationally where engineers on teams are > located in different geographical locations it makes it tough on software > planning. For example I would not be able to give one of my engineering > colleagues DES code from the U.S., if they were working in the Ural > Mountains doing the IPv6 ESP Security work on my project. This kind of > bugs me. Another one for IPSEC I think. Hmmm... do you want real security with that algorithm as well? There are those of us who summarize the current US export restrictions as, "If it's good, it can't be exported." Anyway, I just wanted to point out that with the current regulations the way they are, it's impossible to satisfy both requests, good security and exportable. Note that this doesn't mean that you can't exchange encrypted info, however. It's legal for an encrypted packet to transit into and out of US cyberspace, just not the encryption algorithm implementation, as far as I know. Thus, if your friends were capable of either writing their own code or using a different implementation, that's fine. Dave Roberts Advanced Micro Devices, Inc. I/O and Network Products Division david.roberts@amd.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 15:20:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22892; Fri, 10 Mar 95 15:20:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22886; Fri, 10 Mar 95 15:20:35 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10120; Fri, 10 Mar 1995 15:13:09 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA15489; Fri, 10 Mar 95 15:12:42 PST Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA26771; Fri, 10 Mar 1995 17:14:39 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA01143; Fri, 10 Mar 1995 17:14:29 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA11296; Fri, 10 Mar 1995 16:50:24 -0500 Message-Id: <9503102150.AA11296@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) WG last call: v6 ICMP draft In-Reply-To: Your message of "Thu, 09 Mar 95 16:20:55 EST." <9503092120.AA23007@wizard.gsfc.nasa.gov> Date: Fri, 10 Mar 95 16:50:24 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: bill@wizard.gsfc.nasa.gov (Bill Fink) Subject: Re: (IPng) WG last call: v6 ICMP draft Alex, Thanks for your response. Most of my concerns have been addressed with one important exception, which concerns selection of the source address for ICMP error packets of the type time exceeded, code hop limit exceeded, because of the critical importance to traceroute (see my comments below). -Bill Bill, I appreciate the attention you give to the ICMP document. I thought the changes made resolve the Source Address selection issues you had. Let me take another look at the document, and answer one by one your remaining isses. Thanks, Alex > > The text is correct as is. The type of "destination unreachable" referred t ***o > cannot be generated by the "destination node", since the "destination" node > would have no reason to generate such an ICMP message - the packet reached > its destination node. Huh? I still don't understand this. The type of "destination unreachable" being talked about at this point is not specified. This is the first paragraph immediately following the IPv6 ICMP Fields section, which simply lists all possible "destination unreachable" codes, "port unreachable" being one of the possible codes. Certainly, "port unreachable" may be generated by the destination node, and that's what I thought that part of the sentence was referring to, while the first part of the sentence covered the router case. Could you please elaborate. Of course. The text you refer to is: "A Destination Unreachable message SHOULD be generated by a router, or by the IPv6 layer in the originating node, in response to a packet that cannot be delivered to its destination address for reasons other ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ than congestion." The portion of text marked ^^^^^ referrs to delivery of packets to nodes, as opposed to delivery of packets to end-points of communication, or in other words demultiplexing at transport level port number, which is the case of 'port unreachable'. > Path MTU includes the tunnel Path MTU, so the originating node is informed > about the PMTU as many times as needed until the size of the packet is such *** > that no ICMP Packet Too Big is being generated on the packet's path, includ ***ing > the tunnel. The encapsulating node converts ICMP messages from inside the > tunnel to ICMP messages sent to the originating node, passing the correct P ***MTU > information in the ICMP message. Is it ever allowed to encapsulate ICMP error packets rather than converting them at a tunnel boundary? I would think not. If this is indeed the case, should we explicitly mention anywhere that ICMP error packets MUST NOT ever be encapsulated. No, I do not think the ICMP specifications should say that, it would be beyond its scope. In any case, what was discussed - tunnel ICMP messages - is not a case of pure encapsulation, or decapsulation. Yes, the encapsulating node - tunnel-entry - must decapsulate the payload of the ICMP message received fromwithin the tunnel, for generating the ICMP message to the packet originator, but again the ICMP message sent to the packet originator is not just a decapsulation of the ICMP message received from inside the tunnel. That's why I used the term 'convert'. > > ... > > Thanks. > > I think in 2., entirely or parially, A & B & F coincide with the source > address selection mechanism specified in the IPv6 ICMP document. The A case, time exceeded, hop limit exceeded, was completely different and is the one I am most concerned about since it is what is used by traceroute, which is one of the most critically important network troubleshooting tools available.... I think you are raising a valid concern, which is addressed by the ICMP specifications in the limits of its scope. The text added in the ICMP specification which is: (c) If the message is a response to a packet forwarding action that cannot complete successfully, the Source Address must be a unicast address belonging to the interface on which the packet forwarding failed. is addressing the issue related to 'traceoute' in that a router must check if the packet can be forwarded before it switches to the outgoing interface. So a router would detect the forwarding failure while still having a pointer to the receiving interface, and so the Source Address of the ICMP message is one of the IPv6 addresses of that interface. Additional text in the ICMP specifications related to traceroute will in my view exceed the scope of the document, which is not intended. .... As far as B and F.... .... No critical information is lost with the original IPv6 ICMP spec, but I still feel the suggested change is cleaner. Thanks for your suggestion. I agree that your text may be cleaner for the particular case you looked at. Our experience is that as we tried to make the text cleaner for each of the possible cases, it got more and more complex, loosing its simplicity and flexibility. I think that the document is at a stage where it provides a good balance of clarity, simplicity, and flexibility, which I am very afraid of disturbing by adding more text. > The suggestion in 2., C & D & E, has been included as it follows: > > If the message is a response to a packet forwarding action that cannot > complete successfully, the Source Address must be a unicast address belongi ***ng > to the interface on which the packet forwarding failed. For C (destination unreachable, communication administratively prohibited), D (destination unreachable, address unreachable), and E (packet too big), and as long as it is made clear that this does not apply to A (time exceeded, hop limit exceeded), this wording is fine. The wording would be ambiguous or wrong for the A case, since it would not be clear whether the referenced interface was the input interface or the output interface, and we need to make it explicit that the input interface MUST be chosen for the source address selection in the A case (for traceroute). Thanks for your comments on this. I think the wording is an attempt to simplicity and flexibility, while providing the solution. As I said before, because of a fine balance, and because the danger of exceeding the scope, I would prefer to leave the text as is. > .... I note that you did not respond to either my item 4 (regarding unnumbered interfaces on a router as it relates to selection of a source address for ICMP packets) or my item 5 (regarding timer-based rate limiting of ICMP packets). I am sorry, I must have thought of responding, but just got involved with the other issues which looked perhaps more important. My thought on this is that with autoconfiguration and configuration practically there are no 'unnumbered interfaces'. The ICMP packet sending limit paramaters are suggestions for default values for configurable parameters. > 3. In the Description section of Section 3.1 on page 7, > the part that says "by the IPv6 layer in the > originating node" should say "receiving node". > > Thanks. The text is correct as is - explained in previous response. See earlier comments. This is still valid - see comment #1. Thanks. > ... I note that you did not respond to my item 6 (regarding confusion concerning upper layer notification when an Echo Request originated in the IP layer). There are various documents that suggest cases in which Echo requests may be consequence of IP layer initiation rather than an Echo request/reply tool activated by a user. The referrence is to that type of Echo requests. Thanks, Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 16:37:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23012; Fri, 10 Mar 95 16:37:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23006; Fri, 10 Mar 95 16:37:51 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18969; Fri, 10 Mar 1995 16:30:22 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA02272; Fri, 10 Mar 95 16:30:01 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA25266; Fri, 10 Mar 95 19:29:57 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503110029.AA25266@wizard.gsfc.nasa.gov> Subject: Re: (IPng) WG last call: v6 ICMP draft To: ipng@sunroof.Eng.Sun.COM Date: Fri, 10 Mar 1995 19:29:57 -0500 (EST) Cc: conta@zk3.dec.com In-Reply-To: <9503102150.AA11296@brigit.zk3.dec.com> from "conta@zk3.dec.com" at Mar 10, 95 04:50:24 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alex, Thanks for the explanations and clarifications. You addressed almost all my concerns and questions. I'm making one more attempt to get a sentence added to remove what I feel is still some potential ambiguity in the interpretation of the section relating to source address selection for ICMP packets as it relates to hop limit exceeded ICMP errors (see below). -Bill > > I think in 2., entirely or parially, A & B & F coincide with the source > > address selection mechanism specified in the IPv6 ICMP document. > > The A case, time exceeded, hop limit exceeded, was completely different > and is the one I am most concerned about since it is what is used by > traceroute, which is one of the most critically important network > troubleshooting tools available.... > > I think you are raising a valid concern, which is addressed by the ICMP > specifications in the limits of its scope. > > The text added in the ICMP specification which is: > > (c) If the message is a response to a packet forwarding action that > cannot complete successfully, the Source Address must be a > unicast address belonging to the interface on which the packet > forwarding failed. > > is addressing the issue related to 'traceoute' in that a router must check > if the packet can be forwarded before it switches to the outgoing interface. > So a router would detect the forwarding failure while still having a pointer > to the receiving interface, and so the Source Address of the ICMP message > is one of the IPv6 addresses of that interface. I understand what you are saying and believe that it is the correct interpretation of (c), which is cleanly and succinctly phrased. However, I am worried that in the case of hop limit exceeded, this is a fairly subtle point, and not all implementors reading (c) will necessarily arrive at this correct interpretation. I would feel a whole lot more comfortable adding one more sentence to (c) which said something like: Note that for the case of the packet forwarding failing due to the hop limit being decremented to zero, the receiving interface is the one on which the packet forwarding is considered to have failed. This would remove any possible ambiguity. There is no possible ambiguity with any of the other types of packet forwarding failures. > Additional text in the ICMP specifications related to traceroute will in my > view exceed the scope of the document, which is not intended. I agree there should be no mention of traceroute in the ICMP spec. I did not mean to imply that there should be. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 17:24:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23083; Fri, 10 Mar 95 17:24:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23077; Fri, 10 Mar 95 17:24:41 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03909; Thu, 9 Mar 1995 11:52:01 -0800 Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA18281; Thu, 9 Mar 95 11:51:42 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id OAA07560 for ipng@sunroof.Eng.Sun.COM; Thu, 9 Mar 1995 14:54:18 -0500 (EST) Date: Thu, 9 Mar 1995 14:54:18 -0500 (EST) From: Scott Bradner Message-Id: <199503091954.OAA07560@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) WG last call: v6 ICMP draft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > It _only_ references Assigned Numbers. good Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 17:32:18 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23095; Fri, 10 Mar 95 17:32:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23089; Fri, 10 Mar 95 17:32:10 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24189; Fri, 10 Mar 1995 17:24:42 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA11135; Fri, 10 Mar 95 17:24:43 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm038-08.dialip.mich.net [141.211.7.112]) by merit.edu (8.6.10/merit-2.0) with SMTP id UAA26900; Fri, 10 Mar 1995 20:24:38 -0500 Date: Fri, 10 Mar 95 21:42:19 GMT From: "William Allen Simpson" Message-Id: <4229.bsimpson@morningstar.com> To: Francis Dupont Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) Re: All-Routers multicast address Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Francis Dupont > In draft-simpson-ipv6-discov-process-02.txt and > draft-simpson-ipv6-discov-formats-02.txt you > specify the All-Routers IPv6 Multicast Address > as FF02::3 and FFxx::2. Obviously it is not both... > Thanks for finding the nit. > PS: what is the good value (FF02::2) ? > Nope, FFxx::3, according to the addressing draft by Hinden. But, that might be a problem in _HIS_ fingers. RFC-1700 says 2! I'll raise it on the list. Could we have a little consistency between IPv6 and RFC-1700, please? Let's make 2 all-routers, and 3 all-hosts (3 is reserved in RFC-1700). Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 19:23:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23227; Fri, 10 Mar 95 19:23:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23209; Fri, 10 Mar 95 19:22:45 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB00089; Fri, 10 Mar 1995 19:15:18 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA22174; Fri, 10 Mar 95 19:15:19 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm037-12.dialip.mich.net [141.211.7.85]) by merit.edu (8.6.10/merit-2.0) with SMTP id WAA01306 for ; Fri, 10 Mar 1995 22:15:17 -0500 Date: Sat, 11 Mar 95 01:41:44 GMT From: "William Allen Simpson" Message-Id: <4234.Bill.Simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Encryption and ICMP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: bill@wizard.gsfc.nasa.gov (Bill Fink) > Will it be legal for routers to encrypt ICMP error messages? > Don't see why not. > E.g., if a transit router discovers there is no route to a destination, > is it legal for the router to encrypt the destination unreachable, no > route, ICMP error packet when it sends it back to the source of the problem > packet (this packet may then encounter some other error condition on its > way back to the original source which may require generation of another > ICMP error message which may in turn be encrypted, etc)? > Presumably, each has a Security Assosication with its ICMP Destination. Surely, this will all appear in the ICMP Security draft that Metzger is writing. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 19:23:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23229; Fri, 10 Mar 95 19:23:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23221; Fri, 10 Mar 95 19:22:52 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00101; Fri, 10 Mar 1995 19:15:25 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA22188; Fri, 10 Mar 95 19:15:27 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm037-12.dialip.mich.net [141.211.7.85]) by merit.edu (8.6.10/merit-2.0) with SMTP id WAA01313; Fri, 10 Mar 1995 22:15:21 -0500 Date: Sat, 11 Mar 95 01:55:53 GMT From: "William Allen Simpson" Message-Id: <4236.Bill.Simpson@um.cc.umich.edu> To: ipsec@ans.net Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) The best Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: bound@zk3.dec.com > >I say that we simply behave like engineers and design the best system > >we can, and leave it to the governments to cripple their own countries > >by making it impossible for their citizenry to join the internet, or > >by leaving their citizens open to massive fraud and invasion of > >privacy. I will not lend my support to a consensus for anything less > >than the best system I know how to design, and I suspect that others > >feel the same way. > > I see no consensus that you keep saying with phrases like "I suspect > that others feel the same way". I do see one hand clapping. > OK, Jim, here's agreement with Perry. I feel the same way. I didn't realise that any more than one person needed to say it. Oh, and I saw a message from Ted Ts'o saying the same. Multiple hands clapping. > I with Dan and others will object at last call to that wording in the > document if it is to go to proposed standards before Danvers MA. Done!, > and as far as I am concerned there is no consensus to support your views > technically on any of the security subjects discussed in this rather > extensive mail exchange. You have a view and others have a different > view. Your not winning the debate your just sending a lot of mail. > Perry is more attentive to replying to email than I am, particularly when I'm writing code, so he has a tendency to be the frontrunner. But you can rest assured, Mr Bound, that textual diarrhea is not one of Perry's problems. It is certain "opponents" that have spammed multiple lists, not Perry. The IPv6 Security formats have been completed for some time. They do not include key management. He and I and other have asked that IPv4 technical discourse, such as key management, continue on the IPSec list. Seems to me to be the pot calling the kettle black. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 19:23:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23228; Fri, 10 Mar 95 19:23:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23214; Fri, 10 Mar 95 19:22:47 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00093; Fri, 10 Mar 1995 19:15:20 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA22177; Fri, 10 Mar 95 19:15:21 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm037-12.dialip.mich.net [141.211.7.85]) by merit.edu (8.6.10/merit-2.0) with SMTP id WAA01309 for ; Fri, 10 Mar 1995 22:15:19 -0500 Date: Sat, 11 Mar 95 01:44:39 GMT From: "William Allen Simpson" Message-Id: <4235.Bill.Simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) ICMP limit exceeded Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: bill@wizard.gsfc.nasa.gov (Bill Fink) > The A case, time exceeded, hop limit exceeded, ... > suggested changing this to the address of the router corresponding to > the interface upon which the original packet was received that caused > the ICMP error message to be generated. These are not the same in the > case of asymmetric routing between the original source and the router > generating the ICMP error message, and the change I suggested is what > is required to make traceroute most meaningful. > Since when does traceroute work this way in IPv4? How is it less meaningful? One of the interfaces is learned. Sure, it may not be an interface that the normal packet would ever traverse, but who cares? You now know the node (which likely has the same FQDN for all of its addresses in any case). In many cases (code I've written), you don't know the interface it came in on when it's punted to ICMP. I keep it to the IP layer (need it for multicast routing), but not ICMP. ICMP just makes a message, and then passes it to the IP layer, which figures out the outgoing interface, and sets the Source. Anything else complicates the code too much. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 20:06:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23252; Fri, 10 Mar 95 20:06:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23246; Fri, 10 Mar 95 20:05:53 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01538; Fri, 10 Mar 1995 19:58:26 -0800 Received: from relay.tis.com by Sun.COM (sun-barr.Sun.COM) id AA25532; Fri, 10 Mar 95 19:58:25 PST Received: from mailhub.tis.com(192.33.112.100) by relay.tis.com via smap (a1.4) id sma010260; Fri Mar 10 22:57:03 1995 Received: from (illuminati.tis.com) by tis.com (4.1/SUN-5.64) id AA27461; Fri, 10 Mar 95 22:57:05 EST Received: by (4.1/illuminati) id AA16660; Fri, 10 Mar 95 23:02:30 EST From: "Marcus J. Ranum" Message-Id: <16660.9503110402@illuminati> Subject: (IPng) Re: The besty To: Bill.Simpson@um.cc.umich.edu (William Allen Simpson) Date: Fri, 10 Mar 1995 23:02:30 -0500 (EST) Cc: ipsec@ans.net, ipng@sunroof.Eng.Sun.COM In-Reply-To: <199503110315.AA30078@interlock.ans.net> from "William Allen Simpson" at Mar 11, 95 01:55:53 am Organization: Trusted Information Systems, Inc. Glenwood, MD Phone: 301-854-6889 Coredump: Infocalypse Now!!! Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> I see no consensus that you keep saying with phrases like "I suspect >> that others feel the same way". I do see one hand clapping. >> >OK, Jim, here's agreement with Perry. I feel the same way. I didn't >realise that any more than one person needed to say it. Ditto. I suppose I'll stand and be counted, too. BTW - unless I'm mistaken, Perry's main topic-of-rant was the notion of using exportable crypto instead of something like DES. Crypto policy being what it is, *ANY* encryption support for IP that is worth having will not be exportable. We need to accept that, and publish a relevant standard so that independent non-US iplementations can be developed without having to export code. mjr. [PS - Jim, if you're truly approaching this from the perspective of a vendor, why wait for the ossified standards process to complete its interminable gyrations? The only way to make things work is to ignore the standards community until it catches up, and make sure your products can be easily cut over to standards track IF and WHEN a relevant standard arises. Sign me "standards cynic"] ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 21:01:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23265; Fri, 10 Mar 95 21:01:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23259; Fri, 10 Mar 95 21:01:02 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03396; Fri, 10 Mar 1995 20:53:33 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA00621; Fri, 10 Mar 95 20:52:52 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA29624; Fri, 10 Mar 95 20:47:41 -0800 Received: by xirtlu.zk3.dec.com; id AA27959; Fri, 10 Mar 1995 23:47:39 -0500 Message-Id: <9503110447.AA27959@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipsec@ans.net Subject: Re: (IPng) The best In-Reply-To: Your message of "Sat, 11 Mar 95 01:55:53 GMT." <4236.Bill.Simpson@um.cc.umich.edu> Date: Fri, 10 Mar 95 23:47:32 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> From: bound@zk3.dec.com >> >I say that we simply behave like engineers and design the best system >> >we can, and leave it to the governments to cripple their own countries >> >by making it impossible for their citizenry to join the internet, or >> >by leaving their citizens open to massive fraud and invasion of >> >privacy. I will not lend my support to a consensus for anything less >> >than the best system I know how to design, and I suspect that others >> >feel the same way. >> >> I see no consensus that you keep saying with phrases like "I suspect >> that others feel the same way". I do see one hand clapping. > >OK, Jim, here's agreement with Perry. I feel the same way. I didn't >realise that any more than one person needed to say it. I think consensus has to be more than 3 people in a working group. >> I with Dan and others will object at last call to that wording in the >> document if it is to go to proposed standards before Danvers MA. Done!, >> and as far as I am concerned there is no consensus to support your views >> technically on any of the security subjects discussed in this rather >> extensive mail exchange. You have a view and others have a different >> view. Your not winning the debate your just sending a lot of mail. > >Perry is more attentive to replying to email than I am, particularly >when I'm writing code, so he has a tendency to be the frontrunner. >But you can rest assured, Mr Bound, that textual diarrhea is not one of >Perry's problems. It is certain "opponents" that have spammed multiple >lists, not Perry. Oh I don't agree and I have the mail archives from this discourse. >The IPv6 Security formats have been completed for some time. They do >not include key management. No and no one "at this point" is arguing they should per the discussion on the mail list. The debate now is the wording around in-band key management. >He and I and other have asked that IPv4 technical discourse, such as key >management, continue on the IPSec list. I think we that are concerned are now on IPsec and I am just responding. to the To: and cc: lines. >Seems to me to be the pot calling the kettle black. Not really on this one Bill. Face it, the wording as is about key management is enough to raise a very big issue to the IESG and I intend to do so if it comes across my mail inbox for last call. The only reason I am responding now is because you and Perry have been responding to me. I will be glad to get out of the loop because my mind is made up, unless I see a change in wording. It will be for the IESG to decide and not the working group I guess. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 10 21:34:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23277; Fri, 10 Mar 95 21:34:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23271; Fri, 10 Mar 95 21:34:01 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04292; Fri, 10 Mar 1995 21:26:33 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA03069; Fri, 10 Mar 95 21:26:35 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA01227; Fri, 10 Mar 95 21:21:39 -0800 Received: by xirtlu.zk3.dec.com; id AA29009; Sat, 11 Mar 1995 00:21:38 -0500 Message-Id: <9503110521.AA29009@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipsec@ans.net Subject: Re: (IPng) Re: The besty In-Reply-To: Your message of "Fri, 10 Mar 95 23:02:30 EST." <16660.9503110402@illuminati> Date: Sat, 11 Mar 95 00:21:31 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >>> I see no consensus that you keep saying with phrases like "I suspect >>> that others feel the same way". I do see one hand clapping. >>> >>OK, Jim, here's agreement with Perry. I feel the same way. I didn't >>realise that any more than one person needed to say it. > Ditto. I suppose I'll stand and be counted, too. > BTW - unless I'm mistaken, Perry's main topic-of-rant was >the notion of using exportable crypto instead of something like >DES. Crypto policy being what it is, *ANY* encryption support for >IP that is worth having will not be exportable. We need to accept >that, and publish a relevant standard so that independent non-US >iplementations can be developed without having to export code. I think your mistaken. The issue of exportable crypto has reached closure, your screwed everywhere and it all has restrictions. This is done, finished, and freakin figured out a day ago. I think we do have consensus on this that we are all screwed. The open issue, and unfortuneately we have some strong personalities who cannot agree (me included), is that the IPv6 security spec should remove the words that are negative towards in-band key management. This is the top issue at this point where we are bumping heads. >mjr. >[PS - Jim, if you're truly approaching this from the perspective >of a vendor, why wait for the ossified standards process to complete >its interminable gyrations? The only way to make things work is >to ignore the standards community until it catches up, and make >sure your products can be easily cut over to standards track IF >and WHEN a relevant standard arises. Sign me "standards cynic"] I am here as an individual paid for by my company who is a vendor. Who only asks me that while I am here to make sure I and others can acutually implement the standards. I never speak for my company and I don't think others do either. In fact Ran's draft at the bottom has a complete disclosure that NRL is not responsible for that draft. Lots of us do this and I put a lot of my own personal time into the IETF too, trust me as even the ones I am disagreeing with presently do to. I think its a sick kind of challenge maybe. But assuming I agreed with your comment. I would want to have my customers read Ran's draft and not see that in-band security is bad or to use Dan Nessetts paradigm of wearing Scuba Gear to the grocery store is something all my customers should do. I would like to maybe build a product that does not have perfect forwarding security, which is only necessary for the most in-secure environments and people. The other issue thats at hand is the IETF in their infinite wisdom has decided to make implementing security in a vendors host kernel MANDATORY even if customers (read the market) don't want to use it. Sounds like regulation to me. I am for less standards (no regulation) and more options that use the word MAY unless its an absolute core interoperability requirement like the network layer protocol or how one discovers other nodes on a network. I do not consider security to be in this category at all. So your preaching to the choir except vendors are required to implement standards or they cannot compete in the Open Systems Market. I would like to see a security standard (if we really must have one) that lets the market decide how to implement the key management for security. Now I do listen and can be influenced. For example I was going to object to Ran's draft because he did not mention key management in depth. Now I will accept this as proposed if he will leave ALL key management OPEN as an option. So if I wanted to be a capitalist die hard I could actually do what you have suggested and build and then push SKIP or Photarius or _STAY_OUT_OF_MY_COMPUTER_OR_I_WILL_PULL_YOUR_EYES_OUT type security. I think this all stems from a need to be safe which IMHO is impossible and a dumb way to exist. But I understand it as its natural for most. So lets build a core thought police interface for the Internet. But let the market hire the enforcers not the IETF network layer security standard, we can search the market and then standardize later on what enforcers for key management we need. Or as you suggest let the market put enforcers on top of the IPv6 security spec and if everyone uses it like NFS, DECnet, SNA, or UNIX then it will just become defacto. No Scuba Gear everywhere please. I don't like the color choices for the gear anyway because sharks think your a seal and eat you. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Mar 11 08:12:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23451; Sat, 11 Mar 95 08:12:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23445; Sat, 11 Mar 95 08:12:28 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20953; Sat, 11 Mar 1995 08:03:31 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA26532; Sat, 11 Mar 95 08:03:26 PST Received: from Bill.Simpson.DialUp.Mich.Net ([141.211.7.198]) by merit.edu (8.6.10/merit-2.0) with SMTP id LAA00788 for ; Sat, 11 Mar 1995 11:03:10 -0500 Date: Sat, 11 Mar 95 13:54:24 GMT From: "William Allen Simpson" Message-Id: <4239.Bill.Simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) ICMP Source Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: bill@wizard.gsfc.nasa.gov (Bill Fink) > Of course, the return paths from the transit routers back to the > source may happen to coincide with the forward data path, but we > should insure that traceroute returns the most meaningful information > possible in all cases, even when there is asymmetric routing between > the source and any of the transit routers in the path between the > source and the destination. > Perhaps our messages crossed in the ether. Since when does traceroute work this way in IPv4? How is it less meaningful? One of the interfaces is learned. Sure, it may not be an interface that the normal packet would ever traverse, but who cares? You now know the node (which likely has the same FQDN for all of its addresses in any case). > We need some explicit language in the IPv6 ICMP spec to make it > absolutely clear how to pick the source address for the ICMP hop > limit exceeded error message. > How to pick a Source is in Neighbor Discovery. It should be no different for any ICMP message. > For anyone who didn't grok my earlier postings on this subject, > I hope this helps clarify my technical issue with the current > IPv6 ICMP spec regarding selection of the source address for > generating ICMP error messages of type time limit exceeded, hop > limit exceeded. > I understood the first time, the second time, and the third time. In many cases (code I've written), you don't know the interface it came in on when it's punted to ICMP. ICMP just makes a message, and then passes it to the IP layer, which figures out the outgoing interface, and sets the Source. Anything else complicates the code too much. I am opposed to these changes. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Mar 12 06:03:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23536; Sun, 12 Mar 95 06:03:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23530; Sun, 12 Mar 95 06:02:18 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24382; Sun, 12 Mar 1995 05:53:55 -0800 Received: from wintermute.imsi.com ([192.103.3.10]) by Sun.COM (sun-barr.Sun.COM) id AA14496; Sun, 12 Mar 95 05:51:13 PST Received: from relay.imsi.com by wintermute.imsi.com id IAA06553; Sun, 12 Mar 1995 08:50:25 -0500 Received: from snark.imsi.com by relay.imsi.com id IAA29436; Sun, 12 Mar 1995 08:50:24 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA29308; Sun, 12 Mar 95 08:50:23 EST Message-Id: <9503121350.AA29308@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipsec@ans.net Subject: Re: (IPng) Re: The besty In-Reply-To: Your message of "Sat, 11 Mar 1995 00:21:31 EST." <9503110521.AA29009@xirtlu.zk3.dec.com> X-Reposting-Policy: redistribute only with permission Date: Sun, 12 Mar 1995 08:50:23 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM bound@zk3.dec.com says: > > BTW - unless I'm mistaken, Perry's main topic-of-rant was > >the notion of using exportable crypto instead of something like > >DES. Crypto policy being what it is, *ANY* encryption support for > >IP that is worth having will not be exportable. We need to accept > >that, and publish a relevant standard so that independent non-US > >iplementations can be developed without having to export code. > > I think your mistaken. No, I think, Jim, that YOU are mistaken. Marcus knew precisely what I had said. I was talking about your request that we find a crypto system other than DES that is acceptable to "all governments". You took my reply to that message and proceeded to rant about SKIP and in-band keying. Perhaps *you* wanted to talk about that, but your desire to discuss a topic has little impact on what topic I was writing about. This is the third and last time I'll tell you this. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Mar 12 13:28:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23668; Sun, 12 Mar 95 13:28:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23662; Sun, 12 Mar 95 13:28:04 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02423; Sun, 12 Mar 1995 13:20:36 -0800 Received: from sg543689.eng.chrysler.com by Sun.COM (sun-barr.Sun.COM) id AA00381; Sun, 12 Mar 95 13:20:26 PST Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id QAA19789 for ; Sun, 12 Mar 1995 16:20:23 -0500 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id QAA10362 for ; Sun, 12 Mar 1995 16:22:47 -0500 Received: from bobsgrid.is.chrysler.com by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA06091; Sun, 12 Mar 95 16:36:38 EST Message-Id: <9503122136.AA06091@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 12 Mar 1995 16:20:17 -0500 To: ipng@sunroof.Eng.Sun.COM, perry@imsi.com From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 02:58 PM 2/26/95 -0800, ipng@sunroof.Eng.Sun.COM wrote: >We have several firewalls in-house as well. However, these firewalls >with application-layer relays have never been used to establish >entire virtual enterprises over a public net like the Internet. They >typically give you a handful of Internet services, and connectivity >through them is not as seamless as on a private net. I don't believe >that to date, very large scale virtual enterprises have been built >using the kind of firewall you are referring to (though I am open >to correction). I may have heard wrong but a company bigger than us, a little up the road has used ANS's SiteLock to do just that... But then maybe SiteLock is a different kind of system than what Perry is talking about? Robert Moskowitz Chrysler Corporation (810) 758-8212 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Mar 12 15:52:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23711; Sun, 12 Mar 95 15:52:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23705; Sun, 12 Mar 95 15:52:17 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05643; Sun, 12 Mar 1995 15:44:47 -0800 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA06743; Sun, 12 Mar 95 15:44:31 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Mon, 13 Mar 1995 09:30:59 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Mon, 13 Mar 1995 08:45:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Mon, 13 Mar 1995 08:42:01 +1000 Date: Mon, 13 Mar 1995 08:42:01 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof2.Eng.Sun.COM, Keith._Perger@FINANCE.ausgovfinance.telememo.au X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Mar 13 08:42:00 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 004208130395 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <004208130395*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof2.Eng.Sun.COM (Non Receipt Notification Requested), Keith._Perger@FINANCE.ausgovfinance.telememo.au (Non Receipt Notification Requested) Subject: (IPng) Export controls on Crypto stuff Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM As a non US person I follow all these export things closely. As an international body the IETF should be specifying standards such that products are built so that Standard Internationally Obtainable parts can be added. People talk here of American Standard DES and I wonder why Australian Standard DES can't be used? It is the same standard after all (based on the ANSI). Hence if the products are built with the interfaces referencing internation standards, APIs and Hardware pinouts etc, then when it is shipped here the local part is inserted and Bob's your uncle. This should become a key component of the IP6 security design to allow the whole thing to work. You can't have a network that uses one standard in parts of the world and not in others. For instance, the Australian Government has no problems getting an export licence but sections of the community can't. What does that do to IP6 in Australia? Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Mar 12 16:44:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23723; Sun, 12 Mar 95 16:44:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23717; Sun, 12 Mar 95 16:44:25 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06865; Sun, 12 Mar 1995 16:36:55 -0800 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA09103; Sun, 12 Mar 95 16:36:25 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Mon, 13 Mar 1995 10:29:27 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Mon, 13 Mar 1995 10:29:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Mon, 13 Mar 1995 10:26:09 +1000 Date: Mon, 13 Mar 1995 10:26:09 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Mar 13 10:26:09 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 092610130395 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <092610130395*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Subject: Re: (IPng) Proposed message on perfect forward security Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > There are those of us who summarize the current US export >restrictions as, "If it's good, it can't be exported." Anyway, I >just wanted to point out that with the current regulations the way >they are, it's impossible to satisfy both requests, good security and >exportable. If the IEFT is truly an International organisation rather than a US organisation, it should be conceivable for an anti US Export campaign to be waged. IMHO specifying interfaces etc and ensuring that products can be built outside the US is the best way to change a law. Using Internationally Standards like DES can't be stopped. To ensure that standards are internationally available use interantionally based working groups. Once the legislature is aware that US products are being hurt in the export market things will change. Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 13 05:48:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23941; Mon, 13 Mar 95 05:48:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23935; Mon, 13 Mar 95 05:47:57 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01201; Mon, 13 Mar 1995 05:38:57 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA00915; Mon, 13 Mar 95 05:38:51 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm035-26.dialip.mich.net [141.211.7.37]) by merit.edu (8.6.10/merit-2.0) with SMTP id IAA13436 for ; Mon, 13 Mar 1995 08:38:48 -0500 Date: Mon, 13 Mar 95 00:21:40 GMT From: "William Allen Simpson" Message-Id: <4254.Bill.Simpson@um.cc.umich.edu> To: ipng@sunroof2.Eng.Sun.COM Subject: Re: (IPng) Export controls on Crypto stuff Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Good morning, Jeff. > From: Jeff.Latimer@finance.ausgovfinance.telememo.au > As a non US person I follow all these export things closely. As an > international body the IETF should be specifying standards such that > products are built so that Standard Internationally Obtainable parts > can be added. Agreed. > People talk here of American Standard DES and I wonder > why Australian Standard DES can't be used? It is the same standard > after all (based on the ANSI). Actually, I haven't seen any references to "American Standard DES" -- just references to the "official" DES publications: US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46-1, January 1988. US National Bureau of Standards, "Guidelines for Implementing and Using the Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 74, April 1981. US National Bureau of Standards, "DES Modes of Operation" Federal Information Processing Standard (FIPS) Publication 81, December 1980. Is there a better reference that we could use? > This should become a key component of the IP6 security design to allow > the whole thing to work. You can't have a network that uses one > standard in parts of the world and not in others. Is Australia's version any different? > For instance, the > Australian Government has no problems getting an export licence but > sections of the community can't. What does that do to IP6 in > Australia? > What has this to do with a standard part? The part is standard, the export is politics. Sections of the US community can't export, either. That doesn't mean that import is disallowed. This has merely caused most US manufacturers to build overseas, costing US jobs. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 13 08:17:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24020; Mon, 13 Mar 95 08:17:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24014; Mon, 13 Mar 95 08:16:26 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09432; Mon, 13 Mar 1995 08:07:41 -0800 Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA25499; Mon, 13 Mar 95 08:07:23 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA06386; Mon, 13 Mar 95 08:02:28 -0800 Received: by xirtlu.zk3.dec.com; id AA11651; Mon, 13 Mar 1995 11:02:25 -0500 Message-Id: <9503131602.AA11651@xirtlu.zk3.dec.com> To: Theodore Ts'o Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: (IPng) Re: A plea for peace.... In-Reply-To: Your message of "Sat, 11 Mar 95 01:24:44 +0500." <199503110624.AA18067@interlock.ans.net> Date: Mon, 13 Mar 95 11:02:19 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ted, Please send me what you call a flame. I can't see it. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 13 08:25:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24044; Mon, 13 Mar 95 08:25:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24038; Mon, 13 Mar 95 08:24:39 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10152; Mon, 13 Mar 1995 08:15:56 -0800 Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA27073; Mon, 13 Mar 95 08:15:50 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA07009; Mon, 13 Mar 95 08:12:12 -0800 Received: by xirtlu.zk3.dec.com; id AA12105; Mon, 13 Mar 1995 11:12:09 -0500 Message-Id: <9503131612.AA12105@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipsec@ans.net Subject: Re: (IPng) Re: The besty In-Reply-To: Your message of "Sun, 12 Mar 95 08:50:23 EST." <9503121350.AA29308@snark.imsi.com> Date: Mon, 13 Mar 95 11:12:03 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry, ************************ bound@zk3.dec.com says: > > BTW - unless I'm mistaken, Perry's main topic-of-rant was > >the notion of using exportable crypto instead of something like > >DES. Crypto policy being what it is, *ANY* encryption support for > >IP that is worth having will not be exportable. We need to accept > >that, and publish a relevant standard so that independent non-US > >iplementations can be developed without having to export code. > > I think your mistaken. No, I think, Jim, that YOU are mistaken. Marcus knew precisely what I had said. I was talking about your request that we find a crypto system other than DES that is acceptable to "all governments". You took my reply to that message and proceeded to rant about SKIP and in-band keying. Perhaps *you* wanted to talk about that, but your desire to discuss a topic has little impact on what topic I was writing about. This is the third and last time I'll tell you this. ********************** I am not ranting about encryption. I sent a note asking if there was a means to provide an encryption algorithm that was publicly available and had no restrictions anywhere. The answer was NO. My other mail is regarding in-band keying and the removal of the words presently in the IPv6 sec draft. Send me the mail where I mention SKIP. The only time I mentioned it was that I want the option to prototype SKIP or other proposals for host keying. Whats happening here is the debate is getting very focused and getting closer to the ONLY issue left. Removal of the present words in IPv6 sec about in-band keying. No more and no Less. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 13 08:38:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24060; Mon, 13 Mar 95 08:38:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24054; Mon, 13 Mar 95 08:38:28 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11330; Mon, 13 Mar 1995 08:29:33 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA00344; Mon, 13 Mar 95 08:29:19 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm035-26.dialip.mich.net [141.211.7.37]) by merit.edu (8.6.10/merit-2.0) with SMTP id LAA21018 for ; Mon, 13 Mar 1995 11:29:12 -0500 Date: Mon, 13 Mar 95 15:54:20 GMT From: "William Allen Simpson" Message-Id: <4264.Bill.Simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) True Internationalism Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Jeff.Latimer@finance.ausgovfinance.telememo.au > If the IEFT is truly an International organisation rather than a US > organisation, it should be conceivable for an anti US Export campaign to be > waged. IMHO specifying interfaces etc and ensuring that products can be built > outside the US is the best way to change a law. Sigh. Some of us have been waging this battle for years. Even for PPP CHAP with MD5, I endured an FBI investigation, a 4 year tax audit, wire-tapping, and other official intimidation. We eventually got authentication moved from State to Commerce, where it merely needs to be registered instead of examined on a case by case basis. This took a lot of time and expense, and some pretty fancy maneuvering. Last year, Phil Karn (with a little help from his freinds) took up the export matter of the _book_ "Applied Cryptography" [Schneier 94]. It was denied. For us, this is a serious Constitutional violation. Then, the lawyers got involved (thanks to EFF, send your contributions), and the appeal was granted. Put your money where your mouth is, and buy the book! Since then, Phil Karn (with the help of the EFF) is battling to allow export of machine readable export distribution of the _text_ of the book. That has been denied, appealed, denied, and is now at the highest level of the US Administration. Apparently, somebody thinks that foreign nationals can't type or use an OCR scanner. So, stop telling us how to change a law. We've already been putting our asses on the line, and staring down multi-year prison terms. If your government (of which you seem to be a part) thinks this is important, then it had damn well better let other governments know! > Using Internationally > Standards like DES can't be stopped. Did you ever look at the names on the Finland distribution of the Public Domain version of DES? Did you ever think about how it got there? And why Finland? > Once the > legislature is aware that US products are being hurt in the export market > things will change. > The US House Judiciary Committee already had a series of hearings in 1992. BTW, do you use PGP? Phil Zimmerman is actually on _trial_ now for a possible 10 year sentence and $1,000,000 fine. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 13 08:48:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24085; Mon, 13 Mar 95 08:48:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24078; Mon, 13 Mar 95 08:48:10 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12878; Mon, 13 Mar 1995 08:40:40 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA02882; Mon, 13 Mar 95 08:40:38 PST Received: from relay.imsi.com by wintermute.imsi.com id LAA09686 for ; Mon, 13 Mar 1995 11:40:35 -0500 Received: from snark.imsi.com by relay.imsi.com id LAA09740 for ; Mon, 13 Mar 1995 11:40:34 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA01171; Mon, 13 Mar 95 11:40:34 EST Message-Id: <9503131640.AA01171@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) True Internationalism In-Reply-To: Your message of "Mon, 13 Mar 1995 15:54:20 GMT." <4264.Bill.Simpson@um.cc.umich.edu> X-Reposting-Policy: redistribute only with permission Date: Mon, 13 Mar 1995 11:40:33 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM "William Allen Simpson" says: > > BTW, do you use PGP? Phil Zimmerman is actually on _trial_ now for a > possible 10 year sentence and $1,000,000 fine. > He's not yet on trial -- he hasn't even been formally charged yet, although I suspect he will be. PErry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 13 09:20:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24117; Mon, 13 Mar 95 09:20:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24111; Mon, 13 Mar 95 09:20:27 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB16899; Mon, 13 Mar 1995 09:12:02 -0800 Received: from amdext.amd.com by Sun.COM (sun-barr.Sun.COM) id AA09794; Mon, 13 Mar 95 09:10:35 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA10083 (5.67a/IDA-1.5+AMD for ); Mon, 13 Mar 1995 09:10:30 -0800 Received: from brahms.amd.com by amdint.amd.com with SMTP id AA21752 (5.67a/IDA-1.5+AMD for ); Mon, 13 Mar 1995 09:10:28 -0800 Received: from angelo.amd.com by brahms.amd.com (4.1/AMDSN-1.18) id AA26678; Mon, 13 Mar 95 09:09:44 PST Received: by angelo.amd.com (4.1/AMDC-1.18) id AA02228; Mon, 13 Mar 95 09:10:26 PST From: David.Roberts@amd.com (Dave Roberts) Message-Id: <9503131710.AA02228@angelo.amd.com> Subject: Re: (IPng) Proposed message on perfect forward security To: ipng@sunroof.Eng.Sun.COM Date: Mon, 13 Mar 1995 09:10:25 -0800 (PST) In-Reply-To: <092610130395*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> from "Jeff.Latimer@finance.ausgovfinance.telememo.au" at Mar 13, 95 10:26:09 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > If the IEFT is truly an International organisation rather than a US > organisation, it should be conceivable for an anti US Export campaign to be > waged. IMHO specifying interfaces etc and ensuring that products can be built > outside the US is the best way to change a law. Using Internationally > Standards like DES can't be stopped. To ensure that standards are > internationally available use interantionally based working groups. Once the > legislature is aware that US products are being hurt in the export market > things will change. I agree, 100%. I believe that we (the IETF) should just specify the right thing regarding security protocols and let things take their course. The export laws don't prevent encrypted traffic from crossing US borders and with DES well known and many, many implementations floating around, it isn't like we couldn't get an international system working. It just prevents US manufacturers from exporting that component of their products. Anyway, I was just responding to Jim's (?) desire to have an exportable algorithm; I was not implying that we should only specify something exportable and thus not cryptographically secure (though DES is right on the edge of cryptographically secure). I don't know if things will change "once the legislature knows." The legislature is currently aware of the issues. There have been a couple of bills introduced in the US congress to drop the restrictions (or at least ease them--the Cantwell (sp?) bill) in recent months, but all have been defeated or tangled up in committee such that they didn't see a formal vote. Anyway, I believe that it's only a matter of time, but suffice to say that our illustrious leaders are well aware today but have chosen the easy way out (no change). Dave Roberts Advanced Micro Devices, Inc. I/O and Network Products Division david.roberts@amd.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 13 09:34:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24129; Mon, 13 Mar 95 09:34:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23149; Fri, 10 Mar 95 18:21:15 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27197; Fri, 10 Mar 1995 18:13:46 -0800 Received: from cayenne.cs.ucdavis.edu by Sun.COM (sun-barr.Sun.COM) id AA16794; Fri, 10 Mar 95 18:13:38 PST Received: by cayenne.cs.ucdavis.edu (4.1/UCD.CS.2.6) id AA07742; Fri, 10 Mar 95 18:13:27 PST Date: Fri, 10 Mar 95 18:13:27 PST From: rogaway@cs.ucdavis.edu (Phil Rogaway) Message-Id: <9503110213.AA07742@cayenne.cs.ucdavis.edu> To: atkinson@itd.nrl.navy.mil Subject: (IPng) IPv6: review of draft-atkinson-ipng-{sec,auth,esp} (long) Cc: ipng@sunroof.Eng.Sun.COM, rogaway@cs.ucdavis.edu Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi, Randall, Below are my comments on your Internet Drafts on (A) IPv6 Security Architecture, (B) Authentication Header, and (C) Encapsulated Security Payload (ESP). Best regards, Phil 0 Phil Rogaway 10 March 1995 1 ----------------------------------------------------------------- 2 A. Comments on "IPv6 Security Architecture," by Randall Atkinson, 3 draft-atkinson-ipng-sec-01.txt, draft of 16 February 1995. 4 ----------------------------------------------------------------- 5 6 7 A.1.1. DEFINITIONS 8 9 You follow long-standing tradition in implying that there exist 10 distinct concepts of (cryptographic) message authentication and 11 (cryptographic) message integrity. In fact there is only one 12 underlying problem: you get a message and you believe or do not 13 believe that that particular message was sent by the claimed 14 originator. That there is only one concept here is apparent in a 15 formal treatment: the message authenticity goal is normally 16 understood to mean "no feasible existential forgery under adaptive 17 chosen message attack" (the symmetric version of the definition of 18 [Goldwasser, Micali, Rivest]). The message integrity goal means 19 the same thing. 20 21 I would thus advocate removing all subsequent references to message 22 integrity. For example: 23 24 3.3. COMBINING SECURITY MECHANISMS 25 Last line on page 5, strike "integrity": it should not in any 26 way be implied that the ESP provides integrity. After all, the 27 ideal encryption scheme of a one time pad provides no meaningful 28 integrity; and if this mechanism isn't a good ESP mechanism I'm not 29 sure what ought to be! 30 31 32 A.2. DESIGN OBJECTIVES 33 34 I question that use of the same algorithms as SNMPv2 be a DESIGN 35 OBJECTIVE. (If SNMPv2 has appropriate mechanisms then they should be 36 used; otherwise they should not.) 37 38 39 A.3. IPv6 SECURITY MECHANISMS 40 41 That the privacy mechanism of the ESP might provide authenticity is 42 of course true -- but for an architecture document I would do much 43 more to actively discourage any such attempted use of the ESP. 44 Instead, I would make the simple statement that if you want privacy 45 and authenticity BOTH, you should use BOTH an AH and an ESP. 46 47 My reluctance to admit in an architecture document that a privacy 48 mechanism MIGHT provide authenticity is that concrete proposed privacy 49 mechanisms invariably do NOT achieve message authenticity/integrity. 50 What is more, the original motivation for "including" authenticity in 51 a privacy mechanisms was to improve computational efficiency -- there 52 was a belief that a fast-to-compute "Manipulation Detection Code" 53 (MDC) could be included in the scope of a symmetric encryption 54 mechanism (e.g., DES-CBC) and the result would be to provide 55 authenticity AND privacy with total computational overhead less than 56 separate mechanisms would have taken. In retrospect, this belief 57 was probably wrong: I know of no correct mechanism for 58 privacy + authenticity which is faster to compute than a correct 59 mechanism for privacy + a correct mechanism for authenticity. 60 61 This same point comes up again, e.g. 3.2., first sentence. 62 63 64 A.3.1 AUTHENTICATION HEADER 65 66 I question keyed MD5 is a choice of a default MAC because: 67 68 a. Speed -- it's a few tens of instructions per word, and nothing 69 can ever be done about this. 70 71 b. Lack of parallelizability -- If you can compute MD5 in $x$ bps 72 using one MD5 chip then with two MD5 chips you can compute MD5 73 in ... $x$ bps. 74 75 c. "Foundation-less-ness" -- Though I don't know an attack on 76 MAC_a(x) = MD5(a.x.a), it should be made explicit that the 77 security of such a scheme has nothing to do with MD5 being 78 collision intractable, one-way, etc.. (Notation: MAC is for 79 "Message Authentication Code." MAC_a(x) is the tag for sting $x$ 80 using key $a$.) 81 82 I understand that there is not yet any concrete and attractive 83 alternative to something like MAC_a(x)=MD5(a.x.a), but I'm sure that 84 one can be found. I believe that the best approach lies in 85 Wegman-Carter Authentication (JCSS 1981, 265-279). Any version of 86 Wegman-Carter authentication will fix (b) and (c), and a 87 well-constructed scheme ought to improve on (a). As a sample 88 mechanism, look at the "CRC MAC" of [Krawczyk, Crypto '94]. More 89 efficient proposals are forthcoming. 90 91 92 A.STRUCT. Organization 93 94 More generally (and strictly as a point of organization) it is not 95 really the business of an architecture document to be describing ANY 96 particular mechanism. I'd say it is not clear that it is even the 97 place in the documents one level down. But if mechanisms are 98 described in the AH and ESP documents, it should be ONLY in an 99 appendix or section which does nothing but describe the mechanism. 100 And the mechanism description should be independent of the intended 101 usage. 102 103 Architecture Overall architecture 104 / \ 105 / \ AH and ESP architectures, 106 AH ESP described assuming abstract 107 / \ | \ transformations for MAC, enc. 108 / \ | \ 109 AM-1 ... AM-n PM-1 ... PM-m Authentication and privacy 110 mechanisms (the possible 111 transformations), described 112 independently of intended use. 113 114 115 A.3.2.3. PERFORMANCE IMPACTS OF ESP 116 117 The assumption here is that ESP performance is going to be worse 118 than AH performance. This assumption accurately reflects software 119 DES-CBC_a(x) vs. software MD5(a.x.a); but it does NOT accurately 120 reflect the state-of-the-art, either for hardware embodiments of 121 hardware-efficient schemes (where both a well-designed MAC and a 122 well-designed symmetric encryption can keep up with GBit networks); 123 nor for software-embodiments of software-efficient schemes (where 124 ciphers like SEAL [Rogaway and Coppersmith, 1993] are faster than 125 hash functions like MD5). 126 127 You go on to encourage hardware implementations for high throughput. 128 I believe that this suggestion is more feasible for gateways than 129 pervasive end-to-end encryption. The suggestion I would prefer is 130 special-purpose hardware for hardware-efficient algorithms (like 131 DES CBC), and software-efficient mechanisms where one envisions 132 software embodiments to prevail. 133 134 I would go on to propose that there should be at least TWO required 135 optional IPv6 encryption mechanisms: a hardware-efficient one (based 136 on DES), and a software-efficient one. 137 138 139 A.3.3. COMBINING SECURITY MECHANISMS 140 141 The "cryptographically correct" approach for providing 142 authenticity AND privacy is to authenticate the ciphertext, NOT 143 the cleartext. I have seen many people get this wrong. Shouldn't 144 the architecture talk of this? 145 146 From an organizational point of view, the discussion on combining 147 mechanisms may be more appropriate in an architecture document than 148 in the ESP document. 149 150 151 A.4. AUTOMATED KEY DISTRIBUTION 152 153 It wasn't at first clear to me that the key associated to a SAID is 154 a SESSION KEY. It is worth pointing out in the document that a 155 session key must be used; for example, it would be INCORRECT to 156 realize the key on a SAID as a key which depends only on the identity 157 of the communication endpoints. Doing that would, for example, allow 158 cross-session replay attacks of what were supposed to be authenticated 159 messages. Thus even when communication are configured to have a 160 shared secret key, some (at least implicit) key distribution takes 161 place anyway. 162 163 164 A.KS Key Separation 165 166 Have you ignored key separation? It wasn't clear to me if you expect 167 key separation to be done by the key-distribution mechanism or within 168 the various AH and ESP mechanisms. In the first case this is an 169 architectural requirement which you are effectively levying on the key 170 distribution mechanism, so you should say so; in the second case, you 171 are levying this requirement on each MAC and encryption mechanism, and 172 you should say that. 173 174 Eg: Suppose you distribute a session key for A-->B and you use this 175 SAME session key for DES-CBC-MAC authentication and DES-CBC encryption 176 (in an AH and ESP mechanism, respectively). Then clearly the 177 encryption mechanism destroys the authenticity you thought you were 178 getting from the authentication mechanism. There are two outs: the 179 architecture specifies that distinct session key distributions are 180 used for each mechanism; or else the architecture lets mechanisms 181 share distributed keys, but each mechanism is expected to produce and 182 act using its own key variant, said key variants not being related to 183 one another by any efficiently-computable means. 184 185 I personally believe that the key separation should be done by each 186 mechanism, using its own "random" key variant or a registered key 187 separation constant. For I believe the key distribution mechanism 188 ought to be oblivious as to the beneficiaries of its keys. It also 189 saves communication costs to only distribute one key, and have each 190 mechanism generate its own variant. If you mean to use 191 mechanism-specific variants, then you need to set the precedent on 192 HOW you want to do this (by doing it in your required AH and ESP 193 mechanisms). 194 195 Key separation is very important. A failure to perform proper key 196 separation will almost certainly cause security "interaction" problems 197 if the set of supported MAC and encryption mechanisms becomes 198 reasonably populated. If the architecture document doesn't mandate 199 who does this, no one will do it. 200 201 202 A.4.2. Some Existing Key Management Techniques 203 204 You really mean "key distribution" techniques, not key management 205 techniques. "Key management" is a broader problem. 206 207 If you are thinking to mention [Diffie, Hellman] in this regard, it 208 would be better to mention [Diffie, van Oorschot and Wiener 1992], 209 which at least solves a key distribution protocol for the active 210 adversarial setting. 211 212 Note that even if communicating parties have a manually configured 213 shared key, this is not the key that should be on the SAID; a fresh 214 session key should be distributed. The simplest correct techniques 215 can be found in [Bellare, Rogaway - Crypto '93] 216 217 It is not right to say [DH] came after [NS]. 218 219 I would be reluctant to survey works in a paragraph here; this area 220 is too large to say much meaningful about in one paragraph. 221 222 223 A.MINOR. Typos and other minor matters: 224 225 1.1 - Traffic Analysis - line 2. "oneself just" -> "an entity" 226 3.2.3, line 11. Strike "key size," which is irrelevant except 227 insofar as it is reflected in the previous item. 228 3.2.3 - organization - this paragraph isn't all on performance, as 229 the title says 230 4.3, line 6, strike "would". 231 232 233 234 235 ----------------------------------------------------------------- 236 B. Comments on "IPv6 Authentication Header," by Randall Atkinson, 237 draft-atkinson-ipng-auth-01.txt, draft of 16 February 1995. 238 ----------------------------------------------------------------- 239 240 241 B.1. INTRODUCTION & OVERVIEW 242 243 - last line page 1: as per earlier comments: strike "in lieu of": 244 if you want authenticity, use the AH; if you want privacy, use the 245 ESP; if you want both, use both. Simple story. 246 247 - page 2, paragraph 3, line 5. Presupposes that the MAC verification 248 consists of MAC generation and then comparing the generated MAC 249 with the received one. While this is the approach of the Appendix A 250 mechanism, this certainly is not the only possible one: in fact, 251 it is often useful for the MAC to be probabilistic (the sender 252 flips coins to generate the MAC) or stateful (e.g. the sender 253 maintains a counter which is used in the MAC). Obviously such 254 means should not be excluded. In general, the MAC scheme is pair of 255 algorithms -- one to generate a MAC and one to verify a purported MAC. 256 257 258 B.2. KEY MANAGEMENT 259 260 - Paragraph 1. Key management is out of scope not just because of a 261 history of difficulties, but because there are several trust models 262 and several variants within each trust model of the problem which 263 solutions attempt to solve. 264 265 - It is SESSION KEYS which are being distributed. 266 267 - Paragraph 2. strike "and mode." It is not an "authentication 268 algorithm and a mode; it is simply an authentication algorithm. 269 If your mechanism is MAC_a(x) = DES-CBC-MAC_a(x), for example, that 270 whole thing is the algorithm. 271 272 - Why is this section even here? Isn't this for the architecture 273 document? 274 275 276 B.3. SECURITY ASSOCIATION IDENTIFIER (SAID) 277 278 p. 4. It is not appropriate to specify that the SAID be pseudorandom, 279 since this is not the document which specifies how SAIDs are 280 determined. In fact, as far as everything in these documents are 281 concerned, a mechanism which used sequence numbers for SAIDs, 282 for example, would be just fine. 283 284 p. 5, paragraph 3: "Each SAID value implies ..." should be simplified 285 to "Each SAID value implies the key used in the authentication 286 algorithm, and the authentication algorithm itself." All the other 287 stuff you list is implied by this. The (entire) MAC generation and 288 MAC verification algorithms are what is meant by "algorithm". If I 289 choose to make a MAC algorithm which uses an a block cipher, an 290 IV, .... that's fine -- but it's all just part of my algorithm. 291 292 293 B.4. CALCULATION OF THE AUTHENTICATION DATA 294 295 -You say that [if MAC_a(x) is an $a$-encrypted cryptographic 296 hash or a "keyed" cryptographic hash then] the hash should be one-way. 297 Actually, the assumed one-wayness of a function like MD5 is 298 not the pertinent in determining whether or not the function 299 MAC_a(x) = MD5(a.x.a) is a secure MAC. The same holds for most other 300 candidate MAC constructions which use a cryptographic hash function. 301 302 -I question why you are describing things like your proposed MAC 303 mechanism multiple times. Better to describe the body of this 304 proposal in terms of an abstract function MAC_a(x), MACV_a(x) 305 (MAC generate and verify); and if you want to have a required 306 mechanism in the same RFC, then it would be ONLY in a separate 307 appendix. Having the description multiple times only makes it more 308 likely that the descriptions will vary. (In fact this happens; I read 309 this section to say MAC_a(x) = MD5(a.x.a), and the appendix to say 310 that MAC_a(x) = MD5(a.x) !) When MAC_a(x) and MACV_a(x) are described, 311 this description should be independent of their intended usage (and it 312 should be a secure MAC regardless of the structure of $x$). Thus you 313 shouldn't be talking about Hop Counts etc. when you're describing a 314 particular MAC mechanism; you would talk about this only when you're 315 saying what this function is called on. 316 317 -I have already questioned the wisdom of MAC_a(x)=MD5(a.x.a) because 318 of issues in speed, parallelism, and foundationlessness. Let me 319 add in the remark that if one IS going to use a mechanism like 320 MD5(a.x.a), it would be safer to use only the first 64 bits of 321 MD5(a.x.a). The chance that the adversary has of forging a correct 322 MAC by choosing a random tag is still insignificant (2^{-64}), but now 323 the adversary is denied half of the data which might be useful in 324 recovering $a$ or otherwise breaking the MAC scheme. As an example 325 for how this can help, think back to MAC_a(x) = MD5(a.x), which is an 326 easily broken MAC (as pointed out by [Tsudik 92]). This MAC is NOT 327 known to be breakable had the digest been clipped to the first 64 bits 328 of MD5(a.x). 329 330 -One sentence implies that MD5(a.x.a) might be faster to compute than 331 MD5(x.a). This is false. MD5(a.x) might sometimes be faster to 332 compute then MD5(x.a) (for the reason cited in the draft) -- but that 333 is irrelevant. 334 335 -(first paragraph on page 7) You should say that the receiver MUST 336 discard the datagram as non-authentic-- in what sense have you 337 complied with a message authentication scheme if you accept any 338 packet, independent of its MAC?! 339 340 -On the other hand, you SHOULD audit this event--not that you MUST. 341 Demanding auditing is wrong for two reasons: (1) it provides a 342 natural denial of service attack of sending enough unauthentic 343 packets to fill up the audit log; (2) it effectively mandates 344 that clients support auditing, which is unrealistic in that many 345 platforms which run Internet suite protocols do not support auditing. 346 347 348 B.MD5 APPENDIX A 349 350 -It looks like you have forgotten to append the key to the 351 "b-bit message." You mean MAC_a(x) = MD5(a.x.a), right? That's 352 what's described earlier. 353 354 -It is also not entirely obvious that you mean the length of the 355 message which is used in MD5's padding is the length of the string 356 you are authenticating plus the 256 bits which have been added to it. 357 You should take RFC 1321 to specify a function MD5(x), and then you 358 should use this function to describe your MAC. No reference should 359 be made to the internal structure of MD5 (which is irrelevant). 360 361 -I have already criticized the choice of MAC_a(x)=MD5(a.x.a) on 362 various technical grounds. .... 363 364 365 B.MINOR. Typos and other minor matters: 366 367 -page 4: forgot to say the length of the RESERVED field. 368 -page 6, line 1: I'm not sure what you mean "usually"; there are 369 a great many ways to compute MACs. The most popular, the CBC MAC 370 of X9.9, in fact is not of this form. 371 -page 8. line 3: strike "instead of or". 372 373 374 375 376 ----------------------------------------------------------------------- 377 C. Comments on "IPv6 Encapsulating Security Payload (ESP)" by Randall 378 Atkinson, draft-atkinson-ipng-esp-01.txt, draft of 16 February 1995. 379 ----------------------------------------------------------------------- 380 381 382 C.1. INTRODUCTION and 383 C.1.1 OVERVIEW 384 385 -I don't mean to keep harping on the same thing (this is happening 386 because of the structure of this review)... but you should NOT be 387 saying that the ESP provides integrity. Integrity is simply not a 388 cryptographically meaningful notion distinct from authenticity; and 389 perfectly good privacy mechanisms (e.g. a one-time pad) do not achieve 390 anything that anyone would describe as integrity. 391 392 -If one is really going to admit the possibility that the ESP might 393 provide authenticity, then it could achieve authenticity in the 394 asymmetric model (non-repudiation) just as it could achieve 395 authenticity in the symmetric model. But of course I am not 396 suggesting to add this possibility to the text -- rather the opposite, 397 to take away all comments that the ESP might provide authenticity 398 (symmetric or asymmetric). 399 400 - Saying that ESP may be very expensive to implement is unfair, since 401 this is strictly a question of mechanisms. You did not make such 402 strong statements about authenticity (and as I mentioned, the fastest 403 published software privacy mechanisms are faster than the fastest 404 published software authenticity mechanisms). 405 406 - There is something very wrong with the multiple headers notion you 407 describe in paragraph 2: an encrypted one and a (usually identical?) 408 unencrypted one. You say that the former is "primarily" used 409 for routing and the later for authenticity -- but the second comment 410 makes no sense, since you can not count on the the encryption mechanism 411 as providing any authenticity/integrity. Having the header which 412 appears in plaintext also appear in ciphertext buys you nothing 413 cryptographically, but it does (slightly) increase the length of your 414 packets and the amount of work to produce them. 415 416 417 C.2 KEY MANAGEMENT 418 419 Relevant comments already made. I advise against repeating 420 statements like this in multiple documents. 421 422 423 C.3.1. SAID 424 425 -Relevant comments already made. 426 427 -You say that the SAID is selected based on the sending userid 428 and the destination host. As I understand it, this pair does 429 NOT determine a unique SAID. The SAID should be in one-to-one 430 correspondence with (unidirectional) security contexts. A given 431 userid and host could have multiple security contexts. 432 433 434 C.3.2 ENCRYPTED FIELDS. RESERVED 435 436 -Paragraph 2. I've already complained about this idea of having 437 BOTH the encrypted routing information AND the plaintext routing 438 information. The former should be dropped. Authenticating the 439 routing information is very important, but encrypting the routing 440 information should never engender confidence in the receiver that 441 the routing information is in any way reliable. 442 443 To avoid the attacks you refer to the user should use the AH in 444 addition or in place of the ESP. Because there are relatively 445 few environments where privacy is wanted and authenticity is not, 446 the architecture document should discourage use of the ESP without 447 concomitant use of the AH. 448 449 450 C.4.1 ESP in IP-mode 451 452 -As mentioned: (sending user ID, receiving party ID) does not 453 necessarily determine a unique SAID or a unique key. There 454 could be lots of (senderID, receiverID) sessions, each of which 455 needs to be protected by its OWN key. 456 457 -Don't require auditing (as explained earlier); suggest it. 458 459 460 C.4.3 Combining ESP and the Authentication Header 461 462 I do not understand the third paragraph. Is this describing 463 the second approach -- you are encrypting the authenticated 464 data? This should not be done; the scope of the MAC should 465 cover the whole non-variant portion of the datagram, enciphered 466 or not. I have no idea what happens when you try to encrypt a MAC 467 (it is not clear that it remains a correct MAC). 468 469 470 C.7. SECURITY CONSIDERATIONS 471 472 You sort of unfairly imply that DES has a reasonable chosen 473 plaintext attack, citing [BS93]. But [BS93] does not 474 demonstrate a reasonable attack. 475 476 477 C.APPENDIX 478 479 -Don't cite [Sch94] for describing DES (a great number of books in 480 cryptography and computer security repeat the definition of DES). 481 482 -Even worse is citing [Sch94] for citing Eberle's Crypto '92 paper! 483 (In any case, why is it relevant that DES can be implemented on an 484 (unavailable) GaAs chip of 1992 technology to perform at 1 Gbps?) 485 486 -The cited standards differ in whether or not they demand enforcement 487 of the parity bit convention. You should specify this one way or 488 another. (I would demand non-enforcement of the parity bit 489 convention.) 490 491 -More should be specified about the choice of the IV, since a 492 predictable sequence of nonces is not a good choice. DES_a(i) is 493 the usual choice for the i-th IV of a session. It would be better 494 to transmit nonce i as synchronization data and let the receiver 495 compute IV=DES_a(i) himself. Otherwise, people will mis-implement. 496 497 -More fundamentally, I question the appropriateness of DES-CBC as the 498 only required privacy mechanism. Reasons: 499 500 (a) The key exhaustion known-plaintext attack of DES-CBC is 501 sufficiently problematic that I believe any new proposals should 502 use DES in a mode of operation which is not susceptible to 2^{56} 503 key-exhaustion. This is possible even if one wants to spend just 504 one DES operation for block: for example, [Blaze 93] gives such 505 mode of operation. Even simpler, one might make 506 " CBC" as the required ESP mechanism; if one wants it 507 to collapse to single DES, one selects a key of $a=(a',a')$ and 508 incurs no computational penalty. Making sure that the 509 distributed encryption keys are 128-bits --right from the start-- 510 will help ensure a cleaner evolution path from IPv6. 511 512 (b) Realistically, most end users are not going to have DES 513 hardware and they are not going to want to pay the performance 514 penalty to DES encrypt their IPv6 traffic. The security are 515 mechanisms are useless if no one wants to use them because 516 they are too slow. Thus I believe a required software-efficient 517 mechanism should supplement the hardware-efficient one. 518 Currently the drafts embody a peculiar asymmetry in the 519 required mechanisms: one is intended to be software-efficient 520 (MD5(a.x.a)), while one is intended to be hardware efficient 521 (DES-CBC). This then suits no one's needs well. I would 522 suggest that all four possibilities are important enough to 523 support as required-optional mechanisms: 524 525 526 HW-efficient SW-efficient 527 ________________________________ 528 | | | 529 AH | mac.hw | mac.sw | 530 |_______________________________ 531 | | | 532 ESP | enc.hw | enc.sw | 533 |_______________________________ 534 535 IPv6 Required cryptographic algorithms 536 537 538 I do not know exactly what each mechanism should be, but 539 as a first guess I'd say something like: 540 541 enc.hw: CBC (a) 542 mac.hw: DES CBC MAC (b) 543 enc.sw: SEAL (c) 544 mac.sw: A Wegman-Carter MAC (d) 545 546 547 None of these choices is ideal: 548 549 (a)--3x performance penalty in SW if use key not of 550 form a=(a' a'). Inappropriate at Gbit speeds. 551 (b)--Inappropriate at Gbit speeds. Security analysis suggests 552 alternative mechanisms are stronger. 553 (c)--Inadequate review. (But no well-reviewed fast sw cipher 554 is on the horizon.) 555 (d)--No fully-specified concrete scheme is yet in the 556 literature. 557 558 559 C.MINOR. Typos and other minor matters: 560 561 -page 2, paragraph 2: "an datagram". "an header"? 562 -"synchronisation" (sp?) 563 -do you say if field lengths are in bits/bytes? If bytes: is "- 8" 564 really meant on top of page 6? 565 -"a encryption key" (p. 7, line 5); again page 7, line last-6 566 -add "and algorithm" on (p. 7, paragraph 2, line 4, after "key"). 567 -"MUST recorded" (p. 7) 568 -p.9, TYPICAL USE, line 1, "security" -> "privacy". Last sentence 569 is oxymoronic. 570 -p.9 "an SAID"? 571 -I do not know that [CN94] is making a contribution to be highlighted 572 in Section 7, paragraph 2, line 5. 573 574 ..................................................................... 575 576 Phillip Rogaway 577 Eng. II Bldg., #3063 578 Dept. of Computer Science 579 University of California 580 Davis, CA 95616 USA 581 582 Office: (916) 752-7583 583 FAX: (916) 752-4767 584 585 rogaway@cs.ucdavis.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 13 09:44:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24141; Mon, 13 Mar 95 09:44:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23321; Fri, 10 Mar 95 22:32:14 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05859; Fri, 10 Mar 1995 22:24:45 -0800 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU) by Sun.COM (sun-barr.Sun.COM) id AA06671; Fri, 10 Mar 95 22:24:47 PST Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA12672; Sat, 11 Mar 95 01:24:44 EST Received: by dcl.MIT.EDU (5.0/4.7) id AA17871; Sat, 11 Mar 1995 01:24:44 +0500 Date: Sat, 11 Mar 1995 01:24:44 +0500 From: Theodore Ts'o Message-Id: <9503110624.AA17871@dcl.MIT.EDU> To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net In-Reply-To: bound@zk3.dec.com's message of Sat, 11 Mar 95 00:21:31 -0500, <199503110526.AA11126@interlock.ans.net> Subject: (IPng) A plea for peace.... Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, You're flaming. Not that you're the only one who's been doing it lately, on both of these lists. But, could we, please, have just a tad bit more civility on these lists, and focus on the task at hand, without slipping into invective? There have been people on both sides of nearly all of the past couple of discussions (you and Perry and Bill, and others) who have been guilty of this. Even a little bit of effort would make this working group list much more pleasant to read, and make it much more plesant to particpate in this working group. Thanks.... (a very frustrated) - Ted ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 13 10:19:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24198; Mon, 13 Mar 95 10:19:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23998; Mon, 13 Mar 95 06:30:28 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02900; Mon, 13 Mar 1995 06:22:04 -0800 Received: from mwunix.mitre.org by Sun.COM (sun-barr.Sun.COM) id AA06246; Mon, 13 Mar 95 06:21:58 PST Received: from smiley.sit (smiley.mitre.org [128.29.140.20]) by mwunix.mitre.org (8.6.10/8.6.4) with SMTP id JAA00530; Mon, 13 Mar 1995 09:21:54 -0500 Received: from [128.29.140.100] (shirey-mac) by smiley.sit (4.1/SMI-4.1) id AA04074; Mon, 13 Mar 95 09:21:12 EST Date: Mon, 13 Mar 95 09:21:12 EST X-Sender: shirey@smiley.mitre.org Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bound@zk3.dec.com From: shirey@mitre.org (Robert W. Shirey) Subject: (IPng) Principle Statement on Patents and Exports Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM FYI. Adapted from draft-irtf-psrg-secarch-sect1-00.txt 3.5 Use of the Best Available Technology Internet standards should always employ the best available technology to provide high-quality security. National restrictions and patents sometimes make it hard to follow this principle, but a technology should not be avoided in an attempt to satisfy some countries in which the technology is restricted or patent rights are asserted. The rules differ too much among countries, and the rules keep changing. Any attempt to make Internet standards satisfy the rules of any particular set of governments would unnecessarily and unfairly restrict development and use of Internet technology in other countries. For example, the use of cryptography in Internet standards should not be limited just because of national restrictions on export, import, or use of cryptography. Existing restrictions differ greatly between countries [Chan94a, Chan94b, Hoff93, Info94]. Some countries control domestic use of cryptography, and some do not. Some regulate communication of enciphered data across their borders. Some control export of encryption equipment, and some control import. For example, the U.S. places few restrictions on domestic use. But the U.S. restricts export of cryptography designed only to provide integrity and authentication services, and stringently restricts export of cryptography that can be used for confidentiality service. In the short term, Internet standards can minimize the effect of existing restrictions by using cryptography in a focused way. For example, if authentication and integrity service suffice to meet security needs in some protocol, then confidentiality service should not be included gratuitously. In the long term, the effect of international trade controls should fade. There is no inherent reason why protocol implementations must originate in a single country and be exported to other countries. Protocols and cryptography are being independently implemented today in many countries. Also, the strong trend to electronic commerce throughout the world may cause international standardization and subsequent relaxation of technology restrictions. Similarly, many cryptographic algorithms, especially asymmetric algorithms, are patented, but Internet protocols should not avoid using a technology only because patent rights have been asserted in some countries. The situation with cryptographic patents is similar to that with trade controls. That is, not all algorithms are patented in all countries; parallel, independent implementations in different countries are both possible and customary in the Internet; and patents eventually expire. Thus, use of patented technology in Internet standards should not be precluded so long as the licensing conditions are reasonable and non-discriminatory, as specified in [RFC1602]. Still, Internet protocols should avoid using patented technology whenever there is an appropriate substitute technology that is unrestricted. Internet standards should also avoid encryption algorithms and other technologies that are commercially proprietary, governmentally sensitive, militarily restricted (i.e., "classified"), or otherwise prevented from being publicly disclosed. Such conditions preclude open peer review that is fundamental to Internet standards development and high-quality security. --------- [Chan94a] J. P. Chandler, D. C. Arrington, D. R. Berkelhammer, W. L. Gill, Identification and Analysis of Foreign Laws and Regulations Pertaining to the Use of Commercial Encryption Products for Voice and Data Communications, National Intellectual Property Law Institute and The George Washington University, Washington, D.C., for U.S. National Institute of Standards and Technology, January 1994. [Chan94b] -----, Review and Analysis of U.S. Laws, Regulations, and Case Laws Pertaining to the Use of Commercial Encryption Products for Voice and Data Communications, -----, January 1994. [Hoff93] L. J. Hoffman, Faraz A. Ali, Steven L. Heckler, Ann Huybrechts, Cryptography: Policy and Technology Trends, The George Washington University, Washington, DC, for U.S. National Institute of Standards and Technology, 5 December 1993. [Hoff93] L. J. Hoffman, Faraz A. Ali, Steven L. Heckler, Ann Huybrechts, Cryptography: Policy and Technology Trends, The George Washington University, Washington, DC, for U.S. National Institute of Standards and Technology, 5 December 1993. [Info94] "Encryption's International Labyrinth", Infosecurity News, January/February 1994, pp. 26-30. Regards, -Rob- Robert W. Shirey SHIREY@MITRE.ORG tel 703.883.7210, sec 703.883.5749, fax 703.883.1397 Info. Security Div., The MITRE Corp., Mail Stop Z231 7525 Colshire Drive, McLean, Virginia 22102-3481 USA ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 13 12:10:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24392; Mon, 13 Mar 95 12:10:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24386; Mon, 13 Mar 95 12:09:12 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02223; Mon, 13 Mar 1995 12:00:17 -0800 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA07981; Mon, 13 Mar 95 12:00:11 PST Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA07037; Mon, 13 Mar 95 13:20:09 EST Received: from cabernet.wellfleet by wellfleet (4.1/SMI-4.1) id AA02695; Mon, 13 Mar 95 13:24:59 EST Date: Mon, 13 Mar 95 13:24:59 EST From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9503131824.AA02695@wellfleet> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) True Internationalism Cc: perry@imsi.com, Bill.Simpson@um.cc.umich.edu Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > "William Allen Simpson" says: > > > > BTW, do you use PGP? Phil Zimmerman is actually on _trial_ now for a > > possible 10 year sentence and $1,000,000 fine. > > > > He's not yet on trial -- he hasn't even been formally charged yet, > although I suspect he will be. My apologies in advance for wandering a bit off of the strictly technical topic, but this subject has hit an extremely sore nerve on my part. Even if he's not on trial *yet* (and even if he ends up being acquited) I still found Bill's note to be truely terrifying. Under the circumstances I would not blame Bill if he were tempted to exagerate a little, but even if things are only half as bad as Bill said then we have a system seriously gone beserk. I have seen big intrusive governments do truely horrid things on multiple occasions, so perhaps this is not at all surprising, but it is still bad (I will bring a bunch of my "I vote for LESS GOVERNMENT" bumper stickers to hand out at the IETF, in case anyone is driven by this mess to put one on their car). In terms of the standard, I strongly agree that we have no choice, we have to produce a standard which it technically sound, and which includes whatever security is necessary in order for the Internet to work. It bothers me *a lot* that we are therefore pushed to a standard which is not exportable (or whose state of exportability is incomprehensible to mere engineers). Sadly, given the amount that this has been discussed over the past several years without being fixed, my personal "wild guess" is that this is not likely to be fixed unless congress sees engineering jobs leaving to other countries as a result of the non-exportability. I don't see any solution, except perhaps to suggest that everyone write to their congressman and point out the technical requirement for security in the Internet. One thing that I am not clear on: What are the associated laws regarding export between other countries? Are products that include encryption going to need to be implemented twice (once in the US and once outside), or are they going to have to be implemented separately in every country, and not at all in a few countries? If the implementation of a standard encryption package is done separately in each country, then am I correct in assuming that we can at least send encrypted contents legally between countries? Ross ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 13 12:28:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24417; Mon, 13 Mar 95 12:28:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24398; Mon, 13 Mar 95 12:20:26 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03659; Mon, 13 Mar 1995 12:11:46 -0800 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU) by Sun.COM (sun-barr.Sun.COM) id AA02249; Mon, 13 Mar 95 12:11:25 PST Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA23262; Mon, 13 Mar 95 12:16:41 EST Received: by dcl.MIT.EDU (5.0/4.7) id AA19194; Mon, 13 Mar 1995 12:16:40 +0500 Date: Mon, 13 Mar 1995 12:16:40 +0500 From: Theodore Ts'o Message-Id: <9503131716.AA19194@dcl.MIT.EDU> To: bound@zk3.dec.com Cc: Theodore Ts'o , ipng@sunroof.Eng.Sun.COM, ipsec@ans.net In-Reply-To: bound@zk3.dec.com's message of Mon, 13 Mar 95 11:02:19 -0500, <199503131607.AA16846@interlock.ans.net> Subject: (IPng) Re: A plea for peace.... Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 13 Mar 95 11:02:19 -0500 From: bound@zk3.dec.com Please send me what you call a flame. I can't see it. The message I was referring to was dated March 11, 1995 at 00:21:31 GMT-5, subject line "Re: (IPng) Re: The besty". - Ted ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 13 13:13:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24459; Mon, 13 Mar 95 13:13:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24453; Mon, 13 Mar 95 13:13:39 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09165; Mon, 13 Mar 1995 13:05:15 -0800 Received: from amdext.amd.com by Sun.COM (sun-barr.Sun.COM) id AA09772; Mon, 13 Mar 95 13:03:15 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA05206 (5.67a/IDA-1.5+AMD for ); Mon, 13 Mar 1995 12:49:38 -0800 Received: from brahms.amd.com by amdint.amd.com with SMTP id AA19986 (5.67a/IDA-1.5+AMD for ); Mon, 13 Mar 1995 12:49:37 -0800 Received: from angelo.amd.com by brahms.amd.com (4.1/AMDSN-1.18) id AA15721; Mon, 13 Mar 95 12:48:52 PST Received: by angelo.amd.com (4.1/AMDC-1.18) id AA14964; Mon, 13 Mar 95 12:49:35 PST From: David.Roberts@amd.com (Dave Roberts) Message-Id: <9503132049.AA14964@angelo.amd.com> Subject: Re: (IPng) True Internationalism To: ipng@sunroof.Eng.Sun.COM Date: Mon, 13 Mar 1995 12:49:34 -0800 (PST) In-Reply-To: <9503131824.AA02695@wellfleet> from "Ross Callon" at Mar 13, 95 01:24:59 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Even if he's not on trial *yet* (and even if he ends up being > acquited) I still found Bill's note to be truely terrifying. > Under the circumstances I would not blame Bill if he were > tempted to exagerate a little, but even if things are only > half as bad as Bill said then we have a system seriously gone > beserk. I have seen big intrusive governments do truely horrid > things on multiple occasions, so perhaps this is not at all > surprising, but it is still bad (I will bring a bunch of my > "I vote for LESS GOVERNMENT" bumper stickers to hand out at the > IETF, in case anyone is driven by this mess to put one on their > car). Agreed that this is scary stuff. I'm in for one of those bumper stickers. :-) > One thing that I am not clear on: What are the associated laws > regarding export between other countries? Not that I'm an expert, but we did some digging on stuff like this for 802.11 wireless LAN. Laws vary, but most of the rest of the world seems to be more rational about this stuff than the US. Other governments tend to realize that this stuff is out there, whether or not they "allow" it to be. The "kiddie porn" (this *always* seems to come up as a great example of why crypto should be outlawed) people will use it whether or not governments allow its export. France seems to be worse than the US in that it doesn't even allow crypto to be *imported* (US says coming in is okay, going out is not). I belive Singapore is also more restrictive. > Are products that > include encryption going to need to be implemented twice (once > in the US and once outside), or are they going to have to be > implemented separately in every country, and not at all in a > few countries? The answer is yes. I mean, the stupid thing about the whole situation is that the knowledge to produce this stuff exists even if the implementations aren't allowed across borders. It's not like nobody in other countries doesn't know how to implement DES, IDEA, RSA, etc. Even if they didn't, all they'd have to do is come to the US and photocopy a few pages from "Applied Cryptography" (excellent book, BTW, and highly recommended reading for those interested in the technical aspects of crypto). Of course, exporting those would be illegal, but I have no doubts that the "enemies of the US" would stoop to such nasty behaviour in order to protect their secrets. Not to mention the fact that IDEA was developed outside the US anyway... > If the implementation of a standard encryption > package is done separately in each country, then am I correct > in assuming that we can at least send encrypted contents legally > between countries? As far as I know, this doesn't seem to be a problem with the US. I don't know about other countries. DES is the defacto world-wide standard for bank wire transfers, I believe (someone correct me if I'm wrong), so I assume that other countries allow this traffic to pass. Anyway, it sounds like Bill and several other people have been up to their necks in this stuff for quite some time, and so could probably comment on the specifics better than I. Dave Roberts Advanced Micro Devices, Inc. I/O and Network Products Division david.roberts@amd.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 13 15:04:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24535; Mon, 13 Mar 95 15:04:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24529; Mon, 13 Mar 95 15:04:25 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20056; Mon, 13 Mar 1995 14:56:54 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA00169; Mon, 13 Mar 95 14:56:07 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12193; 13 Mar 95 17:50 EST 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 Subject: (IPng) I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt Date: Mon, 13 Mar 95 17:50:05 -0500 Message-Id: <9503131750.aa12193@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Addressing Architecture Author(s) : R. Hinden Filename : draft-ietf-ipngwg-ipv6-addr-arch-00.txt Pages : 18 Date : 03/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 document editor would like to acknowledge the contributions of Paul Francis, Steve Deering, Jim Bound, Brian Carpenter, Bob Gilligan, Christian Huitema, Greg Minshall, Erik Nordmark, Bill Simpson, and Sue Thomson. Special mention is also given to Yakov Rekhtor, Tony Li, Deborah Estrin, and Peter Ford for the current definition of region addresses. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-addr-arch-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-addr-arch-00.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) 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-ipv6-addr-arch-00.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: <19950310110518.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-addr-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-addr-arch-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950310110518.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 13 16:00:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24692; Mon, 13 Mar 95 16:00:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24686; Mon, 13 Mar 95 16:00:14 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28878; Mon, 13 Mar 1995 15:52:43 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA09391; Mon, 13 Mar 95 15:43:41 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA27273; Tue, 14 Mar 1995 10:42:54 +1100 (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 AA18064; Tue, 14 Mar 95 09:25:33 +1000 Received: by dcthq2.datacraft.com.au; Tue, 14 Mar 95 10:41:07 +1100 Date: Tue, 14 Mar 95 10:34:59 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) my corrupt mail X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=YES Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM begin 600 attach.Z M'YV0:=R,>7/&31HZ;URTF7,&@,.'$"-*G$BQHL6+&"N"V&BC(P@`&T'$H$'C M8\B1)4&&7$DCAHV--6[,B!&C!@T8,F9LC"$C!DZ0,#(*'4JTJ-&)=>;0"2-G M(P`V;\:$87.4(E2I5*MJWO8+7**0.B39ZR8=*P<0$B"1T0:>:`@%-& MSI@R:>R4(0."#IHP;P^"B#JFCARY=]"4<0-BSILV9=ZX(3MG,1FY84`T2=*D M2-DR<^:$.4-601@W?,VB55L7!(HD`@D:1`C"#M,T9>CD20&"3)DQ:7S+I3W0 MC5XY;U6/G0-'3,^<9HQ:!K7H?X&N=S-G<'E!AQUT.%"`PH\(5![9Z3%V'1O0'4& M;G,"):H0%@HIJCBBBRVZ.*+,,8HXXPTUFCC MC3CFJ...//;HXX]`!BGDD$06:>212":IY)),-NGDDU!&*>645%9IY9589JGE MEEQVZ>678(8IYIADEFGFF6BFJ>::;+;IYIMPQBGGG'36:>>=>.:IYYY\]NGG ?GX`&*NB@A!9JZ*&()JKHHHPVZNBCD$8JZ:245FIIG736 ` end ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 13 19:53:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25052; Mon, 13 Mar 95 19:53:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25046; Mon, 13 Mar 95 19:53:37 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26053; Mon, 13 Mar 1995 19:46:05 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA02352; Mon, 13 Mar 95 19:46:01 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA20571; Tue, 14 Mar 1995 08:40:44 +1100 (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 AA17612; Tue, 14 Mar 95 07:25:05 +1000 Received: by dcthq2.datacraft.com.au; Tue, 14 Mar 95 8:40:19 +1100 Date: Tue, 14 Mar 95 8:38:18 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: re re re re4 (IPng) last call X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=YES Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM begin 600 attach.Z M'YV0:=R,>7/&31HZ;URTF7,&@,.'$"-*G$BQHL6+&"N"V&BC(P@`&T'$H$'C M8\B1)4&&7#D#AHV--6[,B!%C1DP8,S;&D!$#!@V0,#(*'4JTJ-&)=>;0"2-G M(P`V;\:$87.4(E2I5*MJWO8+6*"$BGC)R!;N@$+)-V*H@@5)J(`!'& M#1D04.?,`4$0Q)DR!.6$@8,FS1@08M[4L212":IY)),-NGDDU!&*>645%9IY9589JGE 2EEQVZ>678(8IYIADEFGFF0$" ` end ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 13 20:08:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25067; Mon, 13 Mar 95 20:08:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25061; Mon, 13 Mar 95 20:07:55 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27099; Mon, 13 Mar 1995 20:00:10 -0800 Received: from mail1.digital.com by Sun.COM (sun-barr.Sun.COM) id AA05772; Mon, 13 Mar 95 20:00:11 PST Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 2/22/95 for V3.2/1.0/WV) id AA13447; Mon, 13 Mar 1995 19:46:04 -0800 Received: by xirtlu.zk3.dec.com; id AA01586; Mon, 13 Mar 1995 22:45:19 -0500 Message-Id: <9503140345.AA01586@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipsec@ans.net Subject: Re: (IPng) Principle Statement on Patents and Exports In-Reply-To: Your message of "Mon, 13 Mar 95 09:21:12 EST." Date: Mon, 13 Mar 95 22:45:13 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM thank you Robert, /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 13 22:10:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25175; Mon, 13 Mar 95 22:10:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25169; Mon, 13 Mar 95 22:10:14 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02245; Mon, 13 Mar 1995 22:02:42 -0800 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA23042; Mon, 13 Mar 95 22:02:34 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Tue, 14 Mar 1995 15:46:34 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Tue, 14 Mar 1995 15:47:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Tue, 14 Mar 1995 15:44:34 +1000 Date: Tue, 14 Mar 1995 15:44:34 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Mar 14 15:44:33 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 334415140395 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <334415140395*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Subject: Re: (IPng) Export controls on Crypto stuff Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> People talk here of American Standard DES and I wonder >> why Australian Standard DES can't be used? It is the same standard >> after all (based on the ANSI). >Actually, I haven't seen any references to "American Standard DES" -- >just references to the "official" DES publications: I apologise. I was referring to traffic on this list that has made mention to American Standard DES (Ran has done so from time to time). >Is there a better reference that we could use? I can't find a better one. But as long as the FIPS are and remain available worldwide I can live with it. There was some talk of closed European standards a while ago. >> This should become a key component of the IP6 security design to allow >> the whole thing to work. You can't have a network that uses one >> standard in parts of the world and not in others. >Is Australia's version any different? Not that I can tell. It is based on ANSI X3.92 & X3.109. >> For instance, the >> Australian Government has no problems getting an export licence but >> sections of the community can't. What does that do to IP6 in >> Australia? > >What has this to do with a standard part? The part is standard, the >export is politics. True but selection and design are tied up in the politics. >Sections of the US community can't export, either. That doesn't mean >that import is disallowed. This has merely caused most US >manufacturers to build overseas, costing US jobs. I was merely stating the obvious here. The use of the standards, APIs etc. brings economic pressure to problem. Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 13 22:35:46 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25237; Mon, 13 Mar 95 22:35:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25231; Mon, 13 Mar 95 22:35:39 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03271; Mon, 13 Mar 1995 22:28:06 -0800 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA25283; Mon, 13 Mar 95 22:28:04 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Tue, 14 Mar 1995 16:17:40 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Tue, 14 Mar 1995 16:18:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Tue, 14 Mar 1995 16:14:33 +1000 Date: Tue, 14 Mar 1995 16:14:33 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Mar 14 16:14:33 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 331416140395 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <331416140395*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Subject: Re[2]: (IPng) Principle Statement on Patents and Exports Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >thank you Robert, >/jim I did not get what whatever it was you are thanking for. Can you send it again? Ta Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 01:25:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25270; Tue, 14 Mar 95 01:25:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25264; Tue, 14 Mar 95 01:25:19 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10460; Tue, 14 Mar 1995 01:17:49 -0800 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA13832; Tue, 14 Mar 95 01:17:42 PST Received: by mitsou.inria.fr (8.6.10/8.6.10) id KAA18555; Tue, 14 Mar 1995 10:17:36 +0100 Message-Id: <199503140917.KAA18555@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Cc: ipsec@ans.net Subject: Re: (IPng) Re: The besty In-Reply-To: Your message of "Mon, 13 Mar 1995 11:12:03 EST." <9503131612.AA12105@xirtlu.zk3.dec.com> Date: Tue, 14 Mar 1995 10:17:34 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, We all know that we cannot find a crypto-algorithm that is acceptable by all governments (including France, Irak and Russia) and exportable from all countries (including the US). The IAB, the IESG, sevral working groups and research groups discussed the issue at length. There is however a wide recognition that: * we might allow sites to pick any algorithm on a bilateral basis. IDEA and triple DES come out as very reasonable choices. But in order for negotiations to converge, we need one fall common ball-back. * DES in CBC mode has good properties for selection as a common fall back. The specs are public (courtesy of the US govt), hardware and software are available, even public domain software from Finland. * Yes, export control is a pain. But there are at least two turnarounds. Big companies can develop in a country which does not restrict export, which I understand DEC is doing in Israel. Small companies can peer with local partners which add the crypto-stuff in their own country. * Overall, the gain of a common spec is worth the pain. Now, I wish we could get the silly export control restrictions removed, not to mention the absurd usage restrictions of France. But that seems more a task for the EFF or the ISOC than for the IETF. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 01:39:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25286; Tue, 14 Mar 95 01:39:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25280; Tue, 14 Mar 95 01:39:09 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11016; Tue, 14 Mar 1995 01:31:38 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA15200; Tue, 14 Mar 95 01:31:34 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA20826; Tue, 14 Mar 1995 08:47:40 +1100 (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 AA17638; Tue, 14 Mar 95 07:31:28 +1000 Received: by dcthq2.datacraft.com.au; Tue, 14 Mar 95 8:46:44 +1100 Date: Tue, 14 Mar 95 8:44:24 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: Re: (IPng) National Registry of Routing is Har X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=YES Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM begin 600 attach.Z M'YV0:=R,>7/&31HZ;URTF7,&@,.'$"-*G$BQHL6+&"N"V&BC(P@`&T'$H$'C M8\B1)4&&7"G#!HR--6[,B!%CAHT:,$J*E!$#Q@R0,#(*'4JTJ-&)=>;0"2-G M(P`V;\:$87.4(E2I5*MJWO8+6V"3,GS-(U84"T`)$$2LDP9,C(*3-G M3L`S(.Z\D;/F;MXR;-C\:*"`L)LW=$"8D?.F35XT9>:R!:$TC!LR+$`<;IK6 M3)D[(.B@>9/4,AD0B"'+F>,"!),RB:>^L1P:LD@8R4"?T&Q-R!;LRD.5-',D*V4&RX($Q82IDS3,GD#L+&,I`G>A2$7<^^ MO?OW\./+GT^_OOW[^//KW\^_O___``8HX(`$%FC@@0@FJ.""##;HX(,01BCA MA!16:.&%&&:HX88<=NCAAR"&*.*())9HXHDHIJCBBBRVZ.*+,,8HXXPTUFCC MC3CFJ...//;HXX]`!BGDD$06:>212":IY)),-NGDDU!&*>645%9IY9589JFE !@CCF ` end ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 02:18:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25325; Tue, 14 Mar 95 02:18:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25319; Tue, 14 Mar 95 02:17:52 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12734; Tue, 14 Mar 1995 02:10:08 -0800 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA19031; Tue, 14 Mar 95 02:09:54 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) True Internationalism To: ipng@sunroof.Eng.Sun.COM Date: Tue, 14 Mar 1995 10:12:26 +0000 (GMT) In-Reply-To: <9503132049.AA14964@angelo.amd.com> from "Dave Roberts" at Mar 13, 95 12:49:34 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > will use it whether or not governments allow its export. France seems > to be worse than the US in that it doesn't even allow crypto to be > *imported* (US says coming in is okay, going out is not). I belive > Singapore is also more restrictive. I can import cryptography into france. The EEC single european market has its uses. The french thing is targetted at _use_ rather than posession or development. > implementations aren't allowed across borders. It's not like nobody > in other countries doesn't know how to implement DES, IDEA, RSA, etc. > Even if they didn't, all they'd have to do is come to the US and > photocopy a few pages from "Applied Cryptography" (excellent book, IDEA, DES, RSA are all available freely outside the USA. > As far as I know, this doesn't seem to be a problem with the US. I > don't know about other countries. DES is the defacto world-wide > standard for bank wire transfers, I believe (someone correct me if I'm > wrong), so I assume that other countries allow this traffic to pass. Technically not France it would seem. Besides which everyone is now pretty worried that DES isn't good enough for 'real' work. The current approach of allowing choice of systems, making encryption a standard but not 'MUST' facility seems to be precisely the right path to follow. People can then educate their governments or get cracked. As time goes on if the internet becomes the commercial hub of the planet then countries which block the encryption critical to such use will suffer they way governments understand - financially. I like the current ESP situation and I think its about the best that can be done for now. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 05:10:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25420; Tue, 14 Mar 95 05:10:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25414; Tue, 14 Mar 95 05:10:39 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25294; Tue, 14 Mar 1995 05:01:26 -0800 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA12639; Tue, 14 Mar 95 05:01:17 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Tue, 14 Mar 1995 22:56:14 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Tue, 14 Mar 1995 22:57:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Tue, 14 Mar 1995 22:53:51 +1000 Date: Tue, 14 Mar 1995 22:53:51 +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 Mar 14 22:53:51 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 515322140395 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <515322140395*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof2.Eng.Sun.COM (Non Receipt Notification Requested) Subject: Re[2]: (IPng) True Internationalism Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >. The current approach of allowing choice of systems, making encryption a >standard but not 'MUST' facility seems to be precisely the right path to >follow. People can then educate their governments or get cracked. As time >goes on if the internet becomes the commercial hub of the planet then It is the open API set that is important. The US restrictions are unpleasant but if the technology is available from other sources, it can be lived with. To enable the Internet to grow then the standards are the key to prevent the market being stymied. What I don't see at present is how you can use more than one (at most a few) algorithms in a network and still have openish interconnection? Not to mention key management (duck!). Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 06:11:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25477; Tue, 14 Mar 95 06:11:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25471; Tue, 14 Mar 95 06:11:15 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29220; Tue, 14 Mar 1995 06:02:49 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA22718; Tue, 14 Mar 95 06:02:44 PST Received: from relay.imsi.com by wintermute.imsi.com id JAA13849 for ; Tue, 14 Mar 1995 09:02:43 -0500 Received: from snark.imsi.com by relay.imsi.com id JAA20618 for ; Tue, 14 Mar 1995 09:02:42 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA02460; Tue, 14 Mar 95 09:02:41 EST Message-Id: <9503141402.AA02460@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: Re[2]: (IPng) True Internationalism In-Reply-To: Your message of "Tue, 14 Mar 1995 22:53:51 +1000." <515322140395*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Mar 1995 09:02:41 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jeff.Latimer@FINANCE.ausgovfinance.telememo.au says: > It is the open API set that is important. The US restrictions are > unpleasant but if the technology is available from other sources, it can be > lived with. To enable the Internet to grow then the standards are the key > to prevent the market being stymied. Ditto. There are already companies that do development work outside the US so that they can sell their products worldwide. If operating system manufacturers end up having to do their final network stack integration in, say, New Zealand, well, thats not such a horrible thing. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 09:07:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25559; Tue, 14 Mar 95 09:07:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25547; Tue, 14 Mar 95 09:07:12 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12974; Tue, 14 Mar 1995 08:58:46 -0800 Received: from amdext.amd.com by Sun.COM (sun-barr.Sun.COM) id AA26592; Tue, 14 Mar 95 08:54:11 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA25801 (5.67a/IDA-1.5+AMD for ); Tue, 14 Mar 1995 08:53:24 -0800 Received: from brahms.amd.com by amdint.amd.com with SMTP id AA20122 (5.67a/IDA-1.5+AMD for ); Tue, 14 Mar 1995 08:53:22 -0800 Received: from angelo.amd.com by brahms.amd.com (4.1/AMDSN-1.18) id AA00405; Tue, 14 Mar 95 08:52:35 PST Received: by angelo.amd.com (4.1/AMDC-1.18) id AA23519; Tue, 14 Mar 95 08:53:21 PST From: David.Roberts@amd.com (Dave Roberts) Message-Id: <9503141653.AA23519@angelo.amd.com> Subject: Re: (IPng) True Internationalism To: ipng@sunroof.Eng.Sun.COM Date: Tue, 14 Mar 1995 08:53:21 -0800 (PST) In-Reply-To: from "Alan Cox" at Mar 14, 95 10:12:26 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > will use it whether or not governments allow its export. France seems > > to be worse than the US in that it doesn't even allow crypto to be > > *imported* (US says coming in is okay, going out is not). I belive > > Singapore is also more restrictive. > > I can import cryptography into france. The EEC single european market has > its uses. The french thing is targetted at _use_ rather than posession or > development. Alan, I'm not sure what you mean here about "use." Could you elaborate further on what France does and doesn't allow? I can bring it in but I can't use it? What if I developed it in France? > > implementations aren't allowed across borders. It's not like nobody > > in other countries doesn't know how to implement DES, IDEA, RSA, etc. > > Even if they didn't, all they'd have to do is come to the US and > > photocopy a few pages from "Applied Cryptography" (excellent book, > > IDEA, DES, RSA are all available freely outside the USA. Right. I was just making the point that even if the US government embargo had somehow stopped this knowledge from leaking outside of US borders that it would be easy to come inside US borders, educate one's self, and then leave with that knowledge. Thus it's pretty stupid to disallow its export. > > standard for bank wire transfers, I believe (someone correct me if I'm > > wrong), so I assume that other countries allow this traffic to pass. > > Technically not France it would seem. Besides which everyone is now pretty > worried that DES isn't good enough for 'real' work. The current approach > of allowing choice of systems, making encryption a standard but not 'MUST' > facility seems to be precisely the right path to follow. People can then > educate their governments or get cracked. As time goes on if the internet > becomes the commercial hub of the planet then countries which block the > encryption critical to such use will suffer they way governments understand > - financially. Agreed. This is a tidal wave and you either get out of the way or get swept away in it. Either way the right thing will happen eventually, it's just a matter of time and political pain thresholds. > I like the current ESP situation and I think its about the best that can > be done for now. Yup. Do the right thing and let others catch up when they can. Dave Roberts Advanced Micro Devices, Inc. I/O and Network Products Division david.roberts@amd.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 09:12:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25579; Tue, 14 Mar 95 09:12:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24398; Mon, 13 Mar 95 12:20:26 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03659; Mon, 13 Mar 1995 12:11:46 -0800 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU) by Sun.COM (sun-barr.Sun.COM) id AA02249; Mon, 13 Mar 95 12:11:25 PST Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA23262; Mon, 13 Mar 95 12:16:41 EST Received: by dcl.MIT.EDU (5.0/4.7) id AA19194; Mon, 13 Mar 1995 12:16:40 +0500 Date: Mon, 13 Mar 1995 12:16:40 +0500 From: Theodore Ts'o Message-Id: <9503131716.AA19194@dcl.MIT.EDU> To: bound@zk3.dec.com Cc: Theodore Ts'o , ipng@sunroof.Eng.Sun.COM, ipsec@ans.net In-Reply-To: bound@zk3.dec.com's message of Mon, 13 Mar 95 11:02:19 -0500, <199503131607.AA16846@interlock.ans.net> Subject: (IPng) Re: A plea for peace.... Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 13 Mar 95 11:02:19 -0500 From: bound@zk3.dec.com Please send me what you call a flame. I can't see it. The message I was referring to was dated March 11, 1995 at 00:21:31 GMT-5, subject line "Re: (IPng) Re: The besty". - Ted From owner-ipng@sunroof.Eng.Sun.COM Tue Mar 14 02:45:11 1995 Return-Path: Received: from sunroof2.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id CAA17441; Tue, 14 Mar 1995 02:45:07 -0800 Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25402; Tue, 14 Mar 95 02:52:30 PST Date: Tue, 14 Mar 95 02:52:30 PST Message-Id: <9503141052.AA25402@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 [Phil Karn ] Content-Length: 1443 X-Lines: 29 Status: RO From karn@unix.ka9q.ampr.org Tue Mar 14 02:52:18 1995 Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25396; Tue, 14 Mar 95 02:52:18 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14365; Tue, 14 Mar 1995 02:44:47 -0800 Received: from unix.ka9q.ampr.org by Sun.COM (sun-barr.Sun.COM) id AA23004; Tue, 14 Mar 95 02:44:41 PST Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.10/8.6.5) id CAA25035; Tue, 14 Mar 1995 02:48:34 -0800 Date: Tue, 14 Mar 1995 02:48:34 -0800 From: Phil Karn Message-Id: <199503141048.CAA25035@unix.ka9q.ampr.org> To: Danny.Nessett@Eng Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net In-Reply-To: <199503071827.AA21100@interlock.ans.net> (Danny.Nessett@Eng.Sun.COM) Subject: Re: Proposed message on perfect forward security >On the other hand, many other applications have no strong requirement for >perfect forward security. Examples of these fall generally into that class But this is not an argument against mechanisms that do provide perfect forward secrecy unless you can *prove* that the extra cost is unacceptable. As CPUs get faster, the authors of modexp routines get smarter, and the IPSEC group gets older, I find it increasing hard to justify developing lots of different algorithms. I'd much prefer to do one for the most general case and leave it at that. Phil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 09:13:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25591; Tue, 14 Mar 95 09:13:41 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25585; Tue, 14 Mar 95 09:13:34 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id JAA21956; Tue, 14 Mar 1995 09:03:53 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id JAA05979; Tue, 14 Mar 1995 09:03:35 -0800 Date: Tue, 14 Mar 1995 09:03:35 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503141703.JAA05979@elrond.Eng.Sun.COM> To: karn@unix.ka9q.ampr.org Subject: (IPng) Re: Proposed message on perfect forward security Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Phil, Responding to my comment : > > >On the other hand, many other applications have no strong requirement for > >perfect forward security. Examples of these fall generally into that class you observe : > But this is not an argument against mechanisms that do provide perfect > forward secrecy unless you can *prove* that the extra cost is > unacceptable. As CPUs get faster, the authors of modexp routines get > smarter, and the IPSEC group gets older, I find it increasing hard to > justify developing lots of different algorithms. I'd much prefer to > do one for the most general case and leave it at that. I gather from your wording that you mean "prove" in the market acceptance sense (i.e., products using key distribution mechanisms providing perfect forward security will be widely used), rather than the mathematical or formal logic sense. If so, then I think we agree. My arguments are not "against mechanisms that do provide perfect forward secrecy," but rather for allowing the marketplace to do its job. It is too early to tell just what the market will desire and so, I believe, it is imprudent to limit IPv6 to a single class of key distribution mechanisms, viz., only those employing out-of-band keying. Regards, Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 09:55:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25630; Tue, 14 Mar 95 09:55:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25624; Tue, 14 Mar 95 09:54:56 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16946; Tue, 14 Mar 1995 09:45:59 -0800 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA04699; Tue, 14 Mar 95 09:44:35 PST Received: by mitsou.inria.fr (8.6.10/8.6.10) id SAA19636; Tue, 14 Mar 1995 18:44:05 +0100 Message-Id: <199503141744.SAA19636@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) True Internationalism In-Reply-To: Your message of "Tue, 14 Mar 1995 08:53:21 PST." <9503141653.AA23519@angelo.amd.com> Date: Tue, 14 Mar 1995 18:44:04 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, this is not a place to debate the French regulation. For the gory details, you can have a look at http://web.cnam.fr/Network/Crypto/ Indeed, this is in French. But you don't expect the French laws to be debated in English, right? Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 10:17:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25680; Tue, 14 Mar 95 10:17:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25671; Tue, 14 Mar 95 10:17:38 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19346; Tue, 14 Mar 1995 10:08:51 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA08357; Tue, 14 Mar 95 10:04:22 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/24Feb95) id AA08647; Tue, 14 Mar 95 09:50:35 -0800 Received: by xirtlu.zk3.dec.com; id AA27315; Tue, 14 Mar 1995 12:49:11 -0500 Message-Id: <9503141749.AA27315@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: Re[2]: (IPng) Principle Statement on Patents and Exports In-Reply-To: Your message of "Tue, 14 Mar 95 16:14:33 +1000." <331416140395*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> Date: Tue, 14 Mar 95 12:49:05 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jeff, >>thank you Robert, >>/jim >I did not get what whatever it was you are thanking for. Can you send it >again? >Ta >Jeff See attached. /jim --------------------------------------------------- Return-Path: shirey@mitre.org Received: from decvax.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA12396; Mon, 13 Mar 1995 09:24:37 -0500 Received: from mwunix.mitre.org by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA21812; Mon, 13 Mar 1995 09:24:32 -0500 Return-Path: shirey@mitre.org Received: from smiley.sit (smiley.mitre.org [128.29.140.20]) by mwunix.mitre.org (8.6.10/8.6.4) with SMTP id JAA00530; Mon, 13 Mar 1995 09:21:54 -0500 Received: from [128.29.140.100] (shirey-mac) by smiley.sit (4.1/SMI-4.1) id AA04074; Mon, 13 Mar 95 09:21:12 EST Date: Mon, 13 Mar 95 09:21:12 EST X-Sender: shirey@smiley.mitre.org Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bound@zk3.dec.com From: shirey@mitre.org (Robert W. Shirey) Subject: Principle Statement on Patents and Exports Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net FYI. Adapted from draft-irtf-psrg-secarch-sect1-00.txt 3.5 Use of the Best Available Technology Internet standards should always employ the best available technology to provide high-quality security. National restrictions and patents sometimes make it hard to follow this principle, but a technology should not be avoided in an attempt to satisfy some countries in which the technology is restricted or patent rights are asserted. The rules differ too much among countries, and the rules keep changing. Any attempt to make Internet standards satisfy the rules of any particular set of governments would unnecessarily and unfairly restrict development and use of Internet technology in other countries. For example, the use of cryptography in Internet standards should not be limited just because of national restrictions on export, import, or use of cryptography. Existing restrictions differ greatly between countries [Chan94a, Chan94b, Hoff93, Info94]. Some countries control domestic use of cryptography, and some do not. Some regulate communication of enciphered data across their borders. Some control export of encryption equipment, and some control import. For example, the U.S. places few restrictions on domestic use. But the U.S. restricts export of cryptography designed only to provide integrity and authentication services, and stringently restricts export of cryptography that can be used for confidentiality service. In the short term, Internet standards can minimize the effect of existing restrictions by using cryptography in a focused way. For example, if authentication and integrity service suffice to meet security needs in some protocol, then confidentiality service should not be included gratuitously. In the long term, the effect of international trade controls should fade. There is no inherent reason why protocol implementations must originate in a single country and be exported to other countries. Protocols and cryptography are being independently implemented today in many countries. Also, the strong trend to electronic commerce throughout the world may cause international standardization and subsequent relaxation of technology restrictions. Similarly, many cryptographic algorithms, especially asymmetric algorithms, are patented, but Internet protocols should not avoid using a technology only because patent rights have been asserted in some countries. The situation with cryptographic patents is similar to that with trade controls. That is, not all algorithms are patented in all countries; parallel, independent implementations in different countries are both possible and customary in the Internet; and patents eventually expire. Thus, use of patented technology in Internet standards should not be precluded so long as the licensing conditions are reasonable and non-discriminatory, as specified in [RFC1602]. Still, Internet protocols should avoid using patented technology whenever there is an appropriate substitute technology that is unrestricted. Internet standards should also avoid encryption algorithms and other technologies that are commercially proprietary, governmentally sensitive, militarily restricted (i.e., "classified"), or otherwise prevented from being publicly disclosed. Such conditions preclude open peer review that is fundamental to Internet standards development and high-quality security. --------- [Chan94a] J. P. Chandler, D. C. Arrington, D. R. Berkelhammer, W. L. Gill, Identification and Analysis of Foreign Laws and Regulations Pertaining to the Use of Commercial Encryption Products for Voice and Data Communications, National Intellectual Property Law Institute and The George Washington University, Washington, D.C., for U.S. National Institute of Standards and Technology, January 1994. [Chan94b] -----, Review and Analysis of U.S. Laws, Regulations, and Case Laws Pertaining to the Use of Commercial Encryption Products for Voice and Data Communications, -----, January 1994. [Hoff93] L. J. Hoffman, Faraz A. Ali, Steven L. Heckler, Ann Huybrechts, Cryptography: Policy and Technology Trends, The George Washington University, Washington, DC, for U.S. National Institute of Standards and Technology, 5 December 1993. [Hoff93] L. J. Hoffman, Faraz A. Ali, Steven L. Heckler, Ann Huybrechts, Cryptography: Policy and Technology Trends, The George Washington University, Washington, DC, for U.S. National Institute of Standards and Technology, 5 December 1993. [Info94] "Encryption's International Labyrinth", Infosecurity News, January/February 1994, pp. 26-30. Regards, -Rob- Robert W. Shirey SHIREY@MITRE.ORG tel 703.883.7210, sec 703.883.5749, fax 703.883.1397 Info. Security Div., The MITRE Corp., Mail Stop Z231 7525 Colshire Drive, McLean, Virginia 22102-3481 USA ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 10:30:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25692; Tue, 14 Mar 95 10:30:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25686; Tue, 14 Mar 95 10:29:27 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20366; Tue, 14 Mar 1995 10:20:59 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA10385; Tue, 14 Mar 95 10:20:40 PST Received: from relay.imsi.com by wintermute.imsi.com id NAA14772; Tue, 14 Mar 1995 13:20:39 -0500 Received: from snark.imsi.com by relay.imsi.com id NAA22687; Tue, 14 Mar 1995 13:20:38 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA02896; Tue, 14 Mar 95 13:20:37 EST Message-Id: <9503141820.AA02896@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Your message of "Tue, 14 Mar 1995 09:03:35 PST." <199503141703.JAA05979@elrond.Eng.Sun.COM> X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Mar 1995 13:20:37 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan Nessett says: > allowing the marketplace to do its job. It is too early to tell just what > the market will desire and so, I believe, it is imprudent to limit IPv6 > to a single class of key distribution mechanisms, viz., only those employing > out-of-band keying. The problem is this, Dan. SKIP can't use the transforms defined for IPSP or the SAID mechanisms defined for IPSP. It can't support multiple keys between hosts, either. In short, you have this "neither fish nor foul" proposal out there that doesn't really have any demonstrable advantages and doesn't fit in with the rest of the architecture. In the guise of saying "we need to be flexible" you keep coming back and saying that you think that we should rip up the architecture to make SKIP more feasable. Well, I'm sorry, but so far as I can tell a SKIP implementation can't even share the transform code that is used for other key management mechanisms. The thing isn't a modular key management system -- its a proposal that really seeks to fundamentally alter the entire way IPSP was architected. .pm ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 10:38:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25707; Tue, 14 Mar 95 10:38:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25701; Tue, 14 Mar 95 10:38:13 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21100; Tue, 14 Mar 1995 10:29:27 -0800 Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AA00623; Tue, 14 Mar 95 10:29:22 PST Message-Id: <9503141829.AA00623@Sun.COM> From: smb@research.att.com Received: by gryphon; Tue Mar 14 13:13:31 EST 1995 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) True Internationalism Date: Tue, 14 Mar 95 13:13:30 EST Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > will use it whether or not governments allow its export. France s eems > > to be worse than the US in that it doesn't even allow crypto to be > > *imported* (US says coming in is okay, going out is not). I beliv e > > Singapore is also more restrictive. > > I can import cryptography into france. The EEC single european marke t has > its uses. The french thing is targetted at _use_ rather than posessi on or > development. Alan, I'm not sure what you mean here about "use." Could you elaborate further on what France does and doesn't allow? I can bring it in but I can't use it? What if I developed it in France? It's illegal to use encryption algorithms in France without government permission. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 10:49:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25736; Tue, 14 Mar 95 10:49:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25730; Tue, 14 Mar 95 10:49:13 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22730; Tue, 14 Mar 1995 10:39:57 -0800 Received: from by Sun.COM (sun-barr.Sun.COM) id AB02471; Tue, 14 Mar 95 10:38:26 PST Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950221.405.SGI.8.6.10/910110.SGI) for <@sgi.sgi.com:ipng@sunroof.eng.sun.com> id KAA14675; Tue, 14 Mar 1995 10:00:47 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) for <@sgihub.corp.sgi.com:ipng@sunroof.eng.sun.com> id KAA07885; Tue, 14 Mar 1995 10:00:07 -0800 Received: from gauss.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:ipng@sunroof.eng.sun.com id AA07939; Tue, 14 Mar 95 09:58:38 -0800 Received: from localhost by gauss.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA02396; Tue, 14 Mar 1995 10:00:05 -0800 Message-Id: <199503141800.KAA02396@gauss.asd.sgi.com> From: leedom@gauss.asd.sgi.com (Casey Leedom) To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Can *anyone* read Alan Lloyd's email??? Date: Tue, 14 Mar 1995 10:00:04 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I'm just wondering. Am I a minority in that my mail reader doesn't know how to automatically decode his ``Incognito-Format''? If so I guess his sending all these uuencoded, compressed and tar'ed turds with carriage-return line separators isn't absolutely worthless. So far though for me it's all just line noise -- the presentation, not the content -- and I wish he would use a more standard mail format. I've sent him two messages about this already. Casey ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 11:06:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25861; Tue, 14 Mar 95 11:06:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25855; Tue, 14 Mar 95 11:06:50 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25303; Tue, 14 Mar 1995 10:59:17 -0800 Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA01816; Tue, 14 Mar 95 10:58:55 PST Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA11189 for ipng@sunroof.eng.sun.com; Tue, 14 Mar 95 12:43:22 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id KAA15207; Tue, 14 Mar 1995 10:58:31 -0800 Message-Id: <199503141858.KAA15207@aland.bbn.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Can *anyone* read Alan Lloyd's email??? In-Reply-To: Your message of Tue, 14 Mar 95 10:00:04 -0800. <199503141800.KAA02396@gauss.asd.sgi.com> From: Craig Partridge Date: Tue, 14 Mar 95 10:58:30 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Casey: Gee -- I hadn't realized there was intended content -- I'd just assumed his mailer was broken (the frequency was low enough I decided not to worry about it). Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 11:21:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25880; Tue, 14 Mar 95 11:21:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25874; Tue, 14 Mar 95 11:21:15 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27232; Tue, 14 Mar 1995 11:13:41 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA04913; Tue, 14 Mar 95 11:12:08 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA20417; Tue, 14 Mar 95 11:08:02 -0800 Received: by xirtlu.zk3.dec.com; id AA00494; Tue, 14 Mar 1995 14:07:59 -0500 Message-Id: <9503141907.AA00494@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Can *anyone* read Alan Lloyd's email??? In-Reply-To: Your message of "Tue, 14 Mar 95 10:00:04 PST." <199503141800.KAA02396@gauss.asd.sgi.com> Date: Tue, 14 Mar 95 14:07:53 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I am having the same issue as Casey with Alan's mail. I don't have MIME at my end if thats what it is? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 11:38:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25895; Tue, 14 Mar 95 11:38:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25889; Tue, 14 Mar 95 11:38:01 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28837; Tue, 14 Mar 1995 11:29:16 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA06839; Tue, 14 Mar 95 11:24:48 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/24Feb95) id AA12666; Tue, 14 Mar 95 10:48:05 -0800 Received: by xirtlu.zk3.dec.com; id AA29548; Tue, 14 Mar 1995 13:46:39 -0500 Message-Id: <9503141846.AA29548@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Your message of "Tue, 14 Mar 95 13:20:37 EST." <199503141820.AA37743@interlock.ans.net> Date: Tue, 14 Mar 95 13:46:33 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan, Technical Questions: 1. To reveiw: Will in-band keying work with the present IPv6 specs (Rans work) without changes to the specifications? Not just SKIP (see next question). 2. Are there multiple ways to use in-band keying besides SKIP? I am asking this because I believe in-band keying should be something vendors should be able to build as a key-management solution. I am assuming SKIP is only one way to use in-band keying and others can exist too? 3. Can't we discuss this without mention of SKIP so that we can make sure either in-band or out-band can be used? I think its important we get to the heart of the architectural issues technically of the in/out modes and not get hung up on actual mechanisms? Or is this not a good idea? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 11:39:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25924; Tue, 14 Mar 95 11:39:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25909; Tue, 14 Mar 95 11:39:02 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28920; Tue, 14 Mar 1995 11:29:58 -0800 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA07164; Tue, 14 Mar 95 11:28:39 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) True Internationalism To: ipng@sunroof.Eng.Sun.COM Date: Tue, 14 Mar 1995 19:24:07 +0000 (GMT) In-Reply-To: <9503141653.AA23519@angelo.amd.com> from "Dave Roberts" at Mar 14, 95 08:53:21 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Alan, I'm not sure what you mean here about "use." Could you > elaborate further on what France does and doesn't allow? I can bring > it in but I can't use it? What if I developed it in France? As I understand it you can develop it but not use it for encryption over public telecomms without registering the keys with the government. Talk to the french authorities for clarification of this. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 11:51:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25960; Tue, 14 Mar 95 11:51:16 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25954; Tue, 14 Mar 95 11:51:08 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id LAA00547; Tue, 14 Mar 1995 11:41:19 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id LAA06109; Tue, 14 Mar 1995 11:40:52 -0800 Date: Tue, 14 Mar 1995 11:40:52 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503141940.LAA06109@elrond.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net, bound@zk3.dec.com Subject: Re: (IPng) Re: Proposed message on perfect forward security X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, In regards to your questions : > > Technical Questions: > > 1. To reveiw: Will in-band keying work with the present IPv6 specs > (Rans work) without changes to the specifications? Not just SKIP > (see next question). No. In-band keying will not work with the present IPv6 specs. This issue is independent of SKIP. The problem is there is no place to indicate in either the AH or ESP that in-band keying is being used. > 2. Are there multiple ways to use in-band keying besides SKIP? > I am asking this because I believe in-band keying should be > something vendors should be able to build as a key-management > solution. I am assuming SKIP is only one way to use in-band keying > and others can exist too? SKIP is only one way to do in-band keying. Other possibilities exist. For example, Russ Housley has reported on these lists that the IEEE 802.10 standard for Secure Data Exchange (SDE) supports an in-band keying approach developed by DEC. I believe this approach could also be used for in-band keying for IPv6, but would defer on that to the original designers of the protocol or to someone on the IEEE 802.10 committee. As far as I know, SKIP is the only widely publicized in-band keying method proposed for IPv6, but I haven't had a chance to read the recent proposal by Hugo at IBM, so I could be wrong about that. > 3. Can't we discuss this without mention of SKIP so that we can > make sure either in-band or out-band can be used? I think its > important we get to the heart of the architectural issues > technically of the in/out modes and not get hung up on actual > mechanisms? Or is this not a good idea? I agree 100% that we should focus on the issue of in-band and out-of-band keying and not concentrate on SKIP. It is others on this list that continually make accusations about this being a purely SKIP issue. From my perspective the issue is more general. The IPv6 security documents should be written in such a way as not to preclude or even discourage the use of in-band keying. They should be general enough to allow both. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 12:40:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26061; Tue, 14 Mar 95 12:40:13 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26055; Tue, 14 Mar 95 12:40:06 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id MAA05686; Tue, 14 Mar 1995 12:32:31 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id MAA06133; Tue, 14 Mar 1995 12:32:14 -0800 Date: Tue, 14 Mar 1995 12:32:14 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503142032.MAA06133@elrond.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM, perry@imsi.com Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: ipsec@ans.net, bound@zk3.dec.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry, In an earlier message I point out : > > No. In-band keying will not work with the present IPv6 specs. This issue > > is independent of SKIP. The problem is there is no place to indicate in > > either the AH or ESP that in-band keying is being used. To which you reply : > Thats not true. > > The reserved SAIDs were envisioned for doing things like this. It > wasn't thought that we'd actually *want* to use them, but we did leave > in the flexibility just in case. > > So far as I can tell, using one of the reserved SAIDs, as has been > repeatedly proposed, would work just fine for you. This is not to say > that the mechanism is being encouraged, but it is possible. Given the > inability to reuse most of the rest of the protocol machinery, > however, I really don't see, overall, why you would even want to try > to get the round SKIP peg to fit into a square IPSP hole -- you need > all your own transforms, you don't use the SAIDs per se, etc, etc -- > for the most part, you aren't using the IPSP mechanisms at all. Allow me to quote from the current AH I-D : A 32-bit pseudo-random value identifying the security association for this datagram. If no security association has been established, the value of this field shall be 0x00000000. The set of SAID values in the range 0x00000001 through 0x000000FF are reserved for future use. There is similar language in the ESP I-D. I read this to mean that the reserved values are "reserved," i.e., not to be used, since they may be used for some unspecified purpose in the future. If the security documents are modified to indicate an SAID value that is to mean, "using in-band keying," then what you say would be true. However, at present it is not. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 14:34:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26212; Tue, 14 Mar 95 14:34:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26206; Tue, 14 Mar 95 14:34:30 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13818; Tue, 14 Mar 1995 14:25:46 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AB01881; Tue, 14 Mar 95 14:25:37 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/24Feb95) id AA27678; Tue, 14 Mar 95 14:23:17 -0800 Received: by xirtlu.zk3.dec.com; id AA10162; Tue, 14 Mar 1995 17:21:49 -0500 Message-Id: <9503142221.AA10162@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: (IPng) In-Band/Out-Band Moving to IPSEC list Date: Tue, 14 Mar 95 17:21:43 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM IPng List, It is mine and some others view we need a serious technical and architectural discussion of in-band and out-band to understand the engineering trade-offs to be made for IPv6 security. I am going to start such a thread on IPSEC mail list. If you want to participate you need to go an get on that mail list. I think this is focused enough to warrant the discussion in this manner. But I wanted folks here to know I have done this OK. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 14:42:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26237; Tue, 14 Mar 95 14:42:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26231; Tue, 14 Mar 95 14:41:31 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14207; Tue, 14 Mar 1995 14:28:22 -0800 Received: from by Sun.COM (sun-barr.Sun.COM) id AB01737; Tue, 14 Mar 95 14:28:06 PST Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 8199; Tue, 14 Mar 95 17:00:41 EST Received: by RTP (XAGENTA 4.0) id 0660; Tue, 14 Mar 1995 17:00:01 -0500 Received: by wchung.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA14127; Tue, 14 Mar 1995 15:56:33 -0500 Message-Id: <9503142056.AA14127@wchung.raleigh.ibm.com> To: ipng@sunroof.Eng.Sun.COM Cc: hinden@ipsilon.com Subject: Re: (IPng) Last Call for IPng Addressing Architecture Document In-Reply-To: (Your message of Thu, 09 Mar 95 17:22:58 PST.) Date: Tue, 14 Mar 95 15:56:32 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Overall, the document reads well. However, when I got to the region address section, things get confusing really fast. Rather than make detailed comments on that specific text at this point, let me first ask some general questions, in the hope that they clarify my understanding of regions. What exactly is an "anycast" address? The draft spec refers to them, but never defines them or provides a reference. (The draft needs to be changed to address this.) Ditto for "Routing Domain Confederation". >2.5 Region Addresses > >Region Addresses provide information abstraction for the purpose of >network layer routing. A subgraph of an internet forms a "Region" with >an identifier called a "Region-ID" if all the following conditions are >satisfied. > > 1. Associated with each Region is a globally unique identifier called > a Region-ID. Syntactically, a Region-ID is a 128-bit IPv6 unicast > address. Clear enough, at first glance. However, is a critical point perhaps *not* made? Specifically, is it (or is it not) the case that the addresses for all nodes within a region (excluding border gateways) contain the Region-ID number as an address prefix? If the answer is no, what is the canonical example used for justification? minor nits: >2.4.1 Unicast Address Examples > >An example of a Unicast address format which will likely to be common on ^^^^^ >LANs and other environments where IEEE 802 MAC addresses are available >is: "to be" -> "be" >This technique can be continued to allow a site or organization to add >additional layers of internal hierarchy. It may be desirable to use a ^ >interface ID smaller than a 48-bit IEEE 802 MAC address to allow more >space for the additional layers of internal hierarchy. These could be >interface IDs which are administratively created by the site or >organization. "a" -> "an" Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 15:54:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26455; Tue, 14 Mar 95 15:54:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26449; Tue, 14 Mar 95 15:54:28 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24715; Tue, 14 Mar 1995 15:46:53 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA06538; Tue, 14 Mar 95 15:46:31 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA22684; Wed, 15 Mar 1995 10:46:07 +1100 (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 AA21855; Wed, 15 Mar 95 09:30:19 +1000 Received: by dcthq2.datacraft.com.au; Wed, 15 Mar 95 10:45:58 +1100 Date: Wed, 15 Mar 95 9:28:22 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) comments on addressing docs X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM comments on ipv6 addressing architecture - draft ietf-ipngwg-ipv6-addr-00.txt section 2.0 Unicast: should the words "delivered to" say "routed to" because addresses imply routing algorithms and end points. Region : ditto eg "to a region address are routed to AN interface in that region". Multicast: ditto "Packets sent to a multicast address are where necessary copied, and routed to all the interfaces which provide routes to the assigned endpoints. Section 2.3 Whats this "Neutral Interconnect Based Unicast stuff? What was was wrong with good old "geographic"? Will this Neutral Interconnect stuff have the same fate as "cluster" and "pack"? As someone who deals with addressing every day why are these terms introduced. Addresses are where things are: they can be logical (implicit) or geographic - regions and countries - routing domains and subnets. I do have trouble with these vague terms which are totally unnecessary. Section 2.5 "Region addresses MUST NOT be used as a source address. what about SNMP traps, bootp, etc. Dont a region's border routers have addresses which are part of that region. Are not region addresses and "border routers" an abstraction for the purpose of administration? And NOW: The text which states that a " A routing domain is a region - is a confederation is an OSPF area is a IP6 subnet (items 1 through to 5). Should we just say..... A region is an abstraction of the address space for the purposes of administration and is represented by a Region Id. A routing domain, a confederation?, an OSPF area or an IPv6 subnet can be considered as a Region. Other comment Still not keen on this subscriber / provider stuff. Comments on draft-rekhter-stratum-aggregation-01.txt General I dont understand this stratum stuff either or what purpose it serves. section 7 para 3 I agree with. Its questionable. re document development. I would still like to keep addressing formats kept to routing levels and the administration of network addresses re allocation and network operational issues distinct. naturally using useful terms in this process helps. Comments on draft-simpson-ipv6-arch-exch-00.txt General 2.3 Agree The term Domains brings routing sanity into the addressing scheme. (not operational ownership). I support the concepts of regional, national and metropolitan level address admin points. Lets progress this. Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 16:24:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26572; Tue, 14 Mar 95 16:24:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26566; Tue, 14 Mar 95 16:24:02 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29723; Tue, 14 Mar 1995 16:16:28 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA12819; Tue, 14 Mar 95 16:16:13 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA18460; Wed, 15 Mar 1995 09:17:52 +1100 (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 AA21548; Wed, 15 Mar 95 08:02:14 +1000 Received: by dcthq2.datacraft.com.au; Wed, 15 Mar 95 9:17:58 +1100 Date: Wed, 15 Mar 95 9:13:16 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) test message re my mail X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gentlefolk, it seems the gateway we have is learned and remembers what mailer is being used by those in the wider community. However, not being a virgo it is not perfect and got confused about what was who. I hope it is now fixed and apologise most sincerly for its nervous breakdown (and almost causing mine). Please let me know nicely if this is buggered ..as it shouldnt be. regards and thanks alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 16:33:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26602; Tue, 14 Mar 95 16:33:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26596; Tue, 14 Mar 95 16:33:34 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01013; Tue, 14 Mar 1995 16:25:58 -0800 Received: from cayenne.cs.ucdavis.edu by Sun.COM (sun-barr.Sun.COM) id AA14771; Tue, 14 Mar 95 16:24:07 PST Received: by cayenne.cs.ucdavis.edu (4.1/UCD.CS.2.6) id AA12764; Tue, 14 Mar 95 14:59:33 PST Date: Tue, 14 Mar 95 14:59:33 PST From: rogaway@cs.ucdavis.edu (Phil Rogaway) Message-Id: <9503142259.AA12764@cayenne.cs.ucdavis.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 security - review of draft-atkinson-ipng-{sec,auth,esp} Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I sent these comments to this mailing list last Friday, but I'm told that the bits probably evaporated, since I was not a subscriber. I'll try again. The attached note is long. Among its criticisms: 1. Use of ESP should in no way be understood to imply integrity. 2. There is no security reason to encrypt message headers whose contents are non-secret. 3. Key separation should be paid attention to. 4. MAC_a(x)=MD5(a.x.a) is a marginal choice as the required message authentication code. 5. E_a(x) = (IV, DES-CBC_a(x)) is a marginal choice the required encryption mechanism. 6. We probably should have four required algorithms: {Enc-algorithm, Auth-algorithm} x {HW-efficient, SW-efficient}. Phil ........................................................................ 0 Phil Rogaway 10 March 1995 1 ----------------------------------------------------------------- 2 A. Comments on "IPv6 Security Architecture," by Randall Atkinson, 3 draft-atkinson-ipng-sec-01.txt, draft of 16 February 1995. 4 ----------------------------------------------------------------- 5 6 7 A.1.1. DEFINITIONS 8 9 You follow long-standing tradition in implying that there exist 10 distinct concepts of (cryptographic) message authentication and 11 (cryptographic) message integrity. In fact there is only one 12 underlying problem: you get a message and you believe or do not 13 believe that that particular message was sent by the claimed 14 originator. That there is only one concept here is apparent in a 15 formal treatment: the message authenticity goal is normally 16 understood to mean "no feasible existential forgery under adaptive 17 chosen message attack" (the symmetric version of the definition of 18 [Goldwasser, Micali, Rivest]). The message integrity goal means 19 the same thing. 20 21 I would thus advocate removing all subsequent references to message 22 integrity. For example: 23 24 3.3. COMBINING SECURITY MECHANISMS 25 Last line on page 5, strike "integrity": it should not in any 26 way be implied that the ESP provides integrity. After all, the 27 ideal encryption scheme of a one time pad provides no meaningful 28 integrity; and if this mechanism isn't a good ESP mechanism I'm not 29 sure what ought to be! 30 31 32 A.2. DESIGN OBJECTIVES 33 34 I question that use of the same algorithms as SNMPv2 be a DESIGN 35 OBJECTIVE. (If SNMPv2 has appropriate mechanisms then they should be 36 used; otherwise they should not.) 37 38 39 A.3. IPv6 SECURITY MECHANISMS 40 41 That the privacy mechanism of the ESP might provide authenticity is 42 of course true -- but for an architecture document I would do much 43 more to actively discourage any such attempted use of the ESP. 44 Instead, I would make the simple statement that if you want privacy 45 and authenticity BOTH, you should use BOTH an AH and an ESP. 46 47 My reluctance to admit in an architecture document that a privacy 48 mechanism MIGHT provide authenticity is that concrete proposed privacy 49 mechanisms invariably do NOT achieve message authenticity/integrity. 50 What is more, the original motivation for "including" authenticity in 51 a privacy mechanisms was to improve computational efficiency -- there 52 was a belief that a fast-to-compute "Manipulation Detection Code" 53 (MDC) could be included in the scope of a symmetric encryption 54 mechanism (e.g., DES-CBC) and the result would be to provide 55 authenticity AND privacy with total computational overhead less than 56 separate mechanisms would have taken. In retrospect, this belief 57 was probably wrong: I know of no correct mechanism for 58 privacy + authenticity which is faster to compute than a correct 59 mechanism for privacy + a correct mechanism for authenticity. 60 61 This same point comes up again, e.g. 3.2., first sentence. 62 63 64 A.3.1 AUTHENTICATION HEADER 65 66 I question keyed MD5 is a choice of a default MAC because: 67 68 a. Speed -- it's a few tens of instructions per word, and nothing 69 can ever be done about this. 70 71 b. Lack of parallelizability -- If you can compute MD5 in $x$ bps 72 using one MD5 chip then with two MD5 chips you can compute MD5 73 in ... $x$ bps. 74 75 c. "Foundation-less-ness" -- Though I don't know an attack on 76 MAC_a(x) = MD5(a.x.a), it should be made explicit that the 77 security of such a scheme has nothing to do with MD5 being 78 collision intractable, one-way, etc.. (Notation: MAC is for 79 "Message Authentication Code." MAC_a(x) is the tag for sting $x$ 80 using key $a$.) 81 82 I understand that there is not yet any concrete and attractive 83 alternative to something like MAC_a(x)=MD5(a.x.a), but I'm sure that 84 one can be found. I believe that the best approach lies in 85 Wegman-Carter Authentication (JCSS 1981, 265-279). Any version of 86 Wegman-Carter authentication will fix (b) and (c), and a 87 well-constructed scheme ought to improve on (a). As a sample 88 mechanism, look at the "CRC MAC" of [Krawczyk, Crypto '94]. More 89 efficient proposals are forthcoming. 90 91 92 A.STRUCT. Organization 93 94 More generally (and strictly as a point of organization) it is not 95 really the business of an architecture document to be describing ANY 96 particular mechanism. I'd say it is not clear that it is even the 97 place in the documents one level down. But if mechanisms are 98 described in the AH and ESP documents, it should be ONLY in an 99 appendix or section which does nothing but describe the mechanism. 100 And the mechanism description should be independent of the intended 101 usage. 102 103 Architecture Overall architecture 104 / \ 105 / \ AH and ESP architectures, 106 AH ESP described assuming abstract 107 / \ | \ transformations for MAC, enc. 108 / \ | \ 109 AM-1 ... AM-n PM-1 ... PM-m Authentication and privacy 110 mechanisms (the possible 111 transformations), described 112 independently of intended use. 113 114 115 A.3.2.3. PERFORMANCE IMPACTS OF ESP 116 117 The assumption here is that ESP performance is going to be worse 118 than AH performance. This assumption accurately reflects software 119 DES-CBC_a(x) vs. software MD5(a.x.a); but it does NOT accurately 120 reflect the state-of-the-art, either for hardware embodiments of 121 hardware-efficient schemes (where both a well-designed MAC and a 122 well-designed symmetric encryption can keep up with GBit networks); 123 nor for software-embodiments of software-efficient schemes (where 124 ciphers like SEAL [Rogaway and Coppersmith, 1993] are faster than 125 hash functions like MD5). 126 127 You go on to encourage hardware implementations for high throughput. 128 I believe that this suggestion is more feasible for gateways than 129 pervasive end-to-end encryption. The suggestion I would prefer is 130 special-purpose hardware for hardware-efficient algorithms (like 131 DES CBC), and software-efficient mechanisms where one envisions 132 software embodiments to prevail. 133 134 I would go on to propose that there should be at least TWO required 135 optional IPv6 encryption mechanisms: a hardware-efficient one (based 136 on DES), and a software-efficient one. 137 138 139 A.3.3. COMBINING SECURITY MECHANISMS 140 141 The "cryptographically correct" approach for providing 142 authenticity AND privacy is to authenticate the ciphertext, NOT 143 the cleartext. I have seen many people get this wrong. Shouldn't 144 the architecture talk of this? 145 146 From an organizational point of view, the discussion on combining 147 mechanisms may be more appropriate in an architecture document than 148 in the ESP document. 149 150 151 A.4. AUTOMATED KEY DISTRIBUTION 152 153 It wasn't at first clear to me that the key associated to a SAID is 154 a SESSION KEY. It is worth pointing out in the document that a 155 session key must be used; for example, it would be INCORRECT to 156 realize the key on a SAID as a key which depends only on the identity 157 of the communication endpoints. Doing that would, for example, allow 158 cross-session replay attacks of what were supposed to be authenticated 159 messages. Thus even when communication are configured to have a 160 shared secret key, some (at least implicit) key distribution takes 161 place anyway. 162 163 164 A.KS Key Separation 165 166 Have you ignored key separation? It wasn't clear to me if you expect 167 key separation to be done by the key-distribution mechanism or within 168 the various AH and ESP mechanisms. In the first case this is an 169 architectural requirement which you are effectively levying on the key 170 distribution mechanism, so you should say so; in the second case, you 171 are levying this requirement on each MAC and encryption mechanism, and 172 you should say that. 173 174 Eg: Suppose you distribute a session key for A-->B and you use this 175 SAME session key for DES-CBC-MAC authentication and DES-CBC encryption 176 (in an AH and ESP mechanism, respectively). Then clearly the 177 encryption mechanism destroys the authenticity you thought you were 178 getting from the authentication mechanism. There are two outs: the 179 architecture specifies that distinct session key distributions are 180 used for each mechanism; or else the architecture lets mechanisms 181 share distributed keys, but each mechanism is expected to produce and 182 act using its own key variant, said key variants not being related to 183 one another by any efficiently-computable means. 184 185 I personally believe that the key separation should be done by each 186 mechanism, using its own "random" key variant or a registered key 187 separation constant. For I believe the key distribution mechanism 188 ought to be oblivious as to the beneficiaries of its keys. It also 189 saves communication costs to only distribute one key, and have each 190 mechanism generate its own variant. If you mean to use 191 mechanism-specific variants, then you need to set the precedent on 192 HOW you want to do this (by doing it in your required AH and ESP 193 mechanisms). 194 195 Key separation is very important. A failure to perform proper key 196 separation will almost certainly cause security "interaction" problems 197 if the set of supported MAC and encryption mechanisms becomes 198 reasonably populated. If the architecture document doesn't mandate 199 who does this, no one will do it. 200 201 202 A.4.2. Some Existing Key Management Techniques 203 204 You really mean "key distribution" techniques, not key management 205 techniques. "Key management" is a broader problem. 206 207 If you are thinking to mention [Diffie, Hellman] in this regard, it 208 would be better to mention [Diffie, van Oorschot and Wiener 1992], 209 which at least solves a key distribution protocol for the active 210 adversarial setting. 211 212 Note that even if communicating parties have a manually configured 213 shared key, this is not the key that should be on the SAID; a fresh 214 session key should be distributed. The simplest correct techniques 215 can be found in [Bellare, Rogaway - Crypto '93] 216 217 It is not right to say [DH] came after [NS]. 218 219 I would be reluctant to survey works in a paragraph here; this area 220 is too large to say much meaningful about in one paragraph. 221 222 223 A.MINOR. Typos and other minor matters: 224 225 1.1 - Traffic Analysis - line 2. "oneself just" -> "an entity" 226 3.2.3, line 11. Strike "key size," which is irrelevant except 227 insofar as it is reflected in the previous item. 228 3.2.3 - organization - this paragraph isn't all on performance, as 229 the title says 230 4.3, line 6, strike "would". 231 232 233 234 235 ----------------------------------------------------------------- 236 B. Comments on "IPv6 Authentication Header," by Randall Atkinson, 237 draft-atkinson-ipng-auth-01.txt, draft of 16 February 1995. 238 ----------------------------------------------------------------- 239 240 241 B.1. INTRODUCTION & OVERVIEW 242 243 - last line page 1: as per earlier comments: strike "in lieu of": 244 if you want authenticity, use the AH; if you want privacy, use the 245 ESP; if you want both, use both. Simple story. 246 247 - page 2, paragraph 3, line 5. Presupposes that the MAC verification 248 consists of MAC generation and then comparing the generated MAC 249 with the received one. While this is the approach of the Appendix A 250 mechanism, this certainly is not the only possible one: in fact, 251 it is often useful for the MAC to be probabilistic (the sender 252 flips coins to generate the MAC) or stateful (e.g. the sender 253 maintains a counter which is used in the MAC). Obviously such 254 means should not be excluded. In general, the MAC scheme is pair of 255 algorithms -- one to generate a MAC and one to verify a purported MAC. 256 257 258 B.2. KEY MANAGEMENT 259 260 - Paragraph 1. Key management is out of scope not just because of a 261 history of difficulties, but because there are several trust models 262 and several variants within each trust model of the problem which 263 solutions attempt to solve. 264 265 - It is SESSION KEYS which are being distributed. 266 267 - Paragraph 2. strike "and mode." It is not an "authentication 268 algorithm and a mode; it is simply an authentication algorithm. 269 If your mechanism is MAC_a(x) = DES-CBC-MAC_a(x), for example, that 270 whole thing is the algorithm. 271 272 - Why is this section even here? Isn't this for the architecture 273 document? 274 275 276 B.3. SECURITY ASSOCIATION IDENTIFIER (SAID) 277 278 p. 4. It is not appropriate to specify that the SAID be pseudorandom, 279 since this is not the document which specifies how SAIDs are 280 determined. In fact, as far as everything in these documents are 281 concerned, a mechanism which used sequence numbers for SAIDs, 282 for example, would be just fine. 283 284 p. 5, paragraph 3: "Each SAID value implies ..." should be simplified 285 to "Each SAID value implies the key used in the authentication 286 algorithm, and the authentication algorithm itself." All the other 287 stuff you list is implied by this. The (entire) MAC generation and 288 MAC verification algorithms are what is meant by "algorithm". If I 289 choose to make a MAC algorithm which uses an a block cipher, an 290 IV, .... that's fine -- but it's all just part of my algorithm. 291 292 293 B.4. CALCULATION OF THE AUTHENTICATION DATA 294 295 -You say that [if MAC_a(x) is an $a$-encrypted cryptographic 296 hash or a "keyed" cryptographic hash then] the hash should be one-way. 297 Actually, the assumed one-wayness of a function like MD5 is 298 not the pertinent in determining whether or not the function 299 MAC_a(x) = MD5(a.x.a) is a secure MAC. The same holds for most other 300 candidate MAC constructions which use a cryptographic hash function. 301 302 -I question why you are describing things like your proposed MAC 303 mechanism multiple times. Better to describe the body of this 304 proposal in terms of an abstract function MAC_a(x), MACV_a(x) 305 (MAC generate and verify); and if you want to have a required 306 mechanism in the same RFC, then it would be ONLY in a separate 307 appendix. Having the description multiple times only makes it more 308 likely that the descriptions will vary. (In fact this happens; I read 309 this section to say MAC_a(x) = MD5(a.x.a), and the appendix to say 310 that MAC_a(x) = MD5(a.x) !) When MAC_a(x) and MACV_a(x) are described, 311 this description should be independent of their intended usage (and it 312 should be a secure MAC regardless of the structure of $x$). Thus you 313 shouldn't be talking about Hop Counts etc. when you're describing a 314 particular MAC mechanism; you would talk about this only when you're 315 saying what this function is called on. 316 317 -I have already questioned the wisdom of MAC_a(x)=MD5(a.x.a) because 318 of issues in speed, parallelism, and foundationlessness. Let me 319 add in the remark that if one IS going to use a mechanism like 320 MD5(a.x.a), it would be safer to use only the first 64 bits of 321 MD5(a.x.a). The chance that the adversary has of forging a correct 322 MAC by choosing a random tag is still insignificant (2^{-64}), but now 323 the adversary is denied half of the data which might be useful in 324 recovering $a$ or otherwise breaking the MAC scheme. As an example 325 for how this can help, think back to MAC_a(x) = MD5(a.x), which is an 326 easily broken MAC (as pointed out by [Tsudik 92]). This MAC is NOT 327 known to be breakable had the digest been clipped to the first 64 bits 328 of MD5(a.x). 329 330 -One sentence implies that MD5(a.x.a) might be faster to compute than 331 MD5(x.a). This is false. MD5(a.x) might sometimes be faster to 332 compute then MD5(x.a) (for the reason cited in the draft) -- but that 333 is irrelevant. 334 335 -(first paragraph on page 7) You should say that the receiver MUST 336 discard the datagram as non-authentic-- in what sense have you 337 complied with a message authentication scheme if you accept any 338 packet, independent of its MAC?! 339 340 -On the other hand, you SHOULD audit this event--not that you MUST. 341 Demanding auditing is wrong for two reasons: (1) it provides a 342 natural denial of service attack of sending enough unauthentic 343 packets to fill up the audit log; (2) it effectively mandates 344 that clients support auditing, which is unrealistic in that many 345 platforms which run Internet suite protocols do not support auditing. 346 347 348 B.MD5 APPENDIX A 349 350 -It looks like you have forgotten to append the key to the 351 "b-bit message." You mean MAC_a(x) = MD5(a.x.a), right? That's 352 what's described earlier. 353 354 -It is also not entirely obvious that you mean the length of the 355 message which is used in MD5's padding is the length of the string 356 you are authenticating plus the 256 bits which have been added to it. 357 You should take RFC 1321 to specify a function MD5(x), and then you 358 should use this function to describe your MAC. No reference should 359 be made to the internal structure of MD5 (which is irrelevant). 360 361 -I have already criticized the choice of MAC_a(x)=MD5(a.x.a) on 362 various technical grounds. .... 363 364 365 B.MINOR. Typos and other minor matters: 366 367 -page 4: forgot to say the length of the RESERVED field. 368 -page 6, line 1: I'm not sure what you mean "usually"; there are 369 a great many ways to compute MACs. The most popular, the CBC MAC 370 of X9.9, in fact is not of this form. 371 -page 8. line 3: strike "instead of or". 372 373 374 375 376 ----------------------------------------------------------------------- 377 C. Comments on "IPv6 Encapsulating Security Payload (ESP)" by Randall 378 Atkinson, draft-atkinson-ipng-esp-01.txt, draft of 16 February 1995. 379 ----------------------------------------------------------------------- 380 381 382 C.1. INTRODUCTION and 383 C.1.1 OVERVIEW 384 385 -I don't mean to keep harping on the same thing (this is happening 386 because of the structure of this review)... but you should NOT be 387 saying that the ESP provides integrity. Integrity is simply not a 388 cryptographically meaningful notion distinct from authenticity; and 389 perfectly good privacy mechanisms (e.g. a one-time pad) do not achieve 390 anything that anyone would describe as integrity. 391 392 -If one is really going to admit the possibility that the ESP might 393 provide authenticity, then it could achieve authenticity in the 394 asymmetric model (non-repudiation) just as it could achieve 395 authenticity in the symmetric model. But of course I am not 396 suggesting to add this possibility to the text -- rather the opposite, 397 to take away all comments that the ESP might provide authenticity 398 (symmetric or asymmetric). 399 400 - Saying that ESP may be very expensive to implement is unfair, since 401 this is strictly a question of mechanisms. You did not make such 402 strong statements about authenticity (and as I mentioned, the fastest 403 published software privacy mechanisms are faster than the fastest 404 published software authenticity mechanisms). 405 406 - There is something very wrong with the multiple headers notion you 407 describe in paragraph 2: an encrypted one and a (usually identical?) 408 unencrypted one. You say that the former is "primarily" used 409 for routing and the later for authenticity -- but the second comment 410 makes no sense, since you can not count on the the encryption mechanism 411 as providing any authenticity/integrity. Having the header which 412 appears in plaintext also appear in ciphertext buys you nothing 413 cryptographically, but it does (slightly) increase the length of your 414 packets and the amount of work to produce them. 415 416 417 C.2 KEY MANAGEMENT 418 419 Relevant comments already made. I advise against repeating 420 statements like this in multiple documents. 421 422 423 C.3.1. SAID 424 425 -Relevant comments already made. 426 427 -You say that the SAID is selected based on the sending userid 428 and the destination host. As I understand it, this pair does 429 NOT determine a unique SAID. The SAID should be in one-to-one 430 correspondence with (unidirectional) security contexts. A given 431 userid and host could have multiple security contexts. 432 433 434 C.3.2 ENCRYPTED FIELDS. RESERVED 435 436 -Paragraph 2. I've already complained about this idea of having 437 BOTH the encrypted routing information AND the plaintext routing 438 information. The former should be dropped. Authenticating the 439 routing information is very important, but encrypting the routing 440 information should never engender confidence in the receiver that 441 the routing information is in any way reliable. 442 443 To avoid the attacks you refer to the user should use the AH in 444 addition or in place of the ESP. Because there are relatively 445 few environments where privacy is wanted and authenticity is not, 446 the architecture document should discourage use of the ESP without 447 concomitant use of the AH. 448 449 450 C.4.1 ESP in IP-mode 451 452 -As mentioned: (sending user ID, receiving party ID) does not 453 necessarily determine a unique SAID or a unique key. There 454 could be lots of (senderID, receiverID) sessions, each of which 455 needs to be protected by its OWN key. 456 457 -Don't require auditing (as explained earlier); suggest it. 458 459 460 C.4.3 Combining ESP and the Authentication Header 461 462 I do not understand the third paragraph. Is this describing 463 the second approach -- you are encrypting the authenticated 464 data? This should not be done; the scope of the MAC should 465 cover the whole non-variant portion of the datagram, enciphered 466 or not. I have no idea what happens when you try to encrypt a MAC 467 (it is not clear that it remains a correct MAC). 468 469 470 C.7. SECURITY CONSIDERATIONS 471 472 You sort of unfairly imply that DES has a reasonable chosen 473 plaintext attack, citing [BS93]. But [BS93] does not 474 demonstrate a reasonable attack. 475 476 477 C.APPENDIX 478 479 -Don't cite [Sch94] for describing DES (a great number of books in 480 cryptography and computer security repeat the definition of DES). 481 482 -Even worse is citing [Sch94] for citing Eberle's Crypto '92 paper! 483 (In any case, why is it relevant that DES can be implemented on an 484 (unavailable) GaAs chip of 1992 technology to perform at 1 Gbps?) 485 486 -The cited standards differ in whether or not they demand enforcement 487 of the parity bit convention. You should specify this one way or 488 another. (I would demand non-enforcement of the parity bit 489 convention.) 490 491 -More should be specified about the choice of the IV, since a 492 predictable sequence of nonces is not a good choice. DES_a(i) is 493 the usual choice for the i-th IV of a session. It would be better 494 to transmit nonce i as synchronization data and let the receiver 495 compute IV=DES_a(i) himself. Otherwise, people will mis-implement. 496 497 -More fundamentally, I question the appropriateness of DES-CBC as the 498 only required privacy mechanism. Reasons: 499 500 (a) The key exhaustion known-plaintext attack of DES-CBC is 501 sufficiently problematic that I believe any new proposals should 502 use DES in a mode of operation which is not susceptible to 2^{56} 503 key-exhaustion. This is possible even if one wants to spend just 504 one DES operation for block: for example, [Blaze 93] gives such 505 mode of operation. Even simpler, one might make 506 " CBC" as the required ESP mechanism; if one wants it 507 to collapse to single DES, one selects a key of $a=(a',a')$ and 508 incurs no computational penalty. Making sure that the 509 distributed encryption keys are 128-bits --right from the start-- 510 will help ensure a cleaner evolution path from IPv6. 511 512 (b) Realistically, most end users are not going to have DES 513 hardware and they are not going to want to pay the performance 514 penalty to DES encrypt their IPv6 traffic. The security are 515 mechanisms are useless if no one wants to use them because 516 they are too slow. Thus I believe a required software-efficient 517 mechanism should supplement the hardware-efficient one. 518 Currently the drafts embody a peculiar asymmetry in the 519 required mechanisms: one is intended to be software-efficient 520 (MD5(a.x.a)), while one is intended to be hardware efficient 521 (DES-CBC). This then suits no one's needs well. I would 522 suggest that all four possibilities are important enough to 523 support as required-optional mechanisms: 524 525 526 HW-efficient SW-efficient 527 ________________________________ 528 | | | 529 AH | mac.hw | mac.sw | 530 |_______________________________ 531 | | | 532 ESP | enc.hw | enc.sw | 533 |_______________________________ 534 535 IPv6 Required cryptographic algorithms 536 537 538 I do not know exactly what each mechanism should be, but 539 as a first guess I'd say something like: 540 541 enc.hw: CBC (a) 542 mac.hw: DES CBC MAC (b) 543 enc.sw: SEAL (c) 544 mac.sw: A Wegman-Carter MAC (d) 545 546 547 None of these choices is ideal: 548 549 (a)--3x performance penalty in SW if use key not of 550 form a=(a' a'). Inappropriate at Gbit speeds. 551 (b)--Inappropriate at Gbit speeds. Security analysis suggests 552 alternative mechanisms are stronger. 553 (c)--Inadequate review. (But no well-reviewed fast sw cipher 554 is on the horizon.) 555 (d)--No fully-specified concrete scheme is yet in the 556 literature. 557 558 559 C.MINOR. Typos and other minor matters: 560 561 -page 2, paragraph 2: "an datagram". "an header"? 562 -"synchronisation" (sp?) 563 -do you say if field lengths are in bits/bytes? If bytes: is "- 8" 564 really meant on top of page 6? 565 -"a encryption key" (p. 7, line 5); again page 7, line last-6 566 -add "and algorithm" on (p. 7, paragraph 2, line 4, after "key"). 567 -"MUST recorded" (p. 7) 568 -p.9, TYPICAL USE, line 1, "security" -> "privacy". Last sentence 569 is oxymoronic. 570 -p.9 "an SAID"? 571 -I do not know that [CN94] is making a contribution to be highlighted 572 in Section 7, paragraph 2, line 5. 573 574 ..................................................................... 575 576 Phillip Rogaway 577 Eng. II Bldg., #3063 578 Dept. of Computer Science 579 University of California 580 Davis, CA 95616 USA 581 582 Office: (916) 752-7583 583 FAX: (916) 752-4767 584 585 rogaway@cs.ucdavis.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 17:23:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26791; Tue, 14 Mar 95 17:23:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26785; Tue, 14 Mar 95 17:23:17 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08654; Tue, 14 Mar 1995 17:15:43 -0800 Received: from bridge2.NSD.3Com.COM by Sun.COM (sun-barr.Sun.COM) id AA25419; Tue, 14 Mar 95 17:15:29 PST Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA05992 (5.65c/IDA-1.4.4nsd for ); Tue, 14 Mar 1995 17:14:43 -0800 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA18306 (5.65c/IDA-1.4.4-910730 for ); Tue, 14 Mar 1995 17:14:16 -0800 Message-Id: <199503150114.AA18306@remmel.NSD.3Com.COM> To: ipng@sunroof.Eng.Sun.COM Cc: tracym@NSD.3Com.COM Subject: Re: Re[2]: (IPng) True Internationalism In-Reply-To: Your message of "Tue, 14 Mar 1995 22:53:51 +1000." <515322140395*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> Date: Tue, 14 Mar 1995 17:14:16 -0800 From: Tracy Mallory Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > It is the open API set that is important. The US restrictions are > unpleasant but if the technology is available from other sources, it can be > lived with. To enable the Internet to grow then the standards are the key > to prevent the market being stymied. The notion of an open API is nice, but is it really going to work for all of the embedded systems now shipping? Most of the switching platforms in existence today run proprietary systems tuned to particular hardware and development environments. Freeware code from Finland is unlikely to be of much direct use. Or consider the next-generation (+1,+2?) of set-top cable boxes that let you vote from home using your remote control. Both authentication and privacy are required for this application. How does it get into the embedded firmware? I suppose many of the set-top consortiums are big enough to sport multi-national software development, but most startups aren't. The controls have got to go to enable this stuff to work, and be profitable. Tracy ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 17:34:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26813; Tue, 14 Mar 95 17:34:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26801; Tue, 14 Mar 95 17:34:37 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10479; Tue, 14 Mar 1995 17:27:04 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA28293; Tue, 14 Mar 95 17:27:02 PST Received: from relay.imsi.com by wintermute.imsi.com id OAA15161 for ; Tue, 14 Mar 1995 14:43:05 -0500 Received: from snark.imsi.com by relay.imsi.com id OAA23396 for ; Tue, 14 Mar 1995 14:43:05 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA03047; Tue, 14 Mar 95 14:43:04 EST Message-Id: <9503141943.AA03047@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Can *anyone* read Alan Lloyd's email??? In-Reply-To: Your message of "Tue, 14 Mar 1995 14:07:53 EST." <9503141907.AA00494@xirtlu.zk3.dec.com> X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Mar 1995 14:43:04 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM bound@zk3.dec.com says: > I am having the same issue as Casey with Alan's mail. I don't have MIME > at my end if thats what it is? This isn't a MIME issue, actually. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 17:35:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26819; Tue, 14 Mar 95 17:35:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26807; Tue, 14 Mar 95 17:34:48 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10516; Tue, 14 Mar 1995 17:27:13 -0800 Received: from by Sun.COM (sun-barr.Sun.COM) id AB28293; Tue, 14 Mar 95 17:27:12 PST Received: from relay.imsi.com by wintermute.imsi.com id OAA15157; Tue, 14 Mar 1995 14:42:34 -0500 Received: from snark.imsi.com by relay.imsi.com id OAA23392; Tue, 14 Mar 1995 14:42:33 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA03037; Tue, 14 Mar 95 14:42:32 EST Message-Id: <9503141942.AA03037@snark.imsi.com> To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Your message of "Tue, 14 Mar 1995 13:46:33 EST." <199503141851.AA22418@interlock.ans.net> X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Mar 1995 14:42:32 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, bound@zk3.dec.com says: > 3. Can't we discuss this without mention of SKIP so that we can > make sure either in-band or out-band can be used? The problem is that SKIP is the only proposal we've had thats of this form. Given that, its very difficult to discuss this in the general case -- I'm not even sure what the "general case" would look like. My suspicion is that other similar techniques would use very different machinery. SKIP, as it is, cannot reuse any of the standard IPSP machinery -- it needs its own transforms, its own hooks to the key management layer, etc. I'm not sure that other similar techniques could share any of SKIP's machinery, and I'm not sure at all that there is a "general case" here to discuss. Therefore, I prefer to keep discussion concrete and focus on SKIP. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 17:36:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26831; Tue, 14 Mar 95 17:36:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26825; Tue, 14 Mar 95 17:36:06 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10763; Tue, 14 Mar 1995 17:28:32 -0800 Received: from by Sun.COM (sun-barr.Sun.COM) id AB28293; Tue, 14 Mar 95 17:27:19 PST Received: from relay.imsi.com by wintermute.imsi.com id OAA15210; Tue, 14 Mar 1995 14:54:40 -0500 Received: from snark.imsi.com by relay.imsi.com id OAA23498; Tue, 14 Mar 1995 14:54:39 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA03076; Tue, 14 Mar 95 14:54:39 EST Message-Id: <9503141954.AA03076@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipsec@ans.net, bound@zk3.dec.com Subject: Re: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Your message of "Tue, 14 Mar 1995 11:40:52 PST." <199503141940.LAA06109@elrond.Eng.Sun.COM> X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Mar 1995 14:54:38 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan Nessett says: > Jim, > > In regards to your questions : > > > > > Technical Questions: > > > > 1. To reveiw: Will in-band keying work with the present IPv6 specs > > (Rans work) without changes to the specifications? Not just SKIP > > (see next question). > > No. In-band keying will not work with the present IPv6 specs. This issue > is independent of SKIP. The problem is there is no place to indicate in > either the AH or ESP that in-band keying is being used. Thats not true. The reserved SAIDs were envisioned for doing things like this. It wasn't thought that we'd actually *want* to use them, but we did leave in the flexibility just in case. So far as I can tell, using one of the reserved SAIDs, as has been repeatedly proposed, would work just fine for you. This is not to say that the mechanism is being encouraged, but it is possible. Given the inability to reuse most of the rest of the protocol machinery, however, I really don't see, overall, why you would even want to try to get the round SKIP peg to fit into a square IPSP hole -- you need all your own transforms, you don't use the SAIDs per se, etc, etc -- for the most part, you aren't using the IPSP mechanisms at all. > > 2. Are there multiple ways to use in-band keying besides SKIP? > > I am asking this because I believe in-band keying should be > > something vendors should be able to build as a key-management > > solution. I am assuming SKIP is only one way to use in-band keying > > and others can exist too? > > SKIP is only one way to do in-band keying. Other possibilities > exist. However, none have been proposed as serious contenders for IETF standardization.... > As far as I know, SKIP is the only > widely publicized in-band keying method proposed for IPv6, ...which you seem to realize. > > 3. Can't we discuss this without mention of SKIP so that we can > > make sure either in-band or out-band can be used? I think its > > important we get to the heart of the architectural issues > > technically of the in/out modes and not get hung up on actual > > mechanisms? Or is this not a good idea? > > I agree 100% that we should focus on the issue of in-band and out-of-band > keying and not concentrate on SKIP. Given that different hacks and kludges are probably needed for each similar method proposed, I would say that trying to ignore the specifics of the SKIP proposal, which is the only one currently on the table of its kind, would be foolish. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 18:37:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26897; Tue, 14 Mar 95 18:37:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26890; Tue, 14 Mar 95 18:36:59 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20098; Tue, 14 Mar 1995 18:29:25 -0800 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA15395; Tue, 14 Mar 95 18:29:15 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 15 Mar 1995 12:27:25 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Wed, 15 Mar 1995 12:28:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 15 Mar 1995 12:24:51 +1000 Date: Wed, 15 Mar 1995 12:24:51 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Mar 15 12:24:51 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 512412150395 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <512412150395*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Subject: Re[2]: (IPng) Can *anyone* read Alan Lloyd's email??? X-Reposting-Policy: redistribute only with permission Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >bound@zk3.dec.com says: >> I am having the same issue as Casey with Alan's mail. I don't have MIME >> at my end if thats what it is? >This isn't a MIME issue, actually. Its just Alan making sure we take the trouble read the detail. After fighting to extract the text I sure read each word. Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 18:45:32 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26928; Tue, 14 Mar 95 18:45:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26922; Tue, 14 Mar 95 18:45:25 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21082; Tue, 14 Mar 1995 18:37:51 -0800 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA17230; Tue, 14 Mar 95 18:37:33 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 15 Mar 1995 12:35:39 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Wed, 15 Mar 1995 12:36:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 15 Mar 1995 12:33:51 +1000 Date: Wed, 15 Mar 1995 12:33:51 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Mar 15 12:33:51 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 513312150395 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <513312150395*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Subject: Re[4]: (IPng) True Internationalism Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >The controls have got to go to enable this stuff to work, and be >profitable. If it can't be "open" and it can't be exported, then as others have said, it will have to be made outside the US. Profit and economics tends to pretty major political driving factors for change. I am happy enough now that as long as the specs are available then we can live with non US sourced products. Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 21:06:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27065; Tue, 14 Mar 95 21:06:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27059; Tue, 14 Mar 95 21:06:23 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01116; Tue, 14 Mar 1995 20:58:49 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA14633; Tue, 14 Mar 95 20:58:51 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14503(7)>; Tue, 14 Mar 1995 20:58:45 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12175>; Tue, 14 Mar 1995 20:58:32 -0800 To: Danny.Nessett@Eng (Dan Nessett) Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net, deering@parc.xerox.com Subject: Re: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Danny.Nessett's message of Tue, 14 Mar 95 11:40:52 -0800. <199503141940.LAA06109@elrond.Eng.Sun.COM> Date: Tue, 14 Mar 1995 20:58:28 PST From: Steve Deering Message-Id: <95Mar14.205832pst.12175@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan, > No. In-band keying will not work with the present IPv6 specs. This issue > is independent of SKIP. The problem is there is no place to indicate in > either the AH or ESP that in-band keying is being used. I haven't had time to follow the great In-Band/Out-of-Band keying debate in detail, so please excuse me if this is off-base. I thought I saw the suggestion that one of the reserved SAID values could be assigned the role of indicating the presence of in-packet keying material. Alternatively, you could use an option in a Destination (formerly End-to-End) Options header preceding the AH or ESP header to carry the in-packet key stuff. Is it simply the lack of a spec that defines either of those alternatives that leads you to say "In-band keying will not work with the present IPv6 specs."? If so, feel free to write such a spec. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 14 21:30:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27081; Tue, 14 Mar 95 21:30:14 PST Received: from eunuchs.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27075; Tue, 14 Mar 95 21:30:06 PST Received: by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA11240; Tue, 14 Mar 1995 21:22:36 -0800 Received: from snail.Sun.COM by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA11222; Tue, 14 Mar 1995 21:22:31 -0800 Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA15064; Tue, 14 Mar 95 21:22:29 PST Received: from ns.incog.com by Sun.COM (sun-barr.Sun.COM) id AA03459; Tue, 14 Mar 95 12:23:32 PST Received: by ns.incog.com (8.6.10/94082501) id MAA29921; Tue, 14 Mar 1995 12:24:03 -0800 Received: from osmosys.incog.com by ns.incog.com (8.6.10/94082501) id MAA29906; Tue, 14 Mar 1995 12:24:00 -0800 Received: from miraj.incog.com by osmosys.incog.com (5.x/SMI-SVR4) id AA05935; Tue, 14 Mar 1995 12:23:49 -0800 Received: by miraj.incog.com (5.x/SMI-SVR4) id AA02668; Tue, 14 Mar 1995 12:20:39 -0800 Date: Tue, 14 Mar 1995 12:20:39 -0800 From: ashar@icgmail.Eng.Sun.COM (Ashar Aziz) Message-Id: <9503142020.AA02668@miraj.incog.com> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net X-Sun-Charset: US-ASCII X-Icg-Mailfrom: ashar@icgmail.eng.sun.com Subject: Re: (IPng) Re: Proposed message on perfect forward security Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Dan, > > Technical Questions: > > 1. To reveiw: Will in-band keying work with the present IPv6 specs > (Rans work) without changes to the specifications? Not just SKIP > (see next question). (You addressed Dan, but since this was public, I'll offer a response as well). In-band might work. The reason I am hedging is that the words about "not supporting" in-band not implying "precluding" in-band in the IPv6 Arch spec strike me as ambiguous. People wishing to do this later, and relying solely on the specs and not being privy to our e-mail discussions may in fact conclude that in-band keying is precluded. (This was the conclusion that Dan and I arrived at after reading the document). Certainly, there is little guidance in the specs to indicate how to perform in-band keying, should someone wish to do such a thing. By contrast, IEEE 802.10b explicitly defines the Management Defined Field (MDF) which follows the SAID and states that one possible use of this is to carry encrypted keys. My preferred way to deal with this would be to remove the ambiguous text, and specify somewhere how to achieve in-band keying. There have been discussions about bits in the SAID or one reserved SAID to indicate such a thing. We are currently working under the assumption that a reserved SAID may work better because people objected to burning up half the SAID space. In fact, Dan had suggested this to me prior to the suggestions on ipsec/ipng, and we were discussing the right way to structure the information. I am planning on writing up a transform for IPSP to indicate use of such a reserved SAID to indicate in-band keys and hope to write this up before the Danvers meeting. > 2. Are there multiple ways to use in-band keying besides SKIP? > I am asking this because I believe in-band keying should be > something vendors should be able to build as a key-management > solution. I am assuming SKIP is only one way to use in-band keying > and others can exist too? Yes, and in fact there is a DEC patent (US 5081678) on techniques that employ in-band keying that are totally unrelated to SKIP. > 3. Can't we discuss this without mention of SKIP so that we can > make sure either in-band or out-band can be used? We can and I think we should. > I think its > important we get to the heart of the architectural issues > technically of the in/out modes and not get hung up on actual > mechanisms? I, for one, concur. Regards, Ashar. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 05:36:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27261; Wed, 15 Mar 95 05:36:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27255; Wed, 15 Mar 95 05:36:01 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21929; Wed, 15 Mar 1995 05:28:28 -0800 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com) by Sun.COM (sun-barr.Sun.COM) id AA07153; Wed, 15 Mar 95 05:28:28 PST Received: from commtg3-alt.rtp.dg.com by dg-rtp.dg.com (5.4R2.01/dg-rtp-v02) id AA03611; Wed, 15 Mar 1995 08:28:16 -0500 Received: by commtg3 (5.4R3.10 beta /rtp-s04) id AA13635; Wed, 15 Mar 1995 08:28:14 -0500 Date: Wed, 15 Mar 1995 08:28:14 -0500 From: throop@dg-rtp.dg.com (Dean D. Throop) Message-Id: <9503151328.AA13635@commtg3> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) MLS interoperability Cc: atkinson@itd.nrl.navy.mil Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The "IPv6 Security Architecture", section 5.5, talks about MLS issues. There it claims ... In such environments, the ability to communicate between the Internet and the hosts handling sensitive data is probably undesirable. ... I disagree that interoperability is undesirbale. In fact one goal of MLS sites is to allow interoperability when appropriate and disallow interoperability when not appropriate. If the sites never wanted to communicate, they would run system high and there would be no need for MLS. MLS sites want to interoperate but in a controlled and properly authorized way. These sites don't allow communication because they don't trust their systems to properly enforce policy and control access; not because they don't believe communication is desirable. Some sites may always feel their information is so sensitive that the risk of fully trusting the system always outweights the benefits of open communication but I don't think any site would find such communication undesirable. Dean Throop throop@dg-rtp.dg.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 06:58:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27285; Wed, 15 Mar 95 06:58:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27279; Wed, 15 Mar 95 06:57:43 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25520; Wed, 15 Mar 1995 06:48:57 -0800 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com) by Sun.COM (sun-barr.Sun.COM) id AA17137; Wed, 15 Mar 95 06:48:51 PST Received: from commtg3-alt.rtp.dg.com by dg-rtp.dg.com (5.4R2.01/dg-rtp-v02) id AA25138; Wed, 15 Mar 1995 09:48:48 -0500 Received: by commtg3 (5.4R3.10 beta /rtp-s04) id AA15133; Wed, 15 Mar 1995 09:48:46 -0500 Date: Wed, 15 Mar 1995 09:48:46 -0500 From: throop@dg-rtp.dg.com (Dean D. Throop) Message-Id: <9503151448.AA15133@commtg3> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) More Endpoint Attributes Cc: atkinson@itd.nrl.navy.mi Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The "IPv6 Security Architecture", dated Feb 95, section 5.5 describes using the SAID to carry MLS label information. The idea is to make the SAID convey both cryptographic authentication information and MLS labeling information. Communications endpoints in systems that have security mechanisms on steriods (i.e. systems with security features beyond what 4.3BSD offers) have many other attributes in addition the MLS label. These attributes include, but are not limited to: maximum clearance information label priviliges subject identifier current uid current gid additional group ids pid audit info national caveats integrity label acl There have been system built that passed all of these attributes and in the future we can expect some these attributes will grow in importance. If the IPv6 architecture is intended to support MLS operation, it needs to provide for passing these attributes and adding new ones in the future. The model in the architecture for conveying these attribures is to allocate another SAID. There would be a different SAID for different values of these attribues. Some of these attributes are extremely useful for general internet use. For example; if a packet comes into your system and you don't want it, the first question is "where did it come from?", the second question is "who did it?". The subject identifier attribute of an endpoint identifies the person responsible for that endpoint. It answers the question "who did it?". The Feb 95 draft implicitly assumes that SAIDs are rather static. They are allocated manually and then are used for quite a while. This certainly isn't what happens with the attributes of an endpoint. The integrity and information labels float depending on the data being accessed. The current UID/GID changes as the user changes discretionary identity to perform different tasks. Priviliges are often granted based on the client program being executed. The architecture describes one SAID being used for several sessions. It should call more more fully that one session can use several SAIDs. The more information a SAID conveys the more likely it is that an end host will have to use a different SAID for different packets. (MLS operation requires that all packets are labeled with the attributes appropriate for the data in the packet.) Each time the user does something that changes the endpoint attributes, the end host must get a new SAID. If intermediate systems look at SAID (for example to enforce MLS requirements that restricted information only goes on authorized lines), this means all intermediate systems must be updated each time another SAID is allocated. Some of the times a new SAID will be allocated because an attribute changed but the intermediate system doesn't restrict access based on that attribute. The architecture needs to talk about additional endpoint attributes and how those attributes together influence SAID selection. The architecture needs to clarify if one session (one TCP connection) is restricted to one SAID or if one session can use several SAIDs. (If several SAIDs are allowed; what happens when the sender sends information the receiver isn't authorized to receive?). The architecture needs to talk about how intermediate systems may use the SAID to enforce policy routing (yes there are intermediate system out there today that restrict packets to certain lines based on the header of the packet). The point of this very long message is that overloading a single SAID with all attributes won't scale As we get more attributes and they change more often and as intermediate systems have to start looking at them, we'll see an explosion in the number of SAIDs. Start doing a little math number_of_attributes x number_of_values_per_attributes x number_of_hosts I've listed order 2^4 attributes, each with probably 2^6 values, all going through an intermediate system serving maybe 2^10 hosts. If each SAID requires the intermediate system to save 2^2 bytes of data, this use of SAIDs requires 4MegaBytes of memory just to keep track of the SAID information of a rather small router. (Not to mention the time require to search that information.) Such assumptions are really rather conservative. Even the number of users on larger servers can be greater than 2^6. We're today building systems where one attribute can have 2^1000 values. Trying to multiplex 2^1000 values onto a 32bit SAID won't scale. The end host systems are forced to change SAID everytime an endpoint attribute changes. That's the only mechanism they have to tell the other end host that the attributes of data in the packet are different. A better architecture would allow multiple SAIDs. Each SAID would have a type field. A router could look at the type of each SAID and make the policy decisions its intendes to make based SAID types it recognizes. Having multiple SAIDs allows the source host to keep constant the SAID for the attributes a router must look at while changing the SAID that conveys the attributes only the other end hosts cares about. Allowing a variable number of attributes allows for adding other attributes in the future. Dean Throop throop@dg-rtp.dg.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 07:26:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27331; Wed, 15 Mar 95 07:26:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27325; Wed, 15 Mar 95 07:26:43 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27247; Wed, 15 Mar 1995 07:17:57 -0800 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com) by Sun.COM (sun-barr.Sun.COM) id AA21509; Wed, 15 Mar 95 07:17:49 PST Received: from commtg3-alt.rtp.dg.com by dg-rtp.dg.com (5.4R2.01/dg-rtp-v02) id AA03179; Wed, 15 Mar 1995 10:17:45 -0500 Received: by commtg3 (5.4R3.10 beta /rtp-s04) id AA15844; Wed, 15 Mar 1995 10:17:43 -0500 Date: Wed, 15 Mar 1995 10:17:43 -0500 From: throop@dg-rtp.dg.com (Dean D. Throop) Message-Id: <9503151517.AA15844@commtg3> To: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Subject receiver-orientation Cc: atkinson@itd.nrl.navy.mil Bcc: spencerj The "IPv6 Authentication Header", draft Feb 95, describes the SAID has having a receiver-orientation. If the receiver is a unicast address, the receiver should know the SAID. If the receiver is a multi-cast address, the receiver may have to go to some multi-cast SAID server to get information on what the SAID means. This appears to require two mechanisms when a little change in orientation will eliminate this. Make the SAID sender oriented. The sender is always a unicast address independent of whether the receiver is uni or multi cast. If the receiver doesn't recognize a SAID, it can use another protocol (not described here) to ask the sender what the SAID means. I think the mechanism in the current draft bends over backwards to make life easier for the receiver when the truth is the both the sender and the receiver must be compatible. We need to mimize system complexity as much as possible. As we go to more dynamic SAID allocation, we might as well give up having all multicast receivers know the SAID before the sender transmits the packet. There will always be hosts coming up and going down so we might as well assume some host will receive a multicast packet with a SAID it doesn't know. Rather than assume some SAID server in the sky, just require the sender to assign SAIDs and to keep the track of the SAIDs it has assigned. If the sender doesn't answer a request to resolve a SAID, the receiver need not worry about the packet. There's no need to invent some abstract server for this. Dean Throop throop@dg-rtp.dg.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 07:44:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27360; Wed, 15 Mar 95 07:44:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27354; Wed, 15 Mar 95 07:44:39 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28394; Wed, 15 Mar 1995 07:35:53 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA24627; Wed, 15 Mar 95 07:35:47 PST Received: by rodan.UU.NET id QQyhek11974; Wed, 15 Mar 1995 10:35:46 -0500 From: stripes@uunet.uu.net (Josh Osborne) Message-Id: Subject: Re: (IPng) More Endpoint Attributes To: ipng@sunroof.Eng.Sun.COM Date: Wed, 15 Mar 1995 10:35:46 -0500 (EST) In-Reply-To: <9503151448.AA15133@commtg3> from "Dean D. Throop" at Mar 15, 95 09:48:46 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [...a suggestion on attributes to assoicate with SAIDs...] >These attributes include, but are not limited to: [...] > current uid > current gid > additional group ids > pid [...] uid/gid info is very OS dependent. Not just the exact usage, but the concept, and storage type. It would be sufficant to represent Unix uid/gid info as a bunch of 32 bit values for all the systems I know of (or does the Alpha use 64bit uids and gids?), with an arbatary number of gid's. Likewise a large integer would do for the pid as well. Non-unix systems may not have a concept of user id's (like DOS), or may not have a numeric form (an example fails to spring to mind - does Novel Netware have a uid number, or just a string?). Non-unix systems may not have a concept of user groups, if they do have user groups (or a close enough idea of them) they may not have a numeric form (possabbly only strings, or some opaque object reference). Non-unix systems may not have a concept of process id's, or the pid may not have a numeric form. (when I say "may not have a numeric form", I mean a obvious one that a user of the system can map to the group/user/process, it is almost allways be the case that the address of the data structure could be used as a numeric form (unless the OS has garbage collection), or that there is a internal numeric form - but if it isn't useful to users of that OS, then it isn't really useful to pass around) Also as a minor point this data would probbable be intrepreted as more portable then it is, just think about the IP port numbers below 1024 convention. I can see uid info being misused badly. [...] ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 07:52:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27373; Wed, 15 Mar 95 07:52:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27367; Wed, 15 Mar 95 07:52:22 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28917; Wed, 15 Mar 1995 07:43:36 -0800 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com) by Sun.COM (sun-barr.Sun.COM) id AA25978; Wed, 15 Mar 95 07:43:30 PST Received: from commtg3-alt.rtp.dg.com by dg-rtp.dg.com (5.4R2.01/dg-rtp-v02) id AA09845; Wed, 15 Mar 1995 10:43:27 -0500 Received: by commtg3 (5.4R3.10 beta /rtp-s04) id AA17176; Wed, 15 Mar 1995 10:43:25 -0500 Date: Wed, 15 Mar 1995 10:43:25 -0500 From: throop@dg-rtp.dg.com (Dean D. Throop) Message-Id: <9503151543.AA17176@commtg3> To: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Subject Authentication goals Cc: atkinson@itd.nrl.navy.mil Bcc: spencerj It wasn't clear from the security architecture draft if the authentication mechanism intended to authenticate end hosts to end hosts or to authenticate users on a hosts. If its host-to-host, the authentication makes sure the receiver knows what system actually sent the data. That mechanism is then complete and it leaves it up to another mechanism to (if desired) authenticate the session user. Or should the authentication mechanism also include user identification so when the receiving system receives a packet, it knows its from a specific user on a specific host. This impacts the other protocols built upon IPv6. Do those protocols assume that when an IPv6 session is created they will have authentication information or do the protocols above IPv6 have to have provisions for exchanging authentication information? Dean Throop throop@dg-rtp.dg.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 08:17:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27396; Wed, 15 Mar 95 08:17:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27390; Wed, 15 Mar 95 08:16:57 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00824; Wed, 15 Mar 1995 08:08:11 -0800 Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AB00608; Wed, 15 Mar 95 08:07:59 PST Message-Id: <9503151607.AB00608@Sun.COM> From: smb@research.att.com Received: by gryphon; Wed Mar 15 10:32:25 EST 1995 To: ipng@sunroof.Eng.Sun.COM Date: Wed, 15 Mar 95 10:32:25 EST Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The "IPv6 Authentication Header", draft Feb 95, describes the SAID has having a receiver-orientation. If the receiver is a unicast address, the receiver should know the SAID. If the receiver is a multi-cast address, the receiver may have to go to some multi-cast SAID server to get information on what the SAID means. This appears to require two mechanisms when a little change in orientation will eliminate this. Make the SAID sender oriented. The sender is always a unicast address independent of whether the receiver is uni or multi cast. If the receiver doesn't recognize a SAID, it can use another protocol (not described here) to ask the sender what the SAID means. Let me explain the rationale. First, we assumed that the large majority of packets would be unicast, not multicast, so we wanted to optimize for that case. A receiver-generated SAID can be a simple table index, making it very cheap indeed. A sender- generated SAID is meaningless unless paired with the sender's IP address, so some sort of hashed lookup is needed. For the multicast case, we expected to be using one key, and hence one SAID, per multicast group. Unless and until public key technology is *much* cheaper, I don't anticipate seeing every packet signed by the sender. Given that, we chose to bind the SAID to the multicast group id, i.e., the destination address. A hashed lookup is needed here, to avoid collisions between different multicast groups. No server is needed; the receiver will learn the SAID at the same time as it learns the key, though I don't think we've even started to talk about multicast key management yet. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 08:34:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27412; Wed, 15 Mar 95 08:34:47 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27406; Wed, 15 Mar 95 08:34:40 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA11835; Wed, 15 Mar 1995 08:25:05 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA06602; Wed, 15 Mar 1995 08:24:47 -0800 Date: Wed, 15 Mar 1995 08:24:47 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503151624.IAA06602@elrond.Eng.Sun.COM> To: deering@parc.xerox.com Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, Yes, you are right about : > I thought I saw the > suggestion that one of the reserved SAID values could be assigned the role > of indicating the presence of in-packet keying material. The problems with this are : o The existing security architecture I-D explicitly deprecates the use of in-band keying. While we know that it can be made to fit into the existing formats, those who read the documents without the benefit of reading all of the email on this subject that has appeared on the IPng list would legitimately conclude that in-band keying is outside the standard. o One of the reserved SAID values could be used, but right now they are "reserved for future use." Those who are interested in using one of them for in-band keying can't just unilaterally pick one and use it, since sometime in the future the IETF may pick it to be used for something else. I have emailed to the list a suggested value to use for this purpose (i.e., SAID = 1) and proposed that the existing security drafts be changed to include it. (Of course, I don't care if the value is 1, 4 7 or whatever, I just picked 1 as a concrete proposal). o Picking an SAID value for in-band keying still leaves the problem of parsing the remaining information. This problem has two parts. One is how the software will know which in-band keying algorithm is used, and the other is what data format is being used for the algorithm specific data. The first problem is solved by defining a standard way to indicate which algorithm is being used and where the algorithm specific data will go. I have suggested ways in which the current security I-Ds could be changed to do this (but am open to other ways). The second problem is solved on an algorithm by algorithm basis, probably in the form of an RFC per algorithm (much as Photuris will have its own RFC). While your suggestion : > Alternatively, you > could use an option in a Destination (formerly End-to-End) Options header > preceding the AH or ESP header to carry the in-packet key stuff. is possible, it would effectively mean that there would be two AH and ESP header formats (although, they might be called something different). The kind of data in the new option would be pretty much like that in the AH and ESP headers. This seems wasteful, since an IPv6 packet would not carry both an AH or ESP header formated according to the existing definitions as well as the in-band Destination Options header. Your other suggestion, i.e., > Is it > simply the lack of a spec that defines either of those alternatives that > leads you to say "In-band keying will not work with the present IPv6 specs."? > If so, feel free to write such a spec. I have tried to avoid, since it would mean taking 95% of the text from the existing security I-Ds, change it in the way I have suggested in previous email to the list and putting it out as separate drafts. Not only would this be rude to Ran (i.e., stealing someone's text is a somewhat hostile act), it would mean that there would now be two sets of drafts for the already streched people on the list to read and evaluate. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 08:48:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27424; Wed, 15 Mar 95 08:48:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27418; Wed, 15 Mar 95 08:48:00 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03824; Wed, 15 Mar 1995 08:39:14 -0800 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com) by Sun.COM (sun-barr.Sun.COM) id AA07274; Wed, 15 Mar 95 08:39:06 PST Received: from commtg3-alt.rtp.dg.com by dg-rtp.dg.com (5.4R2.01/dg-rtp-v02) id AA26541; Wed, 15 Mar 1995 11:38:47 -0500 Received: by commtg3 (5.4R3.10 beta /rtp-s04) id AA21248; Wed, 15 Mar 1995 11:38:45 -0500 Date: Wed, 15 Mar 1995 11:38:45 -0500 From: throop@dg-rtp.dg.com (Dean D. Throop) Message-Id: <9503151638.AA21248@commtg3> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: (none) receiver-orientation Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: smb@research.att.com > Date: Wed, 15 Mar 95 10:32:25 EST ... > Make the SAID sender oriented. The sender is always a unicast address > independent of whether the receiver is uni or multi cast. ... > > Let me explain the rationale. > > First, we assumed that the large majority of packets would be unicast, > not multicast, so we wanted to optimize for that case. A receiver-generated > SAID can be a simple table index, making it very cheap indeed. A sender- > generated SAID is meaningless unless paired with the sender's IP address, > so some sort of hashed lookup is needed. I don't believe this make things much more difficult. A TCP connection is identified by 2 port numbers and 2 IP addresses. All TCP implementations already have to keep a list of remote IP address; that list is contained in the established connection list. The lookup of session information based on sending address already exists for TCP. > > For the multicast case, we expected to be using one key, and hence > one SAID, per multicast group. Unless and until public key technology > is *much* cheaper, I don't anticipate seeing every packet signed by > the sender. Given that, we chose to bind the SAID to the multicast > group id, i.e., the destination address. A hashed lookup is needed > here, to avoid collisions between different multicast groups. No > server is needed; the receiver will learn the SAID at the same time as > it learns the key, though I don't think we've even started to talk about > multicast key management yet. This assumes a very simple model of authenticating the sending host to the receiving host using a one size fits all use of SAIDs. If a SAID also authenticates a user on the sending host, we get a more dynamic assignment of SAIDs where this doesn't hold. > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com > Dean Throop throop@dg-rtp.dg.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 09:06:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27437; Wed, 15 Mar 95 09:06:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27431; Wed, 15 Mar 95 09:06:29 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05562; Wed, 15 Mar 1995 08:57:42 -0800 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com) by Sun.COM (sun-barr.Sun.COM) id AA10715; Wed, 15 Mar 95 08:57:15 PST Received: from commtg3-alt.rtp.dg.com by dg-rtp.dg.com (5.4R2.01/dg-rtp-v02) id AA00985; Wed, 15 Mar 1995 11:56:28 -0500 Received: by commtg3 (5.4R3.10 beta /rtp-s04) id AA22084; Wed, 15 Mar 1995 11:56:26 -0500 Date: Wed, 15 Mar 1995 11:56:26 -0500 From: throop@dg-rtp.dg.com (Dean D. Throop) Message-Id: <9503151656.AA22084@commtg3> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) More Endpoint Attributes Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: stripes@uunet.uu.net (Josh Osborne) > Subject: Re: (IPng) More Endpoint Attributes ... > > uid/gid info is very OS dependent. Not just the exact usage, but > the concept, and storage type. It would be sufficant to represent > Unix uid/gid info as a bunch of 32 bit values for all the systems > I know of (or does the Alpha use 64bit uids and gids?), with an > arbatary number of gid's. Likewise a large integer would do for > the pid as well. > > Non-unix systems may not have a concept of user id's (like DOS), or > may not have a numeric form (an example fails to spring to mind - > does Novel Netware have a uid number, or just a string?). > > Non-unix systems may not have a concept of user groups, if they > do have user groups (or a close enough idea of them) they may > not have a numeric form (possabbly only strings, or some opaque > object reference). > I agree that many of the attributes are very system/implementation/ configuartion dependent. If we're going to overload everything onto a single SAID, then a SAID must be able to convey everything we ever need. A SAID may be assigned that only represents an encryption algorithm. All other attributes are NULL with respect to that SAID. When we come up with a protocol to allocate SAIDs, the protocol should allow systems with different attributes to exchange the attributes they have in common and to disregard the attributes that are not in common. Many systems will want to allocate SAIDs that conveys a specific user on a specific system and explicitly does not convey any sensitivity label, privileges, or other attributes. If a SAID does't convey an attribute the receiving system needs, the receiving system can disallow the session or supply a default that restricts behavior to less than the full capability of the system. The current mechanism overloads everything on to a single SAID and that won't scale when we get to large number of attributes rapidly changing. Dean Throop throop@dg-rtp.dg.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 09:44:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27475; Wed, 15 Mar 95 09:44:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27469; Wed, 15 Mar 95 09:43:39 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09799; Wed, 15 Mar 1995 09:35:11 -0800 Received: from nic1.barrnet.net by Sun.COM (sun-barr.Sun.COM) id AA18458; Wed, 15 Mar 95 09:35:00 PST Received: from ipsilon.com by nic1.barrnet.net (8.6.10/BARRNET-RELAY.1) id JAA03617; Wed, 15 Mar 1995 09:34:52 -0800 Received: from [204.160.240.13] by ipsilon.com (4.1/SMI-4.1MDV1.0) id AA01141; Wed, 15 Mar 95 09:33:18 PST X-Sender: hinden@servo.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Mar 1995 09:32:52 -0800 To: ipng@sunroof.Eng.Sun.COM From: hinden@ipsilon.com (Bob Hinden) Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: ipsec@ans.net Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan, I have been reading this exchange for a while now and think it has gone beyond the point of being constructive a long while ago. The current exchange seems to me be centered around the definition of the word "reserved". Some seem to think it excludes the possibility of "in-band keying", other think it allows it. This is no longer a technical discussion. Perhaps this debate could be ended if the text was changed to say something like: The set of SAID values in the range 0x00000001 through 0x000000FF are reserved for future use (for example "in-band keying"). Then perhaps everyone can go back to developing and deploying some real key management algorithms and software which we all really need if the internet is to have real security. Bob At 12:32 PM 3/14/95, Dan Nessett wrote: >Perry, > >In an earlier message I point out : > >> > No. In-band keying will not work with the present IPv6 specs. This issue >> > is independent of SKIP. The problem is there is no place to indicate in >> > either the AH or ESP that in-band keying is being used. > >To which you reply : > >> Thats not true. >> >> The reserved SAIDs were envisioned for doing things like this. It >> wasn't thought that we'd actually *want* to use them, but we did leave >> in the flexibility just in case. >> >> So far as I can tell, using one of the reserved SAIDs, as has been >> repeatedly proposed, would work just fine for you. This is not to say >> that the mechanism is being encouraged, but it is possible. Given the >> inability to reuse most of the rest of the protocol machinery, >> however, I really don't see, overall, why you would even want to try >> to get the round SKIP peg to fit into a square IPSP hole -- you need >> all your own transforms, you don't use the SAIDs per se, etc, etc -- >> for the most part, you aren't using the IPSP mechanisms at all. > >Allow me to quote from the current AH I-D : > > A 32-bit pseudo-random value identifying the security association > for this datagram. If no security association has been established, > the value of this field shall be 0x00000000. The set of SAID values > in the range 0x00000001 through 0x000000FF are reserved for future > use. > >There is similar language in the ESP I-D. I read this to mean that the >reserved values are "reserved," i.e., not to be used, since they may >be used for some unspecified purpose in the future. If the security documents >are modified to indicate an SAID value that is to mean, "using in-band >keying," then what you say would be true. However, at present it is not. > >Dan >------------------------------------------------------------------------------ >IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng >Unsubscribe: unsubscribe ipng (as message body, not subject) >Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 10:07:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27497; Wed, 15 Mar 95 10:07:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27491; Wed, 15 Mar 95 10:06:51 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12730; Wed, 15 Mar 1995 09:58:05 -0800 Received: from research.att.com ([192.20.225.3]) by Sun.COM (sun-barr.Sun.COM) id AA22980; Wed, 15 Mar 95 09:53:18 PST Message-Id: <9503151753.AA22980@Sun.COM> From: smb@research.att.com Received: by gryphon; Wed Mar 15 12:44:55 EST 1995 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: (none) receiver-orientation Date: Wed, 15 Mar 95 12:44:54 EST Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I don't believe this make things much more difficult. A TCP connection is identified by 2 port numbers and 2 IP addresses. All TCP implementations already have to keep a list of remote IP address; that list is contained in the established connection list. The lookup of session information based on sending address already exists for TCP. Except that since the TCP header is encrypted, it won't be visible till the packet is decrypted. I agree, of course, that the existence of current TCPs demonstrates that the lookup isn't an insurmountable obstacle -- but if we're using an uninterpreted number for a SAID, I saw no reason not to assign it a simple meaning. > > For the multicast case, we expected to be using one key, and hence > one SAID, per multicast group. Unless and until public key technolo gy > is *much* cheaper, I don't anticipate seeing every packet signed by > the sender. Given that, we chose to bind the SAID to the multicast > group id, i.e., the destination address. A hashed lookup is needed > here, to avoid collisions between different multicast groups. No > server is needed; the receiver will learn the SAID at the same time as > it learns the key, though I don't think we've even started to talk a bout > multicast key management yet. This assumes a very simple model of authenticating the sending host to the receiving host using a one size fits all use of SAIDs. If a SAID also authenticates a user on the sending host, we get a more dynamic assignment of SAIDs where this doesn't hold. Under the assumption that we're using symmetric algorithms for encryption and authentication, there's not a lot of point to identifying individual users or even the sending hosts in a multicast group -- everyone has the key, so anyone can impersonate anyone else. I am a fan of being able to use IPSP for user-granularity protection (see, for example, RFC 1681), but I don't think that it applies in this case. A more interesting question, to my mind, is whether anyone thinks that public key technology will improve enough that we should plan for it now in the multicast case. --Steve Bellovin ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 10:14:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27530; Wed, 15 Mar 95 10:14:29 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27524; Wed, 15 Mar 95 10:14:22 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id KAA17248; Wed, 15 Mar 1995 10:04:44 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id KAA06879; Wed, 15 Mar 1995 10:04:10 -0800 Date: Wed, 15 Mar 1995 10:04:10 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503151804.KAA06879@elrond.Eng.Sun.COM> To: hinden@servo.ipsilon.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: ipsec@ans.net X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bob, Ran has recently sent out an email message stating that he will modify the security I-D to clarify that the IANA will control the range of reserved SAIDs. I think that is helpful. However, the draft still deprecates the use of in-band keying. Why? I guess I am puzzled by your observation that the exchange "has gone beyond the point of being constructive a long while ago." If to pursue an issue is unproductive, what does this say about the whole IETF process? The author of the security I-Ds is reluctant to change them to accomodate in-band keying. Why? However, if pursuing this issue is seen by the long term participants of the IPng working group as counter-productive, then I will retire. I thought this was supposed to be an open process. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 10:23:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27548; Wed, 15 Mar 95 10:23:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27542; Wed, 15 Mar 95 10:22:54 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14787; Wed, 15 Mar 1995 10:14:05 -0800 Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AA27486; Wed, 15 Mar 95 10:13:14 PST Received: by research.att.com; Wed Mar 15 12:54 EST 1995 Received: from roc (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (8.6.9/8.6.5) with ESMTP id MAA00604; Wed, 15 Mar 1995 12:54:45 -0500 Message-Id: <199503151754.MAA00604@smb.research.att.com> From: Steve Bellovin To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: ipsec@ans.net Date: Wed, 15 Mar 1995 12:54:29 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Perhaps this debate could be ended if the text was changed to say something > like: > > The set of SAID values in the range 0x00000001 through 0x000000FF > are reserved for future use (for example "in-band keying"). > > Then perhaps everyone can go back to developing and deploying some real key > management algorithms and software which we all really need if the internet > is to have real security. In principle, I have no objection, and I'd even suggest making the reserved range larger. But the real issue is still open: what will be the common, interoperable key exchange protocol, and will it be in-band or out-of-band. We've achieved nothing if adopting this language just prolongs the debate. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 10:56:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27581; Wed, 15 Mar 95 10:56:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27575; Wed, 15 Mar 95 10:54:45 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19505; Wed, 15 Mar 1995 10:46:17 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA06450; Wed, 15 Mar 95 10:45:51 PST Received: from relay.imsi.com by wintermute.imsi.com id NAA19314; Wed, 15 Mar 1995 13:45:41 -0500 Received: from snark.imsi.com by relay.imsi.com id NAA03747; Wed, 15 Mar 1995 13:45:41 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA05021; Wed, 15 Mar 95 13:45:40 EST Message-Id: <9503151845.AA05021@snark.imsi.com> To: Danny.Nessett@Eng (Dan Nessett) Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Your message of "Wed, 15 Mar 1995 10:04:10 PST." <199503151809.AA29812@interlock.ans.net> X-Reposting-Policy: redistribute only with permission Date: Wed, 15 Mar 1995 13:45:39 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan Nessett says: > Ran has recently sent out an email message stating that he will modify the > security I-D to clarify that the IANA will control the range of reserved > SAIDs. I think that is helpful. However, the draft still deprecates the > use of in-band keying. Why? Not "deprecates". "Is not intended for". The point is this. IPSP was not intended for this use. See that big 32 bit SAID? Well, if we were to use SKIP, that whole field would be a waste of space. If we had expected to use SKIP, it never would have been there. See those transforms we spent huge amounts of time discussing? Well, SKIP uses none of them, so they were a waste of time too. In fact, SKIP could just as well use some other packet type -- nothing in IPSP is of *any* use to SKIP. Thats why the language is there. Using SKIP inside IPSP is a kludge. If we really wanted to use SKIP, this wouldn't be the standard on top of which to build it. > However, if pursuing this issue is seen by the long term participants of the > IPng working group as counter-productive, then I will retire. I thought this > was supposed to be an open process. I believe the arguments have become repetitive at this point. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 12:16:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27769; Wed, 15 Mar 95 12:16:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27763; Wed, 15 Mar 95 12:16:26 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01393; Wed, 15 Mar 1995 12:07:57 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA25874; Wed, 15 Mar 95 12:07:38 PST Received: from relay.imsi.com by wintermute.imsi.com id PAA19614 for ; Wed, 15 Mar 1995 15:07:18 -0500 Received: from snark.imsi.com by relay.imsi.com id PAA04343 for ; Wed, 15 Mar 1995 15:07:17 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA05154; Wed, 15 Mar 95 15:07:17 EST Message-Id: <9503152007.AA05154@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) More Endpoint Attributes In-Reply-To: Your message of "Wed, 15 Mar 1995 11:56:26 EST." <9503151656.AA22084@commtg3> X-Reposting-Policy: redistribute only with permission Date: Wed, 15 Mar 1995 15:07:16 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dean D. Throop says: > I agree that many of the attributes are very system/implementation/ > configuartion dependent. If we're going to overload everything onto a > single SAID, then a SAID must be able to convey everything we ever > need. Please do not confuse a Security Association with an SAID. Security Associations can have all sorts of arbitrary properties associated with them by a key management protocol. An SAID is NOT the same as an SA -- it is just an index into a table of SAs. The index is not the map which is not the territory. .pm ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 14:09:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28072; Wed, 15 Mar 95 14:09:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28066; Wed, 15 Mar 95 14:07:26 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14947; Wed, 15 Mar 1995 13:58:20 -0800 Received: from unix.ka9q.ampr.org by Sun.COM (sun-barr.Sun.COM) id AA20385; Wed, 15 Mar 95 13:58:08 PST Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.10/8.6.5) id OAA26321; Wed, 15 Mar 1995 14:02:54 -0800 Date: Wed, 15 Mar 1995 14:02:54 -0800 From: Phil Karn Message-Id: <199503152202.OAA26321@unix.ka9q.ampr.org> To: Danny.Nessett@Eng Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net In-Reply-To: <199503141714.AA44760@interlock.ans.net> (Danny.Nessett@Eng.Sun.COM) Subject: (IPng) Re: Proposed message on perfect forward security Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >I gather from your wording that you mean "prove" in the market acceptance >sense (i.e., products using key distribution mechanisms providing perfect >forward security will be widely used), rather than the mathematical or >formal logic sense. If so, then I think we agree. My arguments are not Yes. Market acceptance is the final test. Nothing the IETF does can force the market to adopt or use anything; this is the OSI lesson. My own belief is that a single, general purpose key management protocol designed for the most demanding case will be much more widely adopted by the market than a collection of incompatible protocols with different levels of security that are each supposedly epsilon more efficient in some particular circumstance. Again, consider TCP vs TP[0-4]. Phil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 15:01:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28157; Wed, 15 Mar 95 15:01:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28151; Wed, 15 Mar 95 14:58:58 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21555; Wed, 15 Mar 1995 14:50:18 -0800 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU) by Sun.COM (sun-barr.Sun.COM) id AA01254; Wed, 15 Mar 95 14:50:13 PST Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA17744; Wed, 15 Mar 95 17:50:06 EST Received: by dcl.MIT.EDU (5.0/4.7) id AA22347; Wed, 15 Mar 1995 17:50:00 +0500 Date: Wed, 15 Mar 1995 17:50:00 +0500 From: Theodore Ts'o Message-Id: <9503152250.AA22347@dcl.MIT.EDU> To: Danny.Nessett@Eng Cc: hinden@servo.ipsilon.com, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net In-Reply-To: Dan Nessett's message of Wed, 15 Mar 1995 10:04:10 -0800, <199503151809.AA29812@interlock.ans.net> Subject: Re: (IPng) Re: Proposed message on perfect forward security Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Wed, 15 Mar 1995 10:04:10 -0800 From: Danny.Nessett@Eng.Sun.COM (Dan Nessett) However, if pursuing this issue is seen by the long term participants of the IPng working group as counter-productive, then I will retire. I thought this was supposed to be an open process. Dan, Let me be frank. My impression is that your company has a proprietary product which uses in-band keying, and so you are naturally trying to push to make sure there is a place for your company's product in the standard. Thus, you don't like the fact that the IPng specifications currently say that architecture is not intended for use in using in-band keying. I think it is fair to say that we should not rule out systems that use in-band keying. However, it is also fair to say that in the interests of interoperability, we do need to pick a basic method of doing key exchange, that everyone will support. My reading of the IPng specifications is that they mandate a particular architecture for use as the basic, commonly implemented key exchange --- and the architectural direction, which has already been determined, will be using out-of-band keying scheme. The details of that still need to be worked out, of course, but at some point you have to make certain basic architectural decisions, and then move forward. Otherwise, we will end up making no progress at all. My understanding is that the common, required implementation of key-exchange which everyone must implement in the interest of interoperability, has been decided, via an open process, to use out-of-band keying. With this decision already made, unless there are some extreme, extenuating circumstances which would call for us to revisit that decision, I would think that it would be counter-productive for people to continually be insisting that this decision be re-opened, and re-examined, over and over again, ad naseum. Now, my understanding of where we are in the process may be different from what other's people understanding have been --- especially since I haven't been all that active in the IPng discussions. So, I invite people to correct my understanding of where we are in the process. But if we are where we think we are, I believe all we need to do at this point is to make sure that the current proposal do not rule out the use of in-band keying as an optional key management protocol. And, I believe this is the case already. Perhaps some of the flailing that we've had on these lists has had to do with different understandings of where we are in this process. Hopefully if we can clear this up, we can move forward and actually get some real work done. - Ted ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 15:01:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28169; Wed, 15 Mar 95 15:01:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28158; Wed, 15 Mar 95 15:01:23 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21800; Wed, 15 Mar 1995 14:52:19 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA01640; Wed, 15 Mar 95 14:52:12 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13580; 15 Mar 95 17:39 EST 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 Subject: (IPng) I-D ACTION:draft-ietf-ipngwg-bsd-api-00.txt Date: Wed, 15 Mar 95 17:36:34 -0500 Message-Id: <9503151739.aa13580@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPv6 Program Interfaces for BSD Systems Author(s) : R. Gilligan, S. Thomson, J. Bound Filename : draft-ietf-ipngwg-bsd-api-00.txt Pages : 22 Date : 03/14/1995 In order to implement the version 6 Internet Protocol (IPv6) [1] in an operating system based on Berkeley Unix (4.x BSD), changes must be made to the application program interface (API). TCP/IP applications written for BSD-based operating systems have in the past enjoyed a high degree of portability because most of the systems derived from BSD provide the same API, known informally as "the socket interface". We would like the same portability with IPv6. This memo presents a set of extensions to the BSD socket API to support IPv6. The changes include a new data structure to carry IPv6 addresses, new name to address translation library functions, new address conversion functions, and some new setsockopt() options. The extensions are designed to provide access to IPv6 features, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. 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-bsd-api-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-bsd-api-00.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) 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-bsd-api-00.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: <19950314134551.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-bsd-api-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950314134551.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 15:15:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28181; Wed, 15 Mar 95 15:15:41 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28175; Wed, 15 Mar 95 15:15:34 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id PAA03984; Wed, 15 Mar 1995 15:05:10 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id PAA07201; Wed, 15 Mar 1995 15:04:48 -0800 Date: Wed, 15 Mar 1995 15:04:48 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503152304.PAA07201@elrond.Eng.Sun.COM> To: tytso@MIT.EDU Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: hinden@servo.ipsilon.com, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > But if we are where we think we are, I believe all we need to > do at this point is to make sure that the current proposal do not rule > out the use of in-band keying as an optional key management protocol. This is all I've been asking for since the beginning. > And, I believe this is the case already. > I don't agree. Ran has stated that he will clarify the text of the security architecture document so that it is clear the "reserved" SAIDs can be allocated by the IANA for key management purposes. Fine. That removes one impediment. However, the draft still says the architecture is not intended for in-band keying. Once the I-Ds become Proposed Standards, implementors will read them without the benefit of the email that has appeared on the IPng and IPsec lists. If I was going to implement according to the existing I-Ds I would read the section deprecating the use of in-band keying to mean the AH and ESP headers should not be used for that purpose. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 16:08:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28291; Wed, 15 Mar 95 16:08:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28285; Wed, 15 Mar 95 16:08:29 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01225; Wed, 15 Mar 1995 16:00:55 -0800 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU) by Sun.COM (sun-barr.Sun.COM) id AA15192; Wed, 15 Mar 95 16:00:56 PST Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA26691; Wed, 15 Mar 95 19:00:47 EST Received: by dcl.MIT.EDU (5.0/4.7) id AA22457; Wed, 15 Mar 1995 19:00:47 +0500 Date: Wed, 15 Mar 1995 19:00:47 +0500 From: Theodore Ts'o Message-Id: <9503160000.AA22457@dcl.MIT.EDU> To: Danny.Nessett@Eng Cc: hinden@servo.ipsilon.com, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net In-Reply-To: Dan Nessett's message of Wed, 15 Mar 1995 15:04:48 -0800, <199503152304.PAA07201@elrond.Eng.Sun.COM> Subject: Re: (IPng) Re: Proposed message on perfect forward security Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Wed, 15 Mar 1995 15:04:48 -0800 From: Danny.Nessett@Eng.Sun.COM (Dan Nessett) I don't agree. Ran has stated that he will clarify the text of the security architecture document so that it is clear the "reserved" SAIDs can be allocated by the IANA for key management purposes. Fine. That removes one impediment. However, the draft still says the architecture is not intended for in-band keying. Well, that suggests one possible compromise --- which is that draft is modified to remove the comment deprecating in-band keying, but also stating that the intention is that the expectation is that the base level key exchange method will be using an out-of-band key exchange method. Is this something that everyone can live with? - Ted ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 16:34:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28324; Wed, 15 Mar 95 16:34:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28318; Wed, 15 Mar 95 16:34:41 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04685; Wed, 15 Mar 1995 16:27:06 -0800 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA20152; Wed, 15 Mar 95 16:26:46 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 16 Mar 1995 10:24:41 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Thu, 16 Mar 1995 10:25:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 16 Mar 1995 10:23:59 +1000 Date: Thu, 16 Mar 1995 10:23:59 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Mar 16 10:23:59 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 592310160395 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <592310160395*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Subject: (IPng) Re: Proposed message on perfect forward security Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Yes. Market acceptance is the final test. Nothing the IETF does can >force the market to adopt or use anything; this is the OSI lesson. >My own belief is that a single, general purpose key management >protocol designed for the most demanding case will be much more >widely adopted by the market than a collection of incompatible >protocols with different levels of security that are each supposedly >epsilon more efficient in some particular circumstance. Again, >consider TCP vs TP[0-4]. Is not the other lesson from OSI is that too many options and too much perceived complexity scares people off. I would still prefer a single mechanism but I don't know how the market will react. Do we build a Rolls Royce and allow other mechanisms (ie. complexity of options) and waste the effort because the market picks a percieved simpler approach using one of the other mechanisms? Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 17:06:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28365; Wed, 15 Mar 95 17:06:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28359; Wed, 15 Mar 95 17:06:06 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06701; Wed, 15 Mar 1995 16:58:29 -0800 Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA25438; Wed, 15 Mar 95 16:58:23 PST Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA08675 for ipng@sunroof.eng.sun.com; Wed, 15 Mar 95 18:42:47 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id QAA16758; Wed, 15 Mar 1995 16:57:51 -0800 Message-Id: <199503160057.QAA16758@aland.bbn.com> To: ipng@sunroof.Eng.Sun.COM Cc: end2end-interest@isi.edu Subject: (IPng) revised Flow ID management draft From: Craig Partridge Date: Wed, 15 Mar 95 16:57:50 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi folks: Last fall I sent around a draft of this memo and got some comments back. About 6 weeks ago, Steve Deering asked me if I could revise the draft -- I finally got time and here it is. Comments welcome. Craig End-To-End Research Group C. Partridge Request for Comments: DRAFT BBN Systems and Technologies March 1995 Using the Flow ID Field in IPv6 Status of this Memo This memo originated as the report of a discussion at an End-to-End Research Group meeting in November 1994. It has been updated to reflect comments from the IPng community. The purpose of this memo is to distill various opinions and suggestions into a set of recommendations to the IPv6 process. Distribution of this memo is unlimited. Brief Description of the Flow ID The current draft of the IPv6 specification states that every IPv6 header contains a 28-bit Flow Label, which is composed of a 4-bit traffic class field followed by a 24-bit Flow ID field. The traffic class is a priority field and can be redefined by the flow. The Flow ID is a pseudo-random number between 1 and FFFFFF (hex) that is unique when combined with the source address. The zero Flow ID is reserved to say that no Flow ID is being used. The specification requires that a source must not reuse a Flow ID value until all state information for the previous use of the Flow ID has been flushed from all routers in the internet. The specification further requires that all datagrams with the same (non-zero) Flow ID must have the same Destination Address, Hop-by-Hop Options header, Routing Header and Source Address contents. The notion is that by simply looking up the Flow ID in a table, the router can decide how to route and forward the datagram without examining the rest of the header. Flow ID Issues The current specification leaves open a number of questions, of which these three seem to be among the most important: 1. What should a router do if a datagram with a (non-zero) Flow ID arrives and the router has no state for that Flow ID? Partridge [Page 1] RFC DRAFT December 1994 2. How does an internet flush old Flow IDs? 3. Which datagrams should carry (non-zero) Flow IDs? This memo summarizes attempts to answer these questions. What Does a Router Do With Flow IDs for Which It Has No State? If a datagram with a non-zero Flow ID arrives at a router and the router discovers it has no state information for that Flow ID, what is the correct thing for the router to do? The IPv6 specification allows routers to ignore Flow IDs and also allows for the possibility that IPv6 datagrams may carry flow setup information in their options. Unknown Flow IDs may also occur if a router crashes and loses its state. During a recovery period, the router will receive datagrams with Flow IDs it does not know, but this is arguably not an error, but rather a part of the recovery period. Finally, if the controversial suggestion that each TCP con- nection be assigned a separate Flow ID is adopted, it may be neces- sary to manage Flow IDs using an LRU cache (to avoid Flow ID cache overflow in routers), in which case an active but infrequently used flow's state may have been intentionally discarded. In any case, it is clear that treating this situation as an error and, say dropping the datagram and sending an ICMP message, is inap- propriate. Indeed, it seems likely that in most cases, simply for- warding the datagram as one would a datagram with a zero Flow ID would give better service to the flow than dropping the datagram. (Note that because the flow may have redefined the meaning of the traffic class field, the datagram must be forwarded as if the traffic class field was also 0, even if the traffic class is non-zero). Of course, there will be situations in which routing the datagram as if its Flow ID were zero will cause the wrong result. An example is a router which has two paths to the datagram's destination, one via a high-bandwidth satellite link and the other via a low-bandwidth ter- restrial link. A high bandwidth flow obviously should be routed via the high-bandwidth link, but if the router loses the flow state, the router may route the traffic via the low-bandwidth link, with the potential for the flow's traffic to swamp the low-bandwidth link. It seems likely, however, these situations will be exceptions rather than the rule. So it seems reasonable to handle these situations using options that indicate that if the flow state is absent, the datagram needs special handling. (The options may be Hop-by-Hop or only handled at some routers, depending on the flow's needs). It would clearly be desirable to have some method for signalling to Partridge [Page 2] RFC DRAFT December 1994 end systems that the flow state has been lost and needs to be refreshed. One possibility is to add a state-lost bit to the Flow Label field, however, if done, this means putting the bit into the traffic class field (perhaps using value 0xF?), as there is sensi- tivity to eating into the precious 24-bits of the Flow ID field. Other possibilities adding options to the datagram to indicate its Flow ID was unknown or sending an ICMP message back to the flow source. In summary, the view is that the default rule should be that if a router receives a datagram with an unknown Flow ID, it treats the datagram as if the Flow ID and traffic class fields are zero. As part of forwarding, the router will examine any hop-by-hop options and learn if the the datagram requires special handling. The options could include simply the information that the datagram is to be dropped if the Flow ID is unknown or could contain the flow state the router should have. There is clearly room here for experimentation with option design. Flushing Old Flow IDs The flow mechanism assumes that state associated with a given Flow ID is somehow deposited in routers, so they know how to handle datagrams that carry the Flow ID. A serious problem is how to flush Flow IDs that are no longer being used (stale Flow IDs) from the routers. Stale Flow IDs can happen a number of ways, even if we assume that the source always sends a message deleting a Flow ID when the source finishes using a Flow. An internet may have partioned since the flow was created. Or the deletion message may be lost before reaching all routers. Furthermore, the source may crash before it can send out a Flow ID deletion message. The point here is that we cannot expect the source (or, for the same reasons, a third party) always to clear out stale Flow IDs. Rather, routers will have to find some mechanism to flush Flow IDs themselves. The obvious mechanism is to use a timer. Routers should discard Flow IDs whose state has not been refreshed within some period of time (say 2 minutes). At the same time, a source that crashes must observe a quiet time, during which it creates no flows, until it knows that all Flow IDs from its previous life must have expired. (Sources can avoid quiet time restrictions by keeping information about active Flow IDs in stable storage that survives crashes). This is precisely how TCP initial sequence numbers are managed and it seems the same mechanism should work well for Flow IDs. Exactly how the Flow ID and its state should be refreshed needs some study. There are two obvious options. The source could periodically Partridge [Page 3] RFC DRAFT December 1994 send out a special refresh message (such as an RSVP Path message) to explicitly refresh the Flow ID and its state. Or, the router could treat every datagram that carries the Flow ID as an implicit refresh or sources could send explicit refresh options. The choice is between periodically handling a special update message and doing an extra computation on each datagram (namely noting in the Flow ID's entry that the Flow ID has been refreshed). Which Datagrams Should Carry (Non-Zero) Flow IDs? Interestingly, this is the problem on which the least progress has been made. There were some points of basic agreement. Small exchanges of data should have a zero Flow ID, because it is not worth creating a flow for a few datagrams. Real-time flows must obviously always have a Flow ID, since flows are a primary reason Flow IDs were created. The issue is what to do with peers sending large amounts of best effort traffic (e.g., TCP connections). Some people want all long-term TCP connections to use Flow IDs, others do not. The argument in favor of using Flow IDs on individual TCP connections is that even if the source does not request special service, a net- work provider's routers may be able to recognize a large amount of traffic and use the Flow ID field to establish a special route that gives the TCP connection better service (e.g., lower delay or bigger bandwidth). Another argument is to assist in efficient demux at the receiver (i.e., IP and TCP demuxing could be done once). An argument against using Flow IDs in individual TCP connections is that it changes how we handling route caches in routers. Currently one can cache a route for a destination host, regardless of how many different sources are sending to that destination host. I.e., if five sources each have two TCP connections sending data to a server, one cache entry containing the route to the server handles all ten TCPs' traffic. Putting Flow IDs in each datagram changes the cache into a Flow ID cache, in which there is a cache entry for every TCP connection. So there's a potential for cache explosion. There are ways to alleviate this problem, such as managing the Flow ID cache as an LRU cache, in which infrequently used Flow IDs get discarded (and then recovered later). It is not clear, however, whether this will cause cache thrashing. Observe that there is no easy compromise between these positions. One cannot, for instance, let the application decide whether to use a Flow ID. Those who want different Flow IDs for every TCP connection assume that they may optimize a route without the application's knowledge. And forcing all applications to use Flow IDs will force Partridge [Page 4] RFC DRAFT December 1994 routing vendors to deal with the cache explosion issue, even if we later discover that we don't want to optimize individual TCP connec- tions. Recommendations Based on discussions in the End-to-End Research Group and on IPng mailing lists, it seems that the requirements on Flow IDs can safely be added to the IPv6 specification. 1. When a router receives a datagram with an unknown Flow ID, the router forwards the datagram as if the Flow Label field was set to zero (i.e., both traffic class and Flow ID), unless the datagram options indicate different handling is required. Note that the router is not expected to examine any options it would not examine on a datagram with a zero Flow Label. 2. Flow IDs should expire if not refreshed within some number of minutes (the exact number needs some more consideration) and flow sources should observe a quiet time equal to this inter- val after rebooting to avoid confusing Flow IDs (unless the source keeps track of Flow IDs across reboots). The exact refresh mechanism (periodic messages or options vs. implicit refreshes on each datagram) is still to be determined. The issue of which datagrams should have non-zero Flow IDs is still not decided. Acknowledgements I would like to acknowledge the assistance of the members of the End-To-End Research Group, chaired by Bob Braden, whose discussions produced this memo. I would also like to particularly thank Deborah Estrin for her help in putting this memo together. Also thanks to Richard Fox, Noel Chiappa, and Tony Li for insightful comments on the draft. Partridge [Page 5] ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 17:32:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28435; Wed, 15 Mar 95 17:32:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27245; Wed, 15 Mar 95 05:25:20 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21492; Wed, 15 Mar 1995 05:15:58 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA05517; Wed, 15 Mar 95 05:15:52 PST From: Ran Atkinson Message-Id: <9503150812.ZM664@bodhi.nrl.navy.mil> Date: Wed, 15 Mar 1995 08:12:23 -0500 In-Reply-To: Danny.Nessett@Eng.Sun.COM (Dan Nessett) "Re: (IPng) Re: Proposed message on perfect forward security" (Mar 14, 12:32) References: <199503150125.AA05096@interlock.ans.net> X-Mailer: Z-Mail (3.0.0 15dec93) To: Dan Nessett Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: ipsec@ans.net, ipng@sunroof.Eng.Sun.COM Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan, I will edit the drafts to clarify. Those "reserved for future use" SAIDs are reserved to the Internet Assigned Numbers Authority (IANA) per the universal IETF practice. The IANA has always been most reasonable about allocating numbers in all cases for the entire past for all protocols where IANA controls number spaces. It is often the case that IANA wants a public specification (e.g. Informational RFC or Experimental RFC or Standards-track RFC) to exist before granting the number. I will support allocating _1_ of the reserved SAIDs to SKIP once there is a public specification for how SKIP would be used. That public spec would need to be reasonably complete and reasonably clear (i.e. clear enough that someone else could implement it if patent issues and such did not exist). Such allocation would be the decision of the IANA, but there are zero cases where IANA has been unreasonable about allocating numbers. If I understand Ted, Bill, Perry, and Jeff correctly, they would also support allocating _1_ of the reserved SAIDs to SKIP once there were a clear public spec for how SKIP would be implemented/used with the IPv4/v6 security mechanisms. (Jim, The same applies for any "in-band" (sic) protocol that DEC would like to use. DEC should have no trouble obtaining a reserved SAID upon publication of an open specification for its key management scheme should DEC choose to go down that path :-). Because the IPv6/v4 security drafts are standards-track and the use of SKIP is not currently standards-track (or even the consensus of the IPsec WG, unlike Photuris which does have rough consensus in the IPsec WG), it is not appropriate for those IPv4/v6 drafts to specifically allocate an SAID to SKIP at this time. Furthermore, there is no I-D or RFC describing how SKIP would be used with IPv4/v6 security so it would be granting a special privilege to an undocumented protocol that is currently completely proprietary. This also makes it inappropriate for a standards-track specification such as the IPv4/IPv6 security drafts. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 18:36:18 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28518; Wed, 15 Mar 95 18:36:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28512; Wed, 15 Mar 95 18:36:11 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15775; Wed, 15 Mar 1995 18:28:35 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA09859; Wed, 15 Mar 95 18:28:32 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA28310; Thu, 16 Mar 1995 13:27:56 +1100 (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 AA03869; Thu, 16 Mar 95 12:08:50 +1000 Received: by dcthq2.datacraft.com.au; Thu, 16 Mar 95 13:27:03 +1100 Date: Thu, 16 Mar 95 13:08:45 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: (IPng) Re: Proposed message on perfect forward security X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM can I put my two bobs worth in on this one. Is there any approach to the security of the internet and how it is deployed in terms of migration from IP4. ie. If IP6 is carried over IP4 the security mechanisms are end to end. The network is still insecure and this will be the case for years. If IP6 routers have to deal with IP4 and IP6 + AH how do you measure trust in these devices. If the device isnt trusted, why is it verifying headers? If there are many routers in a path which convert / tunnel IP4 and IP6 how is the path made secure at the network level. Would the security management protocol have to know which routers it has to talk and which ones are incapable of "security processing" - on a global scale. I think the AH in IP6 is a bit like the flow Id. Its all right for contained IP6 networks, but has no network centred function in the transistion process or at best will be an operational nightmare. I perceive that the AH and ESP features are being considered collectively. When in fact what should be done is just have an ESP which can be carried over IP4 or 6. This may have been covered on the IPsec list. apologies if so. Globally managed Flow Ids.. HMMMMMM Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 20:17:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28574; Wed, 15 Mar 95 20:17:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28568; Wed, 15 Mar 95 20:17:29 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21270; Wed, 15 Mar 1995 20:09:54 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA21417; Wed, 15 Mar 95 20:09:47 PST Received: from relay.imsi.com by wintermute.imsi.com id XAA21510; Wed, 15 Mar 1995 23:09:46 -0500 Received: from snark.imsi.com by relay.imsi.com id XAA08580; Wed, 15 Mar 1995 23:09:45 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA06011; Wed, 15 Mar 95 23:09:44 EST Message-Id: <9503160409.AA06011@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Your message of "Wed, 15 Mar 1995 15:04:48 PST." <199503152304.PAA07201@elrond.Eng.Sun.COM> X-Reposting-Policy: redistribute only with permission Date: Wed, 15 Mar 1995 23:09:44 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I apologize for replying one last time to this. As a consolation to readers, let me note that its my last word on the subject. Dan Nessett says: > I don't agree. Ran has stated that he will clarify the text of the security > architecture document so that it is clear the "reserved" SAIDs can be > allocated by the IANA for key management purposes. Fine. That removes one > impediment. However, the draft still says the architecture is not intended > for in-band keying. And it is indeed not designed for SKIP style keying. (I refuse to say "in-band" by the way because it is an inaccurate term.) I see no purpose in removing a factual statement from the documents. Trying to make SKIP fit into IPSP is very unnatural. As I repeatedly note, SKIP neither uses SAIDs nor the defined IPSP transforms. It ends up using IPSP as an unreliable datagram protocol -- you might as well build it on top of UDP given the amount of IPSP functionality you make use of. You note that naive readers will think that the design wasn't intended for SKIP style systems -- but it *wasn't*, and I indeed want naive readers to understand how the design was intended to work. I strongly recommend against any removal of the stated text from the draft precisely because it will make the purpose of the features of IPSP less clear and reduce the ability of readers to understand the architecture. Thats all there is to say. From what I can tell, this has been beaten into the ground. I see no reason to discuss it further, and therefore I won't. You all know my position. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 21:52:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28595; Wed, 15 Mar 95 21:52:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28589; Wed, 15 Mar 95 21:52:00 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25201; Wed, 15 Mar 1995 21:44:24 -0800 Received: from mail1.digital.com by Sun.COM (sun-barr.Sun.COM) id AA01288; Wed, 15 Mar 95 21:44:26 PST Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 2/22/95 for V3.2/1.0/WV) id AA10321; Wed, 15 Mar 1995 21:28:46 -0800 Received: by xirtlu.zk3.dec.com; id AA29567; Thu, 16 Mar 1995 00:27:54 -0500 Message-Id: <9503160527.AA29567@xirtlu.zk3.dec.com> To: karn@qualcomm.com Cc: Danny.Nessett@Eng, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Your message of "Wed, 15 Mar 95 14:02:54 PST." <199503152158.AA15456@interlock.ans.net> Date: Thu, 16 Mar 95 00:27:48 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Phil, >My own belief is that a single, general purpose key management >protocol designed for the most demanding case will be much more widely >adopted by the market than a collection of incompatible protocols with >different levels of security that are each supposedly epsilon more >efficient in some particular circumstance. Again, consider TCP vs >TP[0-4]. I think your right regarding the odds for market acceptance. My belief is that we still have a lot of work to do regarding key management in general. I think this will require discussion about our technical beliefs/assumptions where technology must or will be in the future, and what the market can absorb regarding function and cost. Often we say this is not a technical discussion but in fact it truly is and is often at the crux of disagreement. It also is a MUST before an engineer can fully buy-in to any specification. We have to discuss more than just the bits and bytes, to understand the affect of a technology on the total network system. Working on Ran's drafts for some time (SIP, SIPP, and now IPv6) I have reviewed it technically as to the affect to a host kernel as a network layer header and how the design will affect that part of the code base for IPv6 in a network operating system. Now that it may move to proposed standard we must look at it from the perspective of key management too. Until recently there was not a discussion on this topic in SIP, SIPP, or IPv6. I think IPSEC should do that work and I think its started. I do not think TCP vs TP[0-4] is a fair analysis to in-band vs out-band. TCP and TPxxx are two different protocol suites, two different AFs to a socket, and I believe two different philosophies towards the functions of a transport layer protocol. In-band is an option customers may want to use who do not need perfect forwarding security. Everything else about the ip6_input layer is the same, all that changes is the module that processes the IPv6 Security Header (at least in our implementation design). What is not clear to me is what will the out-band key management winner be? To do testing I am assuming we will have to agree to use some out-band method to test Ran's specs in the kernel and at the application layer too. It would be nice if we could get some folks like yourself to agree soon what is a good way for IPv6 implementors to test our implementations. What about kerberos? I think all can get code to do this? [just for interoperability testing]. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 22:02:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28610; Wed, 15 Mar 95 22:02:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28604; Wed, 15 Mar 95 22:02:40 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25553; Wed, 15 Mar 1995 21:55:04 -0800 Received: from mail1.digital.com by Sun.COM (sun-barr.Sun.COM) id AA02161; Wed, 15 Mar 95 21:55:06 PST Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 2/22/95 for V3.2/1.0/WV) id AA07017; Wed, 15 Mar 1995 21:39:37 -0800 Received: by xirtlu.zk3.dec.com; id AA29625; Thu, 16 Mar 1995 00:38:46 -0500 Message-Id: <9503160538.AA29625@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: Danny.Nessett@Eng, hinden@servo.ipsilon.com, ipsec@ans.net Subject: Re: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Your message of "Wed, 15 Mar 95 17:50:00 +0500." <9503152250.AA22347@dcl.MIT.EDU> Date: Thu, 16 Mar 95 00:38:40 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ted, >Date: Wed, 15 Mar 1995 17:50:00 +0500 >From: Theodore Ts'o > My understanding is that the common, required implementation of >key-exchange which everyone must implement in the interest of >interoperability, has been decided, via an open process, to use >out-of-band keying. With this decision already made, unless there are >some extreme, extenuating circumstances which would call for us to >revisit that decision, I would think that it would be counter-productive >for people to continually be insisting that this decision be re-opened, >and re-examined, over and over again, ad naseum. Besides the in-band/out-band discussion. We have input to Ran regarding other parts of the specifications from Phil Rogaway, Dean Throop, and Andy Bayerl that will affect the specification, I would like to see responses to that input publicly as the questions and input were relative as to whether the specs are ready for proposed standard before Danvers. I have not decided in my mind if they may cause a change to the architecture, which Ran needs to give us his view of that set of input. Whether it affects keying I am not sure, but I think not? I do not think its counter-productive to implement the specs as they exist today, and because of interoperability testing, cause a change if necessary to the architecture or to the method or methods that can be implemented for customers who want to use IPv6 Security. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 15 22:14:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28622; Wed, 15 Mar 95 22:14:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28616; Wed, 15 Mar 95 22:14:35 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26041; Wed, 15 Mar 1995 22:06:59 -0800 Received: from mail1.digital.com by Sun.COM (sun-barr.Sun.COM) id AA03297; Wed, 15 Mar 95 22:07:02 PST Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 2/22/95 for V3.2/1.0/WV) id AA09815; Wed, 15 Mar 1995 21:45:31 -0800 Received: by xirtlu.zk3.dec.com; id AA29668; Thu, 16 Mar 1995 00:44:40 -0500 Message-Id: <9503160544.AA29668@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: Danny.Nessett@Eng, hinden@servo.ipsilon.com, ipsec@ans.net Subject: Re: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Your message of "Wed, 15 Mar 95 19:00:47 +0500." <9503160000.AA22457@dcl.MIT.EDU> Date: Thu, 16 Mar 95 00:44:34 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ted, >Date: Wed, 15 Mar 1995 19:00:47 +0500 >From: Theodore Ts'o >Well, that suggests one possible compromise --- which is that draft is >modified to remove the comment deprecating in-band keying, but also >stating that the intention is that the expectation is that the base >level key exchange method will be using an out-of-band key exchange >method. >Is this something that everyone can live with? Yes regarding the subject/topic of keying in the specs. This states the base key exchange method and does not mention others that may develop. This will let competition exist which IMHO is OK for any proposed standard evolution, and in fact good. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 16 10:20:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28802; Thu, 16 Mar 95 10:20:27 PST Received: from eunuchs.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28796; Thu, 16 Mar 95 10:20:18 PST Received: by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA02277; Thu, 16 Mar 1995 10:12:46 -0800 Received: from snail.Sun.COM by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA02259; Thu, 16 Mar 1995 10:12:42 -0800 Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA07364; Thu, 16 Mar 95 10:12:40 PST Received: from ns.incog.com by Sun.COM (sun-barr.Sun.COM) id AA28867; Thu, 16 Mar 95 10:12:29 PST Received: by ns.incog.com (8.6.10/94082501) id KAA25341; Thu, 16 Mar 1995 10:12:54 -0800 Received: from osmosys.incog.com by ns.incog.com (8.6.10/94082501) id KAA25326; Thu, 16 Mar 1995 10:12:52 -0800 Received: from miraj.incog.com by osmosys.incog.com (5.x/SMI-SVR4) id AA22457; Thu, 16 Mar 1995 10:12:31 -0800 Received: by miraj.incog.com (5.x/SMI-SVR4) id AA00771; Thu, 16 Mar 1995 10:24:24 -0800 Date: Thu, 16 Mar 1995 10:24:24 -0800 From: ashar@icgmail.Eng.Sun.COM (Ashar Aziz) Message-Id: <9503161824.AA00771@miraj.incog.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipsec@ans.net X-Sun-Charset: US-ASCII X-Icg-Mailfrom: ashar@icgmail.eng.sun.com Subject: Re: (IPng) Re: Proposed message on perfect forward security Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: "Theodore Ts'o" > Well, that suggests one possible compromise --- which is that draft is > modified to remove the comment deprecating in-band keying, but also > stating that the intention is that the expectation is that the base > level key exchange method will be using an out-of-band key exchange > method. > > Is this something that everyone can live with? Ted, In the interest of bringing this unfortunately long debate to an end, I will say "Yes". Not that this solution is ideal from my perspective, but that it appears to be better than the current situation. I believe that the correct way to resolve this issue is to actually build and deploy security/key-mgmt in the extremely diverse environments/applications possible in the Internet, and therefore to the extent that this permits experimentation with alternative approaches, I am for it. Ultimately, as we have all agreed, the market will decide the approach it prefers. Thanks, BTW for making a compromise proposal. Kind regards, Ashar. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 16 10:44:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28853; Thu, 16 Mar 95 10:44:08 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28847; Thu, 16 Mar 95 10:44:01 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id KAA02398; Thu, 16 Mar 1995 10:36:02 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id KAA00428; Thu, 16 Mar 1995 10:35:44 -0800 Date: Thu, 16 Mar 1995 10:35:44 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199503161835.KAA00428@elrond.Eng.Sun.COM> To: tytso@MIT.EDU Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: hinden@servo.ipsilon.com, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ted, In the interests of getting this settled, I would accept the compromise. Dan > From tytso@MIT.EDU Wed Mar 15 16:01:12 1995 > To: Danny.Nessett@Eng > Cc: hinden@servo.ipsilon.com, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net > Subject: Re: (IPng) Re: Proposed message on perfect forward security > Address: 1 Amherst St., Cambridge, MA 02139 > Phone: (617) 253-8091 > > Date: Wed, 15 Mar 1995 15:04:48 -0800 > From: Danny.Nessett@Eng.Sun.COM (Dan Nessett) > > I don't agree. Ran has stated that he will clarify the text of the security > architecture document so that it is clear the "reserved" SAIDs can be > allocated by the IANA for key management purposes. Fine. That removes one > impediment. However, the draft still says the architecture is not intended > for in-band keying. > > Well, that suggests one possible compromise --- which is that draft is > modified to remove the comment deprecating in-band keying, but also > stating that the intention is that the expectation is that the base > level key exchange method will be using an out-of-band key exchange > method. > > Is this something that everyone can live with? > > - Ted > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 16 16:05:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29359; Thu, 16 Mar 95 16:05:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29353; Thu, 16 Mar 95 16:05:16 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18084; Thu, 16 Mar 1995 15:57:41 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA15898; Thu, 16 Mar 95 15:55:12 PST Received: from Support.DCPCAN.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA25296; Fri, 17 Mar 1995 10:54:00 +1100 (from Kim.Fenley@Support.DCPCAN.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA06810; Fri, 17 Mar 95 09:34:52 +1000 Received: by dcthq2.datacraft.com.au; Fri, 17 Mar 95 10:53:38 +1100 Date: Fri, 17 Mar 95 10:39:36 +1100 Message-Id: <0X87+ZwAOja@dcthq2.datacraft.com.au> From: Kim.Fenley@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: Re[4]: (IPng) True Internationalism X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Wrote: | | Jeff and others I believe that Harris is developing and encrypter to be in hardware along the lines of the Clipper algorithm and is called the "Redbrick". My understanding is that this will be exportable. The problem is that everyone has to be able to decipher, not a a case-by-case basis. Kim@oz | >The controls have got to go to enable this stuff to work, | and be | >profitable. | | If it can't be "open" and it can't be exported, then as | others have | said, it will have to be made outside the US. Profit and | economics | tends to pretty major political driving factors for change. | I am | happy enough now that as long as the specs are available then | we can | live with non US sourced p r o d u c t s ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 16 19:59:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29463; Thu, 16 Mar 95 19:59:06 PST Received: from auckland.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29457; Thu, 16 Mar 95 19:58:55 PST Received: by auckland.Eng.Sun.COM (5.x/SMI-SVR4) id AA12802; Thu, 16 Mar 1995 19:50:43 -0800 Date: Thu, 16 Mar 1995 19:50:43 -0800 From: finlayson@auckland (Ross Finlayson) Message-Id: <9503170350.AA12802@auckland.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM, craig@aland.bbn.com Subject: (IPng) Re: revised Flow ID management draft Cc: end2end-interest@ISI.EDU X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Craig, The following two sections of the document appear contradictory, or at the very least, confusing. Ross. ------------------------------------------ > The Flow ID is a pseudo-random number between 1 and FFFFFF (hex) that > is unique when combined with the source address. ......... > The specification further requires that all datagrams with the same > (non-zero) Flow ID must have the same Destination Address, Hop-by-Hop > Options header, Routing Header and Source Address contents. ^^^^^^^^^^^^^^ ------------------------------------------ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 16 21:07:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29479; Thu, 16 Mar 95 21:07:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29473; Thu, 16 Mar 95 21:07:13 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09625; Thu, 16 Mar 1995 20:59:36 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA26668; Thu, 16 Mar 95 20:59:30 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA10916; Fri, 17 Mar 1995 15:58:49 +1100 (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 AA08230; Fri, 17 Mar 95 14:40:25 +1000 Received: by dcthq2.datacraft.com.au; Fri, 17 Mar 95 15:59:13 +1100 Date: Fri, 17 Mar 95 15:01:35 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: Re Re Re4 (IPng) Last Call etc.... X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM just been going through the backlog on this one. can I make some statements re the debate presented. "intercontinental ATM will affect national boundaries." However the numbering plans used are nationally applied and this will be the case for years. Probably while the atlas is still being printed or CD'd. "Telephone calls take a long time to set up whereas data switching has to be instant." Telephone call set up checks calling party, billing, valid destinations, obtain capacity, etc. However, once set up bit rate throughput generally applies. Telephone numbers traditionally work on geographical groupings. Mobile telephones and 008 nos work with "logical" addresses which are processed IN THE NETWORK with some very heavy duty - distributed iron. Signalling schemes are now separating call information from connection information so that the users can be identified distinctly from the network endpoints that serve them. (for billing, multiparty etc). People require a number (or a limited set) to be able to communicate with others. These should not changed as the result of "switching providers". ie people naturally use geographic, logical and combination (geog -log) numbers. what I seem to be seeing is that the IP address form which is for a connection less global service is trying to be all things. ie deal with network topology- tree or mesh, be dynamically assigned, permit mobility, multi homing, be non geographic and be used for multicast purposes. Not fogetting that with the above, the addresses must be registered, allocated and managed. AND all this will be performed at network end points. So some minor points. address forms should only represent some decomposition of the network space in terms of route agrigation and administration. 4-6 levels seems a reasonable choice. (eg. region,country (or logical id), rd,subnet,system ) the form should be in geographical and logical forms. This takes care of the muti national providers. Registration Authorities must be declared to represent the decomposition levels or approximations thereof. wrt to network meshing, this will have to taken care of by the network designers / implementation. wrt to address re use and management, this is performed procedurally through the Registration Authorities. And can be achied with automated mechanisms. wrt auto assignment, this can only be performed within limited scopes say within specified routing domains. One cannot build simple mechanisms which dynamically assign global addresses on demand - across the whole planet. the problems I see that the addressing ideals presented would require some connection oriented approach, with different semantics placed on callers and connections and some fairly heavy duty functions (user directories, mobile tracking, address databases, switch management, etc) IN the network. The comments i make about the management of flow ids and auth headers for global operation also apply. To set these up for global transfers one is setting up an environment within a network. Just as a connection oriented service would do with its signalling system. To close this off. Are we taking a datagram with a 16 byte address form and now trying to turn it into a global, fully scalable, secure, predicatble, accountable network which auto configures and cannot be monopolised by address registration authorities and national influence. If we are we will never tie the format of the address down and its registration process unles someone puts some rules in place re the above. It is pointless IMHO to believe that the ideals presented for IP6 addressing scheme can be achieved with a few end system mechanisms if there is no commitment to central network functions. Major ones at that. I think the biggest problem that faces us is the consolidation of the IP4 space legal and illegal addresses and its operational mapping to the new IP6 space. This needs a bit of methodology and a plan. Lets keep the IP6 addressing simple.. please. Regards alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 16 23:44:54 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29499; Thu, 16 Mar 95 23:44:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29493; Thu, 16 Mar 95 23:44:47 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15081; Thu, 16 Mar 1995 23:37:10 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA12378; Thu, 16 Mar 95 23:37:08 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA17599; Fri, 17 Mar 1995 18:37:00 +1100 (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 AA08777; Fri, 17 Mar 95 17:18:41 +1000 Received: by dcthq2.datacraft.com.au; Fri, 17 Mar 95 18:37:33 +1100 Date: Fri, 17 Mar 95 18:07:10 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) questions on IP6apis X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=YES Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM begin 600 attach.Z M'YV0:=R,>7/&31HZ;URTF7,&@,.'$"-*G$BQHL6+&"N"V&BC(P@`&T'$H$'C M8\B1)4&&/$DCQHV--6[,D"%CA@T8-VILC"$CQHP:(&%D'$JTJ-&C$^O,H1-& MSD8`;-Z,"<,&*<6H4ZM:WO8,-NI8.FS)PR(-J$R0-"#%HR==J(`1&G MCEDZ:=ZXF=-`05^R:(-`20*"C%00<.2\L9.&C%D0;LK<*5S&S!P0""E3!7'G M(!H08>L1O,&#@@%`^NXH7,YC!LR(,Q$G=QX MCHN^?>^@"4.G\!O0<."PN6P8M)@WKD&4^8WY^7;@M?'JO:QW#%K`;)O"-A.P M#!D7H$EC+GOV-IPP<\X")]OZS&?`(,P11AMHA0%'&C\@IT!U9`5TQF5LI+$& M6G.\02`(;Y@Q'UJ139;$$$U`D59I89SQF(G-W9>?>_/U]]]S`!HHW6U450A? M&6=PMEQS:6CH&PA)0%&2C&R`@&)O(*0Q1ANV=486"+J1-E!!:>@'@@A!VC"? M@R*`,-!E"@"('1W7Z09$4I(#5I\!R=ISW7*!)NK%G M:Z_)<1D*84C*)E-)DI>=&(6N219S\:$5T)[WD;6:88^%N2B1H$WW'*>>@K"& M&V],!B"I!7('8*>FYK47AAH&.1^MZMTVQZ!PH/8:<+L\\X\]^SSST`'+?301!=M]-%()ZWTTDPW[?334$M]MILM^WVVW#'+??<=-=M]]UXYZWW 2WGSW[???@` Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29613; Fri, 17 Mar 95 06:50:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29607; Fri, 17 Mar 95 06:49:59 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02394; Fri, 17 Mar 1995 06:42:23 -0800 Received: from nbkanata.Newbridge.COM (Newbridge.COM) by Sun.COM (sun-barr.Sun.COM) id AA20091; Fri, 17 Mar 95 06:42:22 PST Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1) id AA24949; Fri, 17 Mar 95 09:42:19 EST Received: from mako.newbridge.com by Newbridge.COM (4.1/SMI-4.0) id AA00358; Fri, 17 Mar 95 09:40:20 EST Received: from lobster.Newbridge.COM by mako.newbridge.com (4.1/SMI-4.1) id AA15989; Fri, 17 Mar 95 09:38:08 EST Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA02025; Fri, 17 Mar 1995 09:38:16 +0500 Date: Fri, 17 Mar 1995 09:38:16 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9503171438.AA02025@lobster.Newbridge.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) questions on IP6apis X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Your mailer is at it again. Good luck stopping it. Joel M. Halpern ----- Begin Included Message ----- From owner-ipng@sunroof2.Eng.Sun.COM Fri Mar 17 02:41:04 1995 Date: Fri, 17 Mar 95 18:07:10 +1100 From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) questions on IP6apis X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=YES begin 600 attach.Z M'YV0:=R,>7/&31HZ;URTF7,&@,.'$"-*G$BQHL6+&"N"V&BC(P@`&T'$H$'C M8\B1)4&&/$DCQHV--6[,D"%CA@T8-VILC"$CQHP:(&%D'$JTJ-&C$^O,H1-& MSD8`;-Z,"<,&*<6H4ZM:WO8,-NI8.FS)PR(-J$R0-"#%HR==J(`1&G MCEDZ:=ZXF=-`05^R:(-`20*"C%00<.2\L9.&C%D0;LK<*5S&S!P0""E3!7'G M(!H08>L1O,&#@@%`^NXH7,YC!LR(,Q$G=QX MCHN^?>^@"4.G\!O0<."PN6P8M)@WKD&4^8WY^7;@M?'JO:QW#%K`;)O"-A.P M#!D7H$EC+GOV-IPP<\X")]OZS&?`(,P11AMHA0%'&C\@IT!U9`5TQF5LI+$& M6G.\02`(;Y@Q'UJ139;$$$U`D59I89SQF(G-W9>?>_/U]]]S`!HHW6U450A? M&6=PMEQS:6CH&PA)0%&2C&R`@&)O(*0Q1ANV=486"+J1-E!!:>@'@@A!VC"? M@R*`,-!E"@"('1W7Z09$4I(#5I\!R=ISW7*!)NK%G M:Z_)<1D*84C*)E-)DI>=&(6N219S\:$5T)[WD;6:88^%N2B1H$WW'*>>@K"& M&V],!B"I!7('8*>FYK47AAH&.1^MZMTVQZ!PH/8:<+L\\X\]^SSST`'+?301!=M]-%()ZWTTDPW[?334$M]MILM^WVVW#'+??<=-=M]]UXYZWW 2WGSW[???@` Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29663; Fri, 17 Mar 95 07:59:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29657; Fri, 17 Mar 95 07:59:28 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07038; Fri, 17 Mar 1995 07:51:52 -0800 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA01498; Fri, 17 Mar 95 07:51:35 PST Received: by mitsou.inria.fr (8.6.10/8.6.10) id QAA01324; Fri, 17 Mar 1995 16:51:23 +0100 Message-Id: <199503171551.QAA01324@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Cc: end2end-interest@isi.edu Subject: Re: (IPng) revised Flow ID management draft In-Reply-To: Your message of "Wed, 15 Mar 1995 16:57:50 PST." <199503160057.QAA16758@aland.bbn.com> Date: Fri, 17 Mar 1995 16:51:23 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Craig, Your recent draft on "how to use flow ids" seems to imply that the normal usage of flow ids is to associate some set up with a flow. I have a different understanding, which triggers some different reactions, and also an additional question: 1. What should a router do if a datagram with a (non-zero) Flow ID arrives and the router has no state for that Flow ID? * Route the datagram as if the flow-id was null is indeed the solution, but I don't see why one should ignore the "traffic class" field. * Also, I believe that this is by no means an "error", but simply the normal occurence of the first packet within a flow. The router is going to perform several computations based on the destination address and the hop-by-hop options. If the destination is local and a "routing header" follows the plain header, it may have to perfrom further computations. It is natural to cache the result of these computations in an LRU cache, so as to expedite the processing of further packets for the same flow. 2. How does an internet flush old Flow IDs? * With a timer indeed. But look at the additional question. 3. Which datagrams should carry (non-zero) Flow IDs? * It is reasonable to initiate a flow whenever one knows that several packets are going to be sent "on the same path", i.e. with the same destination, hop by hop arguments and routing header. Whether these are one or many TCP connections or one or many UDP packet is irrelevant. "Real time" is irrelevant too, unless you are capable of defining what is "real time" and what is not. And now, the additional question: 4. What should a router do if it receive a packet with a "wrong" flow-id? Routers may, but need not, keep flow information in their memory. The flow information may include those parameters which are supposed to stay constant for a flow, i.e. the destination address, the hop by hop options and in some cases the routing header. Suppose now that a router receives a packet for a flow Id which is "already known", i.e. where an entry exist for the same flow-id and source address in the local memory. The router may decide to compare the packet destination with the destination address associated to the flow in the local memory; it may also check that the hop by hop options and the routing header are consistent. If it does check, it can indeed detect a mismatch. What to do then? My personal suggestion: * This normally indicates an error. The packet should be deleted, an ICMP report may be sent back. * It may result from caching an old information for too long. The cache should thus be flushed - or at least its flushing should be scheduled. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 17 08:24:49 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29706; Fri, 17 Mar 95 08:24:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29700; Fri, 17 Mar 95 08:24:41 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08903; Fri, 17 Mar 1995 08:17:05 -0800 Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA05937; Fri, 17 Mar 95 08:17:02 PST Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA10486 for ipng@sunroof.eng.sun.com; Fri, 17 Mar 95 10:01:27 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id IAA18527; Fri, 17 Mar 1995 08:13:29 -0800 Message-Id: <199503171613.IAA18527@aland.bbn.com> To: Christian Huitema Cc: ipng@sunroof.Eng.Sun.COM Cc: end2end-interest@isi.edu Subject: Re: (IPng) revised Flow ID management draft In-Reply-To: Your message of Fri, 17 Mar 95 16:51:23 +0100. <199503171551.QAA01324@mitsou.inria.fr> From: Craig Partridge Date: Fri, 17 Mar 95 08:13:27 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi Christian: 1. What should a router do if a datagram with a (non-zero) Flow ID arrives and the router has no state for that Flow ID? * Route the datagram as if the flow-id was null is indeed the solution, but I don't see why one should ignore the "traffic class" field. Because IPv6 allows the flow to redefine the meaning of the traffic class field. Thus we must ignore it if the flow id is set (on the grounds we might otherwise harmfully misunderstand it). 3. Which datagrams should carry (non-zero) Flow IDs? * It is reasonable to initiate a flow whenever one knows that several pack ets are going to be sent "on the same path", i.e. with the same destination, hop by hop arguments and routing header. Whether these are one or many TCP connections or one or many UDP packet is irrelevant. "Real time" is irrelevant too, unless you are capable of defining what is "real time" a nd what is not. Exactly who should use Flow IDs remains a subject of debate. I'll see if I can find a way to fit your view in too. 4. What should a router do if it receive a packet with a "wrong" flow-id? * This normally indicates an error. The packet should be deleted, an ICMP report may be sent back. * It may result from caching an old information for too long. The cache should thus be flushed - or at least its flushing should be scheduled. Good points, I'll add them. Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 17 17:36:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29976; Fri, 17 Mar 95 17:36:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29970; Fri, 17 Mar 95 17:35:54 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10715; Fri, 17 Mar 1995 17:28:17 -0800 Received: from lobster.wellfleet.com ([192.32.253.3]) by Sun.COM (sun-barr.Sun.COM) id AA06036; Fri, 17 Mar 95 12:36:23 PST Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA24094; Fri, 17 Mar 95 15:32:29 EST Received: from maggie.wellfleet by wellfleet (4.1/SMI-4.1) id AA01291; Fri, 17 Mar 95 15:37:22 EST Date: Fri, 17 Mar 95 15:37:22 EST From: jkrawczy@pobox.wellfleet.com (John Krawczyk) Message-Id: <9503172037.AA01291@wellfleet> Received: by maggie.wellfleet (4.1/SMI-4.1) id AA00471; Fri, 17 Mar 95 15:34:42 EST To: ipng@sunroof.Eng.Sun.COM Cc: end2end-interest@isi.edu Subject: Re: (IPng) revised Flow ID management draft In-Reply-To: <199503171551.QAA01324@mitsou.inria.fr> References: <199503160057.QAA16758@aland.bbn.com> <199503171551.QAA01324@mitsou.inria.fr> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Fri, 17 March, Christian Huitema (Christian.Huitema@sophia.inria.fr) wrote: Suppose now that a router receives a packet for a flow Id which is "already known", i.e. where an entry exist for the same flow-id and source address in the local memory. The router may decide to compare the packet destination with the destination address associated to the flow in the local memory; it may also check that the hop by hop options and the routing header are consistent. If it does check, it can indeed detect a mismatch. What to do then? This is a very key point: is the verification of the flow id in this manner a MAY, SHOULD, or MUST? (no, I don't expect an answer yet...) If the check is done, this takes away from forwarding performance (which is why we're doing the flow-id in the first place). If the check is not done, I can imagine all sorts of hacker tricks one could do given the knowledge of which routers ignore flow-ids, which use but do not verify flow-ids, and which use and verify them. * This normally indicates an error. Or maybe an intentional attack... The packet should be deleted, an ICMP report may be sent back. * It may result from caching an old information for too long. The cache should thus be flushed - or at least its flushing should be scheduled. In either case, it would be a good idea for the router to log the event. -jj ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 17 20:53:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00264; Fri, 17 Mar 95 20:53:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00258; Fri, 17 Mar 95 20:53:49 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21215; Fri, 17 Mar 1995 20:46:12 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA14758; Fri, 17 Mar 95 20:46:13 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA05865; Fri, 17 Mar 95 23:46:12 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503180446.AA05865@wizard.gsfc.nasa.gov> Subject: Re: (IPng) Base IPv6 Specification: Robust Service vs Lack of Header Checksum To: ipng@sunroof.Eng.Sun.COM Date: Fri, 17 Mar 1995 23:46:11 -0500 (EST) In-Reply-To: <9503102034.AA08705@wchung.raleigh.ibm.com> from "Thomas Narten" at Mar 10, 95 03:34:36 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Fri, 10 Mar 95 15:34:36 -0500 > From: "Thomas Narten" > > It seems to me that the issue Bill Fink raises can be summed up as: > "What is the probability that a mangled packet will be improperly > processed by a router"? Christian (and the group as a whole) argue > that the probability is low because of the sparseness of flow labels & > address bits. Bill then goes on to argue that a checksum is needed to > make the probability acceptably low. > > The essential issue here seems to concern "cache keys", the bits a > router extracts from the packet header to locate the state associated > with the packet's flow label. > > ... Thomas, Thanks for expressing the concerns I had much more succinctly, and adding a theoretical perspective. I don't know that anyone has a precise handle on the risk of undetected packet corruption causing a collision in the "cache keys" if 10**12 (or 10**15) hosts are sharing the 10**7 Flow ID space, or the resultant possible level or scope of impact to the Internet that might be caused by such an event. However, Christian's suggestion of including the destination address in the "cache key" has convinced me that it is possible to significantly reduce the level of risk introduced by high-volume, very broad multicast distribution of flows. I still have some remaining qualms, but they are not nearly as pronounced as before. Your idea of including guard bits in the Flow ID itself is interesting. Since my major concern is protecting against rogue flows, this would be a possible mechanism for protecting flows without impacting other non-flow IP traffic, i.e. traditional best-effort datagram delivery. -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 17 21:05:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00276; Fri, 17 Mar 95 21:05:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00270; Fri, 17 Mar 95 21:05:27 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21461; Fri, 17 Mar 1995 20:57:49 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA15308; Fri, 17 Mar 95 20:57:50 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA05889; Fri, 17 Mar 95 23:57:49 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503180457.AA05889@wizard.gsfc.nasa.gov> Subject: Re: (IPng) ICMP limit exceeded To: ipng@sunroof.Eng.Sun.COM Date: Fri, 17 Mar 1995 23:57:49 -0500 (EST) In-Reply-To: <4235.Bill.Simpson@um.cc.umich.edu> from "William Allen Simpson" at Mar 11, 95 01:44:39 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Sat, 11 Mar 95 01:44:39 GMT > From: "William Allen Simpson" > > > From: bill@wizard.gsfc.nasa.gov (Bill Fink) > > The A case, time exceeded, hop limit exceeded, ... > > suggested changing this to the address of the router corresponding to > > the interface upon which the original packet was received that caused > > the ICMP error message to be generated. These are not the same in the > > case of asymmetric routing between the original source and the router > > generating the ICMP error message, and the change I suggested is what > > is required to make traceroute most meaningful. > > > Since when does traceroute work this way in IPv4? If a particular facet of IPv4 is imprecise, inconsistent, or less useful than it could be, IPv6 is an opportunity to correct matters. > How is it less meaningful? One of the interfaces is learned. Sure, it > may not be an interface that the normal packet would ever traverse, but > who cares? You now know the node (which likely has the same FQDN for > all of its addresses in any case). You care when troubleshooting IP layer problems, which may be interface specific, and not just router specific. This will be even more important in IPv6 with greatly increased use of such features of QOS routing. > In many cases (code I've written), you don't know the interface it came > in on when it's punted to ICMP. I keep it to the IP layer (need it for > multicast routing), but not ICMP. Then you might have to tweak your implementation a little to keep information about the receive interface. > ICMP just makes a message, and then passes it to the IP layer, which > figures out the outgoing interface, and sets the Source. Anything else > complicates the code too much. I'll gladly take the tradeoff of a little more code versus improved IPv6/ICMP diagnostic capabilities. -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Mar 18 16:25:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00408; Sat, 18 Mar 95 16:25:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00402; Sat, 18 Mar 95 16:24:50 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20702; Sat, 18 Mar 1995 16:17:11 -0800 Received: from unix.ka9q.ampr.org by Sun.COM (sun-barr.Sun.COM) id AA06771; Sat, 18 Mar 95 16:17:11 PST Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.10/8.6.5) id QAA01708; Sat, 18 Mar 1995 16:14:52 -0800 Date: Sat, 18 Mar 1995 16:14:52 -0800 From: Phil Karn Message-Id: <199503190014.QAA01708@unix.ka9q.ampr.org> To: bound@zk3.dec.com Cc: Danny.Nessett@Eng, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net In-Reply-To: <9503160527.AA29567@xirtlu.zk3.dec.com> (bound@zk3.dec.com) Subject: (IPng) Re: Proposed message on perfect forward security Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >I do not think TCP vs TP[0-4] is a fair analysis to in-band vs >out-band. TCP and TPxxx are two different protocol suites, two >different AFs to a socket, and I believe two different philosophies >towards the functions of a transport layer protocol. In-band is an >option customers may want to use who do not need perfect forwarding >security. Everything else about the ip6_input layer is the same, all Ah, but I think TP[0-4] *is* an excellent analogy. The reason given for having 5 different transport protocols, all of which provided the same interface to the user, was that the "heavier" protocol (TP4) was not needed when the underlying network claimed to provide reliability. As we saw, however, the benefits of having a single, universal transport protocol providing a virtual byte stream service outweighed any concerns about performance -- many of which became moot when clever tricks like VJ header compression came along. And so I believe it will be with IP security. Once it becomes popular, people will find clever coding tricks and CPUs will get faster. But it won't become popular if there are a half dozen non-interoperable standards competing with each other. That says we should try to make the most general purpose protocol we can. Phil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Mar 19 13:36:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00600; Sun, 19 Mar 95 13:36:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00594; Sun, 19 Mar 95 13:36:01 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24014; Sun, 19 Mar 1995 13:28:23 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA23097; Sun, 19 Mar 95 13:28:18 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA17264; Mon, 20 Mar 1995 08:27:51 +1100 (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 AA14366; Mon, 20 Mar 95 07:09:57 +1000 Received: by dcthq2.datacraft.com.au; Tue, 21 Mar 95 8:26:15 +1100 Date: Tue, 21 Mar 95 8:22:19 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: Re: (IPng) ICMP limit exceeded X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I agree with bill on the traceability requirements with IP6. If check sums are not used and bad implementations or route failures cause packet/connection loss what chances does one have of finding it. Remember flow Ids, dynamic address allocation and network meshes (not trees) with load balancing will be in use. regards alan@Oz PS if this is corrupt , I apologise again. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Mar 19 14:27:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00635; Sun, 19 Mar 95 14:27:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00629; Sun, 19 Mar 95 14:27:21 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25078; Sun, 19 Mar 1995 14:19:42 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA25138; Sun, 19 Mar 95 14:19:36 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AB19052; Mon, 20 Mar 1995 09:18:58 +1100 (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 AA14547; Mon, 20 Mar 95 08:00:57 +1000 Date: Mon, 20 Mar 95 08:00:57 +1000 Message-Id: <9503192200.AA14547@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au; Mon, 20 Mar 95 9:17:18 +1100 Resent-Date: Fri, 17 Mar 95 18:07:10 +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) questions on IP6apis X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Forwarded to: internet[ipng@sunroof.eng.sun.com] cc: darren.sturre@datacraft.com.au Comments by: Alan Lloyd@Marketing@DCTHQ Comments: gentlefolk, I apologise but I believe this one went out encoded - incognito. All intellegence?! in our gateway has now been turned off (its almost in DOS mode). regards -------------------------- [Original Message] ------------------------- these may be dumb questions the API doc provides new defs to deal with address form, route defs, hop counts and flow ids. what do appls do about end to end options once they are defined. are these passed through the same api? do things like some of the new ICMP messages get passed through to the appl also. eg what if an IP4 appl gets a icmp with unrecognised "IP6 thing" cos the outbound IP(6) datagram got munched. if the appl has to set up and manage the flow id and auth header and these have to set in the routers (auth data is out band) that are in the path, does the appl also have to know the route and the versions of IP that are supported in the route? what about mesh networks, auto address assignment, alternate routes? Help! Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Mar 19 15:51:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00657; Sun, 19 Mar 95 15:51:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00651; Sun, 19 Mar 95 15:51:26 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27145; Sun, 19 Mar 1995 15:43:47 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA29233; Sun, 19 Mar 95 15:43:47 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14404(4)>; Sun, 19 Mar 1995 15:43:42 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12175>; Sun, 19 Mar 1995 15:43:38 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: (IPng) latest IPv6 spec Date: Sun, 19 Mar 1995 15:43:31 PST From: Steve Deering Message-Id: <95Mar19.154338pst.12175@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM As Bob mentioned yesterday, the latest revision of the base IPv6 spec has (finally) been submitted as an Internet Draft and also made available from . I would appreciate comments/corrections as soon as possible, in preparation for passing it to the IESG with our recommendation that it be approved as a Proposed Standard. If you can get your comments in by this Wednesday, and there aren't any showstoppers, I'd like to pass the base spec and the other WG Last Called documents to the IESG Wednesday night, for consideration at their Thursday teleconference. That would enable them to possibly issue an IETF-wide Last Call before Danvers (and would still leave you all another couple of weeks to identify problems, as part of the IETF Last Call). Regarding the base spec, probably the most significant changes from the previous version are the following: - In the previous spec, there was a 28-bit field in the base header called the "Flow Label", which was internally divided into two subfields: a 4-bit "TClass" and a 24-bit "Flow ID". Understandably, people got confused about the distinction between "Flow Labels" and "Flow IDs", so to remove that source of confusion, the spec now has just two fields (not one field with two subfields). The 4-bit TClass field has been renamed "Priority", which is a more accurate and understandable term for that field. The 24-bit field is now called the "Flow Label". The document no longer refers to "Flow IDs" (though that would be a reasonable term for people to use for the concatenation of Source Address and Flow Label, which is what uniquely identifies a flow.) Also, I removed the text that said that semantics of the Priority (formerly TClass) field could be redefined by a flow set-up protocol, so now routers that do not have state for a particular flow label are not required to ignore the Priority field for fear it may have been redefined. The above two changes impact Craig Partridge's recent flow draft. I hope he agrees that the elimination of a proven source of confusion is worth the hassle of having to update his document. Finally, on flows, I added a bunch of text talking about "opportunistic" flow state set-up and about flow-state lifetime. - As agreed in San Jose, I renamed the End-to-End Options header to be the Destination Options header, and specified that it may precede a Routing header. This allows for options that are processed by all explicitly-addressed intermediate routers, as well as the final destination. - I added ERP's Strict/Loose Bit Map field to the Routing header. However, I did not specify the various flags and the "NestL" field from ERP yet -- those bits are all reserved for now, until I can understand how ERP is supposed to work. - I deleted the place-holder section for IPv6-in-IPv6 encapsulation. It turns out there is a fair amount to say about that, so Alex Conta and I are writing a separate IPv6 tunneling spec. Regarding the concern that without an encapsulation spec, MTU discovery procedures are unclear, I would respond that one of the requirements imposed on the tunneling spec (*any* tunneling spec) is simply that it be transparent to a source node's use of MTU discovery. - I added the Jumbo Payoad hop-by-hop option, for payloads longer that 65,535 bytes. - I removed the special pseudo-header checksum rules for ICMP; it now uses the same pseudo-header as TCP and UDP. A complete list of changes is in appendix B of the new draft. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Mar 19 16:52:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00686; Sun, 19 Mar 95 16:52:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00680; Sun, 19 Mar 95 16:52:45 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28947; Sun, 19 Mar 1995 16:45:06 -0800 Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA02946; Sun, 19 Mar 95 16:45:07 PST Received: from oils.ozy.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA15658; Sun, 19 Mar 95 16:40:00 -0800 Received: by oils.ozy.dec.com (5.65/ozy-051294); id AA24427; Mon, 20 Mar 1995 10:40:21 +1000 Message-Id: <9503200040.AA24427@oils.ozy.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: latest IPv6 spec Date: Mon, 20 Mar 95 10:40:21 +1000 From: grehan@ozy.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, > - I added the Jumbo Payoad hop-by-hop option, for payloads longer > that 65,535 bytes. Should the pseudo-header checksums for jumbograms use the length modulo 2^16 ? Peter. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Mar 19 17:22:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00706; Sun, 19 Mar 95 17:22:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00700; Sun, 19 Mar 95 17:21:57 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29817; Sun, 19 Mar 1995 17:14:18 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA04654; Sun, 19 Mar 95 17:14:19 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14433(2)>; Sun, 19 Mar 1995 17:14:10 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12175>; Sun, 19 Mar 1995 17:14:02 -0800 To: grehan@ozy.dec.com Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) Re: latest IPv6 spec In-Reply-To: grehan's message of Sun, 19 Mar 95 16:40:21 -0800. <9503200040.AA24427@oils.ozy.dec.com> Date: Sun, 19 Mar 1995 17:13:49 PST From: Steve Deering Message-Id: <95Mar19.171402pst.12175@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Should the pseudo-header checksums for jumbograms use the length modulo > 2^16 ? Good question, Peter; I missed that one. I think the pseudo header for jumbograms should definitely use the full 32-bit jumbo length. I guess that'll need another illustration in section 8.1. Probably messes up your checksum routine, eh? Feel free to keep all aspects of jumbogram processing out of your "fast path" -- the only reason for using jumbograms is if the per-packet "fast path" is already extremely un-fast. BTW, UDP won't work with jumbograms -- its own length field is 16 bits wide. TCP with Big Window extension might work with jumbograms, but I haven't looked at that in detail. Anyway, I guess we have to make sure at least ICMP works with jumbograms, so since v6 ICMP uses a pseudo header, we can't just punt on the issue you raised. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Mar 19 22:54:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00776; Sun, 19 Mar 95 22:54:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00770; Sun, 19 Mar 95 22:53:53 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08535; Sun, 19 Mar 1995 22:46:12 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA25948; Sun, 19 Mar 95 22:46:13 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA09467; Sun, 19 Mar 95 22:44:48 -0800 Received: by xirtlu.zk3.dec.com; id AA21467; Mon, 20 Mar 1995 01:44:47 -0500 Message-Id: <9503200644.AA21467@xirtlu.zk3.dec.com> To: hinden@ipsilon.com Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 Addr Arch Spec Date: Mon, 20 Mar 95 01:44:41 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bob, Looks good to me. Have one question. Re: Two interfaces having the same address but presented to the upper layers as a single logical interface. In the case of DHCPv6 presently in the spec a Client passes an interface token to the Server. That interface token could have multiple IPv6 addresses assigned to the interface. So the Server could have state that looked like this: int1 ipv6_addr1 ipv6_addr2 ipv6_addr3 int2 ipv6_addr4 ipv6_addr5 ipv6_addr6 So int1 or int2 could be a logical interface for two real interfaces? In the case of stateless addr conf it gets a bit more tricky with timeouts and whatever deprecated addresses mean. Do I timeout and/or deprecate both interfaces? I think the answer to all the above is yes, the way its worded? IMHO the draft is ready for proposed standard. It was work to chase all the pointers to other specs but I found it all to add up (just a comment not complaining). thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 02:08:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00853; Mon, 20 Mar 95 02:08:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00847; Mon, 20 Mar 95 02:08:01 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15278; Mon, 20 Mar 1995 02:00:23 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA13087; Mon, 20 Mar 95 02:00:23 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-02.dialip.mich.net [141.211.7.138]) by merit.edu (8.6.10/merit-2.0) with SMTP id FAA18199 for ; Mon, 20 Mar 1995 05:00:20 -0500 Date: Mon, 20 Mar 95 08:59:38 GMT From: "William Allen Simpson" Message-Id: <4327.Bill.Simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 Addr Arch Spec Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I would like to have the drafts renamed. The -addr-arch- and the -arch-addr- are _not_ the same draft with slightly different names. In this case, -ipngwg-ipv6-addr-arch- was announced as IPng Addr Arch, which doesn't match. The IPv6 is redundant anyway. Please rename as -ipngwg-addresses- (with a title of "IPv6 Addresses"). Also, someone seems to be reposting some drafts with -ipngwg- names, without any substantive changes. This is confusing (to me). When this happens, the -nn.txt at the end should at least be the same, to help organize. I completely missed the IPv6 Addr Arch because of these two problems. Maybe I'll get to it later in the week. And it would be really really nice if the rest of you (particularly using Sun stations) would start using diffmk to insert change bars. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 03:39:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00922; Mon, 20 Mar 95 03:39:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00916; Mon, 20 Mar 95 03:38:49 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18864; Mon, 20 Mar 1995 03:31:07 -0800 Received: from bells.cs.ucl.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA22614; Mon, 20 Mar 95 03:31:04 PST Message-Id: <9503201131.AA22614@Sun.COM> Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 20 Mar 1995 11:30:30 +0000 To: Craig Partridge Cc: ipng@sunroof.Eng.Sun.COM, end2end-interest@ISI.EDU Subject: (IPng) Re: revised Flow ID management draft In-Reply-To: Your message of "Wed, 15 Mar 95 16:57:50 PST." <199503160057.QAA16758@aland.bbn.com> X-Mailer: exmh Version:Speedy 1.4 6/24/94 Date: Mon, 20 Mar 95 11:30:24 +0000 From: Zheng Wang Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Craig, Two comments about your Flow ID draft: >The notion is that by simply looking up the Flow ID in a table, the router >can decide how to route and forward the datagram without examining the rest >of the header. The Flow ID is unique only when combined with source address. Therefore, a router must look at Flow ID *and* source address to decide how to route the packet. >What does a router do with Flow ID for which it has no state? It is unclear how the state in routers is established. Is the state established with a setup message, or is it established with the first packet of the flow? If the latter is the case, the router should be able to establish the state anytime from a packet. Cheers Zheng ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 04:54:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00944; Mon, 20 Mar 95 04:54:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00938; Mon, 20 Mar 95 04:54:23 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24668; Mon, 20 Mar 1995 04:46:43 -0800 Received: from charon.siemens.be by Sun.COM (sun-barr.Sun.COM) id AA27518; Mon, 20 Mar 95 04:45:44 PST Received: by charon.siemens.be (5.65c/charon-0) id ; Mon, 20 Mar 1995 13:44:15 +0100 with SMAPD Received: from atea.atea.be(193.210.197.11) by charon via smap (V1.3mjr) id sma006604; Mon Mar 20 13:44:12 1995 Received: from atdec1.ATEA.BE by atea.atea.be with SMTP (1.37.109.4/15.6-FW) id AA07923; Mon, 20 Mar 95 07:56:15 +0100 Received: from vnet by atdec1.atea.be (5.65/Ultrix3.0-C) id AA16326; Mon, 20 Mar 1995 07:56:27 +0100 Received: by vnet.atea.be; Mon, 20 Mar 95 7:56:28 +0100 Date: Mon, 20 Mar 95 7:55:23 +0100 Message-Id: From: (Lode Coene) To: IPNG@sunroof.Eng.Sun.COM Subject: Re(IPng): remarks to addressing X-Incognito-Sn: 319 X-Incognito-Format: VERSION=1.60g ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Remarks concerning the Backlog of Alan Telephone calls take a long time to set up whereas data switching has to be instant" Telephone Setup time is dependant on the signalling system used. The slowest signalling system used during connection setup chain determines the setup time. All signalling system prior to SS7 may be considered as slow(reason: analog based) Telephone numbers have to comply to a numbering plan. until now, nearly all numbering plans have been geographical based. If somebody would need something else, then a new numbering plan may be in order. Beside the ISDN numbering plan(which I understand can be used in IP6 if you ask for NSAP addresses) other numbering plans do exist(ex ISDN/Mobile numbering plan). The logical address are called "global titles" in the signalling system nr 7, whereas the physical address are called "point codes". The US defined SS7 used some form of partitioning in the "Pointcodes" just as some of the form of the IP unicast addresses uses it. In Europe, the allocation of the Point codes is entirly left to the discretion of the network operator. The telephone users never sees this, he is only known by its telephone number which is a global title. Alan stresses that this is handled in the network which is a distribute enviroment consisting of a bunch of databases and a lot of service switches. The best example of this is a GSM network and also a IN("Intelligent" network). Do not be mislead by the term intelligent, it would be better called a "optimising" networ(ON) but I suspect that this term was already taken by someone else. Signalling is not always concerned with setting up a connection(or as is said CALL related information), it may also be non-call related information(Ex where is a certain person located at the moment(and yet noone else wants to call him)). The practise in a mobile net indicates that non-call related messages generate as much traffic as call related. For a "IN" net that is not the case. I agree with Alan that numbers should not be changed, even if you switch from one operator(service) provider to another. People simply hate this. That is a case that will become normal in the whole of Europe, esspecially as 1998 is approaching. If the IP address should be used for "everyone and his daddy" then some thought must be given to the concept of physical and logical addresses and the separation between them. A nice start seems already to be given with those NSAP addresses. If you want some more information you can read the SCCP specs Q.710 till Q.715 published by the ITU(they are concerned with message routing & global titles within a SS7 network). It's pretty boring stuff but it can give you some ideas for when you should ever decide on a next IP version. I am not sure that all Addressing ideals should need a connection-oriented approach. The combination of a connectionless network for signalling and a connection oriented network for the really very heavy stuff may be the sollution. Connectionless networks will be always needed be it for signalling transport and user transport of a lighter nature(TCP/IP connections). Alan also has a remark about address registration and it possible influence on not being able to completely specify the address format. If some things are left open to interpretation, then someone will certainly come along, exploite this gap(maybe some others also) and this leads very probable to incompatibilities in the end products. A central management(its a bad term, I would prefer a more decentralized management, everyone administrates what it knows best) has the possiblity to catch this and maybe solve them(it's certainly not guaranteed) I am always happy to respond to further questions about this mail, but please don't flood me because you did'nt like it. I `m just a simple SS7 software designer with some intrest in other networking protocols and I was triggered by the mentioning of signalling in the mail of Alan. I hope I did provide some clarrification about signalling in general. Yours sincerly Lode Coene ATEA Belgium E-mail: p82609@vnet.atea.be ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 06:17:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00999; Mon, 20 Mar 95 06:17:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00984; Mon, 20 Mar 95 06:17:48 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27892; Mon, 20 Mar 1995 06:10:08 -0800 Received: from zephyr.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA04737; Mon, 20 Mar 95 06:10:02 PST Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Mon, 20 Mar 1995 06:10:02 -0800 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199503201410.AA03530@zephyr.isi.edu> Subject: Re: (IPng) latest IPv6 spec To: ipng@sunroof.Eng.Sun.COM Date: Mon, 20 Mar 1995 06:10:01 -0800 (PST) Cc: In-Reply-To: <95Mar19.154338pst.12175@skylark.parc.xerox.com> from "Steve Deering" at Mar 19, 95 03:43:31 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM on the loopback address... shold we also allow ::127.0.0.1 -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 07:25:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01084; Mon, 20 Mar 95 07:25:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01078; Mon, 20 Mar 95 07:25:35 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01267; Mon, 20 Mar 1995 07:17:55 -0800 Received: from CLYNN.BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA12994; Mon, 20 Mar 95 07:17:56 PST Message-Id: <9503201517.AA12994@Sun.COM> Date: Mon, 20 Mar 95 10:09:36 EST From: Charles Lynn To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: Re: (IPng) latest IPv6 spec Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, - As agreed in San Jose, I renamed the End-to-End Options header to be the Destination Options header, and specified that it may precede a Routing header. This allows for options that are processed by all explicitly-addressed intermediate routers, as well as the final destination. I think it should be permitted for a packet to contain a Destination Options header before the Routing header to specify options that the routers must process AND one after it for options that are strictly End-to-End. Does the spec allow it? Charlie ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 07:42:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01104; Mon, 20 Mar 95 07:42:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01098; Mon, 20 Mar 95 07:42:28 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02269; Mon, 20 Mar 1995 07:34:47 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA15429; Mon, 20 Mar 95 07:34:48 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14424(4)>; Mon, 20 Mar 1995 07:34:35 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12175>; Mon, 20 Mar 1995 07:34:32 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: Re: (IPng) IPv6 Addr Arch Spec In-Reply-To: Bill.Simpson's message of Mon, 20 Mar 95 00:59:38 -0800. <4327.Bill.Simpson@um.cc.umich.edu> Date: Mon, 20 Mar 1995 07:34:25 PST From: Steve Deering Message-Id: <95Mar20.073432pst.12175@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: "William Allen Simpson" > > Please rename as -ipngwg-addresses- (with a title of "IPv6 Addresses"). I like this suggestion. Also, maybe we should change the file name of Yakov and Tony's address architecture draft to contain -unicast-addr-arch- or -arch-addr-unicast- to further distinguish it from the -addresses- draft. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 09:56:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01402; Mon, 20 Mar 95 09:56:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01396; Mon, 20 Mar 95 09:55:58 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16375; Mon, 20 Mar 1995 09:48:17 -0800 Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA11386; Mon, 20 Mar 95 09:48:16 PST Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA13378 for ipng@sunroof.eng.sun.com; Mon, 20 Mar 95 11:32:38 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id JAA21619; Mon, 20 Mar 1995 09:47:34 -0800 Message-Id: <199503201747.JAA21619@aland.bbn.com> To: deering@parc.xerox.com Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) latest IPv6 spec In-Reply-To: Your message of Sun, 19 Mar 95 15:43:31 -0800. <95Mar19.154338pst.12175@skylark.parc.xerox.com> From: Craig Partridge Date: Mon, 20 Mar 95 09:47:32 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The above two changes impact Craig Partridge's recent flow draft. I hope he agrees that the elimination of a proven source of confusion is worth the hassle of having to update his document. No problem. By the way, most of the comments on the current draft have been minor, so I actually have hope of wrapping it up this week. Since it is merely a set of suggestions, I plan to send it straight to the RFC editor. Craig PS: Why discard opportunistic flow state within 6 seconds? (Curious where the number came from). ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 10:05:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01463; Mon, 20 Mar 95 10:05:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00573; Sun, 19 Mar 95 10:25:26 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19848; Sun, 19 Mar 1995 10:17:47 -0800 Received: from mordor.cs.du.edu by Sun.COM (sun-barr.Sun.COM) id AA15940; Sun, 19 Mar 95 10:17:07 PST Received: from nyx10.cs.du.edu by mordor.cs.du.edu with SMTP id AA09155 (5.65c/IDA-1.4.4 for ); Sun, 19 Mar 1995 11:07:12 -0700 Received: by nyx10.cs.du.edu (4.1/SMI-4.1) id AA14904; Thu, 16 Mar 95 17:44:04 MST Date: Thu, 16 Mar 95 17:44:04 MST From: colin@nyx10.cs.du.edu (Colin Plumb) Message-Id: <9503170044.AA14904@nyx10.cs.du.edu> X-Disclaimer: Nyx is a public access Unix system run by the University of Denver. The University has neither control over nor responsibility for the opinions or correct identity of users. To: evi@piper.cs.colorado.edu Subject: (IPng) Re: True internationalisation Cc: Bill.Simpson@um.cc.umich.edu, hallc@piper.cs.colorado.edu, ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill Simpson wrote the following: > Last year, Phil Karn (with a little help from his freinds) took up the > export matter of the _book_ "Applied Cryptography" [Schneier 94]. It > was denied. For us, this is a serious Constitutional violation. The book was approved. The floppy containing the software printed in the back of the book was denied. More info is available from ftp.epic.org and ftp.eff.org. > BTW, do you use PGP? Phil Zimmerman is actually on _trial_ now for a > possible 10 year sentence and $1,000,000 fine. This is not true. He hasn't (after 1.5 years of investigation) been *indicted* (i.e. charged) yet, let alone brought to trial. The mandatory sentencing guidelines (i.e. if found guilty, a judge must give at least this) are 41 to 51 months. A lot, but under 10 years, and nobody imagines he'd get more than the minimum. I don't know about fines. You can verify this by calling Philip himself - his phone number is widely published with PGP. Just remember that he isn't going to tell J Random Schmuck who calls him up the details of his defense preparations, so it's impolite to pry into those matters. Sorry to land on you, but *please* check your facts more carefully. -- -Colin ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 10:21:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01528; Mon, 20 Mar 95 10:21:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00808; Mon, 20 Mar 95 00:23:44 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12083; Mon, 20 Mar 1995 00:16:04 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA05962; Mon, 20 Mar 95 00:16:04 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-17.dialip.mich.net [141.211.7.153]) by merit.edu (8.6.10/merit-2.0) with SMTP id DAA14627 for ; Mon, 20 Mar 1995 03:16:01 -0500 Date: Sun, 19 Mar 95 21:31:53 GMT From: "William Allen Simpson" Message-Id: <4322.Bill.Simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: True internationalisation Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: colin@nyx10.cs.du.edu (Colin Plumb) > Bill Simpson wrote the following: > > Last year, Phil Karn (with a little help from his freinds) took up the > > export matter of the _book_ "Applied Cryptography" [Schneier 94]. It > > was denied. For us, this is a serious Constitutional violation. > > The book was approved. The floppy containing the software printed in the back > of the book was denied. More info is available from ftp.epic.org > and ftp.eff.org. > Perhaps you could read more thoroughly when you are so far behind on your email. The next sentence said: # Then, the lawyers got involved (thanks to EFF, send your contributions), # and the appeal was granted. The floppy information (a separate export application) was detailed in the following paragraph, which I will not recapitulate here. > > BTW, do you use PGP? Phil Zimmerman is actually on _trial_ now for a > > possible 10 year sentence and $1,000,000 fine. > > This is not true. He hasn't (after 1.5 years of investigation) been > *indicted* (i.e. charged) yet, let alone brought to trial. Thank you for being the second or third person to tell us this. I'm sorry that the article in Dr Dobbs Developer Update was wrong, and apologize on their behalf. I'm merely a PGP user, and rely on accurate reporting by the press. I wouldn't think of calling Zimmerman for regular updates. I expect him to make better use of his time getting 3.0 out the door. As to the difference between needing lawyers for an indictment and needing lawyers for a trial, that was my faulty verbiage. Some of us think of them as the same thing. Once upon a time they were. Mea Culpa. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 10:23:18 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01540; Mon, 20 Mar 95 10:23:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01057; Mon, 20 Mar 95 06:36:26 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28713; Mon, 20 Mar 1995 06:28:46 -0800 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA06996; Mon, 20 Mar 95 06:28:47 PST Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA00924; Mon, 20 Mar 95 09:27:07 EST Received: from eddie.wellfleet by wellfleet (4.1/SMI-4.1) id AA06238; Mon, 20 Mar 95 09:32:00 EST Date: Mon, 20 Mar 95 09:32:00 EST From: mdavis@wellfleet.com (Mike Davis) Message-Id: <9503201432.AA06238@wellfleet> Received: by eddie.wellfleet (4.1/SMI-4.1) id AA24979; Mon, 20 Mar 95 09:28:33 EST To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <4327.Bill.Simpson@um.cc.umich.edu> Subject: Re: (IPng) IPv6 Addr Arch Spec Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >>>>> "Bill" == William Allen Simpson writes: . . . Bill> When this happens, the -nn.txt at the end should at least be Bill> the same, to help organize. I strongly second this notion. I made some silly comments at San Jose in part because I had there were two versions of the same draft, the later one with the a different name but the version number reset to -00. A scheme that keeps the version numbers for the same draft monotonically increasing regardless of the title. (I agree that it was my own fault for having the wrong version in San Jose, but anything that makes it easier to be right is a good thing, IMO.) Bill> Bill.Simpson@um.cc.umich.edu -mad signoff Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 10:54:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01576; Mon, 20 Mar 95 10:54:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01570; Mon, 20 Mar 95 10:54:05 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24190; Mon, 20 Mar 1995 10:46:23 -0800 Received: from nic1.barrnet.net by Sun.COM (sun-barr.Sun.COM) id AA22054; Mon, 20 Mar 95 10:42:47 PST Received: from mdv.com by nic1.barrnet.net (8.6.10/BARRNET-RELAY.1) id KAA12550; Mon, 20 Mar 1995 10:41:32 -0800 Received: from [204.160.240.224] by mdv.com (4.1/SMI-4.1MDV1.0) id AA25303; Mon, 20 Mar 95 10:42:15 PST X-Sender: hinden@servo.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Mar 1995 10:39:40 -0800 To: ipng@sunroof.Eng.Sun.COM From: hinden@ipsilon.com (Bob Hinden) Subject: Re: (IPng) IPv6 Addr Arch Spec Cc: deering@parc.xerox.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 7:34 AM 3/20/95, Steve Deering wrote: >> From: "William Allen Simpson" >> >> Please rename as -ipngwg-addresses- (with a title of "IPv6 Addresses"). > >I like this suggestion. Also, maybe we should change the file name of >Yakov and Tony's address architecture draft to contain -unicast-addr-arch- >or -arch-addr-unicast- to further distinguish it from the -addresses- draft. I too agree. I will talk to CNRI and have them change the file names to something consistent and clear. The result will be announced to the list. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 11:48:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01763; Mon, 20 Mar 95 11:48:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01757; Mon, 20 Mar 95 11:48:28 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00798; Mon, 20 Mar 1995 11:40:47 -0800 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA02723; Mon, 20 Mar 95 11:40:41 PST Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA08853; Mon, 20 Mar 95 14:26:41 EST Received: from cabernet.wellfleet by wellfleet (4.1/SMI-4.1) id AA16531; Mon, 20 Mar 95 14:31:29 EST Date: Mon, 20 Mar 95 14:31:29 EST From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9503201931.AA16531@wellfleet> To: ipng@sunroof.Eng.Sun.COM, karn@unix.ka9q.ampr.org Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: ipsec@ans.net Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >I do not think TCP vs TP[0-4] is a fair analysis to in-band vs > >out-band. TCP and TPxxx are two different protocol suites, two > >different AFs to a socket, and I believe two different philosophies > >towards the functions of a transport layer protocol. In-band is an > >option customers may want to use who do not need perfect forwarding > >security. Everything else about the ip6_input layer is the same, all > > Ah, but I think TP[0-4] *is* an excellent analogy. The reason given > for having 5 different transport protocols, all of which provided the > same interface to the user, was that the "heavier" protocol (TP4) was > not needed when the underlying network claimed to provide reliability. > As we saw, however, the benefits of having a single, universal transport > protocol providing a virtual byte stream service outweighed any > concerns about performance -- many of which became moot when clever > tricks like VJ header compression came along. I also agree that this is at least a partly reasonable analogy. Some of us who were working on CLNP/TP4 etc at the time figured that TP4 was obviously necessary (for the same reasons as TCP over IP), and that the market would figure this out. What happened instead was that having five transport layer standards and at least two network layer standards helped to confuse potential users, which added still more delay and confusion to potential use of OSI. Now, the analogy probably partly fails in that network and transport layer problems were NOT what stopped OSI (at least in my opinion). I think that OSI suffered more from application complexity, particular complexity as seen by the user (eg, ugly Email names), and other problems independent of the network and transport layers. However, if OSI had said "TP4 and CLNP are our transport and network layer standards" then this would have made it simpler for folks who thought that they needed to deploy OSI to actually start doing so. > And so I believe it will be with IP security. Once it becomes popular, > people will find clever coding tricks and CPUs will get faster. But it > won't become popular if there are a half dozen non-interoperable > standards competing with each other. That says we should try to make > the most general purpose protocol we can. > > Phil Also, if encryption is really *necessary* for security in the Internet to work, and if simultaneous security and performance in the Internet is necessary for the global information super- highway to have a several orders of magnitude increase in its commercial value, then encryption may need to be in hardware. Clearly hardware can be cheaper if there are fewer standards to implement (although patents and laws may also throw a monkey wrench in the works). Ross ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 12:41:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01958; Mon, 20 Mar 95 12:41:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00430; Sat, 18 Mar 95 20:48:28 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28168; Sat, 18 Mar 1995 20:40:50 -0800 Received: from gw.steam.com by Sun.COM (sun-barr.Sun.COM) id AA17472; Sat, 18 Mar 95 20:40:47 PST Received: from [140.174.164.132] (annex-p132.meer.net [140.174.164.132]) by gw.steam.com (8.6.10/8.6.9) with SMTP id UAA02958; Sat, 18 Mar 1995 20:38:32 -0800 X-Sender: rmh@gw.steam.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 18 Mar 1995 20:49:17 -0800 To: ipng@sunroof.Eng.Sun.COM From: rmh@alderaan.com (Bob Hinden) Subject: (IPng) New IPng Protocol Spec Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM A new IPng Protocol specification has been submitted to the Internet Drafts directory. It should appear in a few days. In the mean time it can be anonymously ftp'ed from parcftp.xerox.com in the pub/ipng directory. The file name is: draft-ietf-ipngwg-ipv6-spec-01.txt This constitutes the IPng working group last call for this document. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 12:46:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01986; Mon, 20 Mar 95 12:46:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01980; Mon, 20 Mar 95 12:46:23 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09036; Mon, 20 Mar 1995 12:38:41 -0800 Received: from CLYNN.BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA17172; Mon, 20 Mar 95 12:38:38 PST Message-Id: <9503202038.AA17172@Sun.COM> Date: Mon, 20 Mar 95 15:35:09 EST From: Charles Lynn To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM, end2end-interest@isi.edu, Craig Partridge Subject: Re: (IPng) revised Flow ID management draft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Craig, I do not think that either: The notion is that by simply looking up the Flow ID in a table, the router can decide how to route and forward the datagram without examining the rest of the header. nor draft-hinden-ipng-ipv6-spec-00.txt is an adequate description of the model. The issue is what does "forward the datagram without examining the rest of the header" mean. In the context of the routing issues, I think it has to mean more than just caching outgoing interface and next hop. Consider a packet sent from source S to destination D with a Routing Header that specifies R1, R2, and R3 as intermediate hops (either routers or pack addresses -- say routers for this example), flow label F, and no flow state for F in the routers. +---+ _ +----+ _ +----+ _ +----+ _ +---+ | S |o -<_>- i| R1 |o -<_>- i| R2 |o -<_>- i| R3 |o -<_>- i| D | +---+ +----+ +----+ +----+ +---+ R1 will receive the packet on interface R1.i that has the Rouging Header pointing at R1, have no state for F, perform the routing function that advances the pointer to R2, selects the next hop toward R2, say X1, and the outgoing interface R1.o, creates flow state for F, and forwards the packet. R2 and R3 perform similar operations. Now the second packet comes along; flow state for F exists in R1, R2, and R3. What happens to the Routing Header pointer? If the routing portion of the flow state just forwards the packet to X1 out interface R1.o, then the routing header pointer will not be updated. The route loops, etc. that will most likely result should be "obvious". So it would seem that the effects of the full Routing Header processing are required even in the presence of a Flow Label: either remembering to bump the pointer as part of F's flow state, or actually reperforming the complete processing associated with the Header. I think the text should be clarified to increase the chances of getting multiple interoperable implementations. Charlie ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 14:14:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02079; Mon, 20 Mar 95 14:14:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02073; Mon, 20 Mar 95 14:14:01 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20811; Mon, 20 Mar 1995 14:06:18 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA08674; Mon, 20 Mar 95 14:06:17 PST Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA07658; Mon, 20 Mar 1995 17:06:12 -0500 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65 EXP 2/22/95 for V3.2/1.1.8.2/18Feb95-1123AM) id AA27486; Mon, 20 Mar 1995 17:06:11 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA17886; Mon, 20 Mar 1995 16:42:03 -0500 Message-Id: <9503202142.AA17886@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) New IPng Protocol Spec In-Reply-To: Your message of "Sat, 18 Mar 95 20:49:17 PST." Date: Mon, 20 Mar 95 16:42:03 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: rmh@alderaan.com (Bob Hinden) Subject: (IPng) New IPng Protocol Spec A new IPng Protocol specification has been submitted to the Internet Drafts directory. It should appear in a few days. In the mean time it can be anonymously ftp'ed from parcftp.xerox.com in the pub/ipng directory. The file name is: draft-ietf-ipngwg-ipv6-spec-01.txt This constitutes the IPng working group last call for this document. Bob Bob, I have the following comments (a. and c. are suggestions). a. In section "2.5 Region Addresses", please add examples of the format of 'region addresses' as the document does for "Unicast" and "Multicast" addresses. This would make easier deriving the 'region address' from a 'unicast address', or a 'unicast address' from a 'region address' - for instance paragraph #4, at page 12 does not make too clear IMO: "The Region-ID is an address out of the subnet". b. In section "2.4.7 IPv6 Addresses with Embedded IPv4 Addresses", I salute the linking of the "IPv4-compatible IPv6 address" only with one IPv4 to IPv6 transition mechanism, i.e. "IPv4 tunneling of IPv6 packets". This removes some of the complexitiy and over-load of this particular address. c. For implementing another IPv4 to IPv6 transition mechanism - "translation" - a new "IPv4-mapped" address with an embedded IPv4 address could/should be reserved/specified, and used in lieu of the "IPv4-compatible IPv6 address". Adding a new address with very precise role in translation, would help with simplifying the translation mechanism specification and implementation. For instance tha address could be: 0:0:0:0:ffff:0:'ipv4 address', or any other combination that would result in the same checksum field value with 'ipv4 address'. This address could/would represent "IPv6 only nodes" that communicate with "IPv4 only nodes", and would pair with the current "IPv4-mapped IPv6 address" in implementing IPv6 to IPv4, and IPv4 to IPv6 translation mechanisms. The two addresses could be named: "IPv6 only node IPv4-mapped IPv6 address" "IPv4 only node IPv4-mapped IPv6 address". and used to represent: "IPv6 only nodes communicating with IPv4 only nodes" respectively "IPv4 only nodes communicating with IPv6 only nodes". For illustration of how the two addresses could/would be used: An IPv6 header's src and dst "en route" from an IPv6 only node to an IPv4 only node would look on an IPv6 network like: src: 0:0:0:ffff:0:a.b.c.d IPv6 only node IPv4-mapped IPv6 address dst: 0:0:0:0:ffff:e.f.g.h IPv4 only node IPv4-mapped IPv6 address A translator of IP6 packets to IPv4 packets would receive and accept only this type of 'src' and 'dst' combination in IPv6 headers to be translated to IPv4 headers. An IPv6 header's src and dst "en route" from an IPv4 only node to an IPv6 only node would look on an IPv6 network: src: 0:0:0:0:ffff:e.f.g.h IPv4 only node IPv4-mapped IPv6 address dst: 0:0:0:ffff:0:a.b.c.d IPv6 only node IPv4-mapped IPv6 address A translator of IPv4 packets to IPv6 packets would transmit only this type of 'src' and 'dst' combination in IPv6 headers that were translated from IPv4 headers. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 15:19:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02162; Mon, 20 Mar 95 15:19:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02156; Mon, 20 Mar 95 15:18:54 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29474; Mon, 20 Mar 1995 15:11:10 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA22502; Mon, 20 Mar 95 15:11:01 PST Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA10151; Mon, 20 Mar 1995 18:10:57 -0500 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65 EXP 2/22/95 for V3.2/1.1.8.2/18Feb95-1123AM) id AA31844; Mon, 20 Mar 1995 18:10:55 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA18010; Mon, 20 Mar 1995 17:46:42 -0500 Message-Id: <9503202246.AA18010@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com, bound@zk3.dec.com, set@thumper.bellcore.com, bob.gilligan@Eng Subject: (IPng) a few IPv6 API document related comments: Date: Mon, 20 Mar 95 17:46:42 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Here are a few comments on the IPv6 API draft: 1. On page 6 - 4.3. The Socket Functions - system calls that handle IPv6 addresses do not mention 'sndmsg' and 'rcvmsg'. I made this comment several months ago. Is 'sndmsg' and 'rsvmsg' omitting intentional?. 2. On page 9 - 4.7 , the "IPv4-mapped IPv6 address" value changed - new "addressing" architecture document. 3. On page 17 - 4.13, Name-to-Address Translation Functions. To provide more flexibility for writting applications that could use both IPv6 and IPv4 addresses, it would be usefull to extend the role of the second argument of the 'host2nameaddr' call from that of an 'input parameter' to that of an 'input/output parameter'. The two cases when 'af=AF_INET' and 'af=AF_INET6' will continue to mean that 'af' is an input parameter. The third case, when 'af' is specified but it contains a value 'zero' would mean that 'af' is also an 'output parameter' to be returned an AF_INET or AF_INET6 value. The text to be added after the two paragraphs that document the case 'af=AF_INET', and 'af=AF_INET6' would be the following: " If the 'af' argument contains a value 'zero' - any address family - the 'af' parameter is filled by the 'hostname2addr' call as it follows: 'hostname2addar' queries the name service: - for IPv6 addresses, and if any are found, returns a 'hostent' structure that includes an array of IPv6 addresses and fill in the 'h_addrtype' field in the 'hostent' structure, and the 'af' parameter with the AF_INET6 value. - for IPv4 addresses, and if any are found, returns a 'hostent' structure that includes an array of IPv4 addresses and fill in the 'h_addrtype' field in the 'hostent' structure, and the 'af' parameter, with the AF_INET value. The returned value in 'af' could be used to (derive and) specify the protocol family and address family for further 'socket' calls. Alex Conta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 17:02:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02311; Mon, 20 Mar 95 17:02:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02305; Mon, 20 Mar 95 17:02:18 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14787; Mon, 20 Mar 1995 16:54:36 -0800 Received: from nic1.barrnet.net by Sun.COM (sun-barr.Sun.COM) id AA15258; Mon, 20 Mar 95 16:54:36 PST Received: from ipsilon.com by nic1.barrnet.net (8.6.10/BARRNET-RELAY.1) id QAA19707; Mon, 20 Mar 1995 16:54:34 -0800 Received: from [204.160.240.224] (acacia.ipsilon.COM) by ipsilon.com (4.1/SMI-4.1MDV1.0) id AA01263; Mon, 20 Mar 95 16:53:08 PST X-Sender: hinden@servo.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Mar 1995 16:52:42 -0800 To: ipng@sunroof.Eng.Sun.COM From: hinden@ipsilon.com (Bob Hinden) Subject: (IPng) New IPv6 DNS Draft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM A new draft of the IPv6 DNS specification has been submitted to become an Internet Draft. It should be available in a few days. In the mean time it is available for anonymous FTP from thumper.bellcore.com in /pub/set/ipv6DNS.txt This constitutes the IPng working group last call for this document. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 20:08:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02388; Mon, 20 Mar 95 20:08:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02382; Mon, 20 Mar 95 20:07:53 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29826; Mon, 20 Mar 1995 20:00:11 -0800 Received: from mail1.digital.com by Sun.COM (sun-barr.Sun.COM) id AA12355; Mon, 20 Mar 95 20:00:13 PST Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 2/22/95 for V3.2/1.0/WV) id AA30358; Mon, 20 Mar 1995 19:47:22 -0800 Received: by xirtlu.zk3.dec.com; id AA08006; Mon, 20 Mar 1995 22:46:11 -0500 Message-Id: <9503210346.AA08006@xirtlu.zk3.dec.com> To: conta@brigit.zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com, set@thumper.bellcore.com, bob.gilligan@Eng Subject: Re: (IPng) a few IPv6 API document related comments: In-Reply-To: Your message of "Mon, 20 Mar 95 17:46:42 EST." <9503202246.AA18010@brigit.zk3.dec.com> Date: Mon, 20 Mar 95 22:46:06 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Date: Mon, 20 Mar 95 17:46:42 -0500 >From: conta@brigit.zk3.dec.com >1. On page 6 - 4.3. The Socket Functions - system calls that handle IPv6 >addresses do not mention 'sndmsg' and 'rcvmsg'. >I made this comment several months ago. Is 'sndmsg' and 'rsvmsg' omitting >intentional?. No. It should have been in here. It was an oversight. >2. On page 9 - 4.7 , the "IPv4-mapped IPv6 address" value changed - new >"addressing" architecture document. Its :FFFF:d.d.d.d as in the new "addressing architecture doc? >3. On page 17 - 4.13, Name-to-Address Translation Functions. >To provide more flexibility for writting applications that could use both >IPv6 and IPv4 addresses, it would be usefull to extend the role of the >second argument of the 'host2nameaddr' call from that of an 'input parameter' >to that of an 'input/output parameter'. >The two cases when 'af=AF_INET' and 'af=AF_INET6' will continue to mean that >'af' is an input parameter. The third case, when 'af' is specified but >it contains a value 'zero' would mean that 'af' is also an 'output parameter' >to be returned an AF_INET or AF_INET6 value. >The text to be added after the two paragraphs that document the case >'af=AF_INET', and 'af=AF_INET6' would be the following: " >If the 'af' argument contains a value 'zero' - any address family - the 'af' >parameter is filled by the 'hostname2addr' call as it follows: >'hostname2addar' queries the name service: >- for IPv6 addresses, and if any are found, returns a 'hostent' structure >that includes an array of IPv6 addresses and fill in the 'h_addrtype' field >in the 'hostent' structure, and the 'af' parameter with the AF_INET6 value. >- for IPv4 addresses, and if any are found, returns a 'hostent' structure that >includes an array of IPv4 addresses and fill in the 'h_addrtype' field >in the 'hostent' structure, and the 'af' parameter, with the AF_INET value. >The returned value in 'af' could be used to (derive and) specify the >protocol family and address family for further 'socket' calls. We discussed this at length. We concluded with is_ipv4_addr function. One idea presented was to pass a socket structure to is_ipv4_addr and have it filled out upon return, which would be more powerful than any solution so far. You can do what you ask via is_ipv4_addr. Or do you not think so? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 20:52:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02409; Mon, 20 Mar 95 20:52:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02403; Mon, 20 Mar 95 20:52:06 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01870; Mon, 20 Mar 1995 20:44:24 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA15953; Mon, 20 Mar 95 20:44:05 PST Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA25146; Mon, 20 Mar 1995 23:44:01 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA07087; Mon, 20 Mar 1995 23:43:57 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA14970; Mon, 20 Mar 1995 23:19:44 -0500 Message-Id: <9503210419.AA14970@brigit.zk3.dec.com> To: bound@zk3.dec.com Cc: conta@zk3.dec.com, ipng@sunroof.Eng.Sun.COM, set@thumper.bellcore.com, bob.gilligan@Eng Subject: Re: (IPng) a few IPv6 API document related comments: In-Reply-To: Your message of "Mon, 20 Mar 95 22:46:06 EST." <9503210346.AA08006@xirtlu.zk3.dec.com> Date: Mon, 20 Mar 95 23:19:44 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Return-Path: bound In-Reply-To: Your message of "Mon, 20 Mar 95 17:46:42 EST." <9503202246.AA18010@brigit.zk3.dec.com> X-Mts: smtp >Date: Mon, 20 Mar 95 17:46:42 -0500 >From: conta@brigit.zk3.dec.com >1. On page 6 - 4.3. The Socket Functions - system calls that handle IPv6 >addresses do not mention 'sndmsg' and 'rcvmsg'. >I made this comment several months ago. Is 'sndmsg' and 'rsvmsg' omitting >intentional?. No. It should have been in here. It was an oversight. OK. >2. On page 9 - 4.7 , the "IPv4-mapped IPv6 address" value changed - new >"addressing" architecture document. Its :FFFF:d.d.d.d as in the new "addressing architecture doc? You're right. >3. On page 17 - 4.13, Name-to-Address Translation Functions. >To provide more flexibility for writting applications that could use both >IPv6 and IPv4 addresses, it would be usefull to extend the role of the >second argument of the 'host2nameaddr' call from that of an 'input parameter ***' >to that of an 'input/output parameter'. >The two cases when 'af=AF_INET' and 'af=AF_INET6' will continue to mean that >'af' is an input parameter. The third case, when 'af' is specified but >it contains a value 'zero' would mean that 'af' is also an 'output parameter' >to be returned an AF_INET or AF_INET6 value. >The text to be added after the two paragraphs that document the case >'af=AF_INET', and 'af=AF_INET6' would be the following: " >If the 'af' argument contains a value 'zero' - any address family - the 'af' >parameter is filled by the 'hostname2addr' call as it follows: >'hostname2addar' queries the name service: >- for IPv6 addresses, and if any are found, returns a 'hostent' structure >that includes an array of IPv6 addresses and fill in the 'h_addrtype' field >in the 'hostent' structure, and the 'af' parameter with the AF_INET6 value. >- for IPv4 addresses, and if any are found, returns a 'hostent' structure th ***at >includes an array of IPv4 addresses and fill in the 'h_addrtype' field >in the 'hostent' structure, and the 'af' parameter, with the AF_INET value. >The returned value in 'af' could be used to (derive and) specify the >protocol family and address family for further 'socket' calls. We discussed this at length. We concluded with is_ipv4_addr function. I am not sure who are 'we'. Do you mean you and me, or you, Sue, and Bob? I have in mind porting an application from IPv4 to dual IPv6 and IPv4. I would like to replace 'gethostbyname' with 'hostname2addr', and use the addresses and address family returned to issue subsequent socket calls without any additional calls, or conversions. The proposed addition will do just that. This is more simple and requires less from the programmer. Using 'is_ipv4_addr' as documented, is one more step, and it requires additionally some more steps, which altough are not difficult to do for one who knows the details, are still demanding knowledge from a programmer, and is also less elegant. One idea presented was to pass a socket structure to is_ipv4_addr and have it filled out upon return, which would be more powerful than any solution so far. /jim I am not sure I follow, so the 'is_ipv4_addr' would fill out the 'socket' structure based on a 'socket' structure and 'in_addr6' structure passed as input arguments? Would the 'is_ipv4_addr' be still part of the 'Name-to-Address Translation Functions' ? Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 20 22:15:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02436; Mon, 20 Mar 95 22:15:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02430; Mon, 20 Mar 95 22:14:58 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04458; Mon, 20 Mar 1995 22:07:15 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA21890; Mon, 20 Mar 95 22:07:18 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14424(4)>; Mon, 20 Mar 1995 22:05:40 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12175>; Mon, 20 Mar 1995 22:05:29 -0800 To: Charles Lynn Cc: ipng@sunroof.Eng.Sun.COM, end2end-interest@isi.edu, Craig Partridge , deering@parc.xerox.com Subject: Re: (IPng) revised Flow ID management draft In-Reply-To: clynn's message of Mon, 20 Mar 95 12:35:09 -0800. <9503202038.AA17172@Sun.COM> Date: Mon, 20 Mar 1995 22:05:22 PST From: Steve Deering Message-Id: <95Mar20.220529pst.12175@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I do not think that either: > > The > notion is that by simply looking up the Flow ID in a table, the > router can decide how to route and forward the datagram without > examining the rest of the header. > > nor draft-hinden-ipng-ipv6-spec-00.txt is an adequate description of > the model. The issue is what does "forward the datagram without > examining the rest of the header" mean. In the context of the routing > issues, I think it has to mean more than just caching outgoing > interface and next hop. ... Charlie, The most recent IPv6 spec says the following, which recognizes the issue you raise: Routers are free to "opportunistically" set up flow-handling state for any flow, even when no explicit flow establishment information has been provided to them via a control protocol, a hop-by-hop option, or other means. For example, upon receiving a packet from a particular source with an unknown, non-zero flow label, a router may process its IPv6 header and any necessary extension headers as if the flow label were zero. That processing would include determining the next-hop interface, and possibly other actions, such as updating a hop-by-hop option, advancing the pointer and addresses in a Routing header, or deciding on how to queue the packet based on its Priority field. The router may then choose to "remember" the results of those processing steps and cache that information, using the source address plus the flow label as the cache key. Subsequent packets with the same source address and flow label may then be handled by referring to the cached information rather than examining all those fields that, according to the requirements of the previous paragraph, can be assumed unchanged from the first packet seen in the flow. Does that assuage your concerns? This is all uncharted territory, so I wouldn't be surprised to find all sorts of hazards still lurking here. It may turn out that the only safe or practical thing to do is to cache flow state for only those packets that have no Routing header and no changeable-en-route options. I await implementation and testing reports. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 01:32:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02492; Tue, 21 Mar 95 01:32:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02485; Tue, 21 Mar 95 01:32:13 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13005; Tue, 21 Mar 1995 01:24:33 -0800 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA09038; Tue, 21 Mar 95 01:24:30 PST Received: by mitsou.inria.fr (8.6.10/8.6.10) id KAA13087; Tue, 21 Mar 1995 10:24:09 +0100 Message-Id: <199503210924.KAA13087@mitsou.inria.fr> To: Craig Partridge Cc: ipng@sunroof.Eng.Sun.COM, end2end-interest@isi.edu Subject: Re: (IPng) revised Flow ID management draft In-Reply-To: Your message of "Fri, 17 Mar 1995 08:13:27 PST." <199503171613.IAA18527@aland.bbn.com> Date: Tue, 21 Mar 1995 10:24:08 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM => 1. What should a router do if a datagram with a (non-zero) => Flow ID arrives and the router has no state for that Flow ID? => => * Route the datagram as if the flow-id was null is indeed the solution, => but I don't see why one should ignore the "traffic class" field. => => Because IPv6 allows the flow to redefine the meaning of the traffic class => field. Thus we must ignore it if the flow id is set (on the grounds we => might otherwise harmfully misunderstand it). Well, what about the drop priorities options then? Would you want to restrict them to flows which have been explicitly set? What if I decide to do fair queuing in my routers through a hierarchy of classes ending with source address and flow number? Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 01:38:49 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02508; Tue, 21 Mar 95 01:38:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02502; Tue, 21 Mar 95 01:38:42 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13243; Tue, 21 Mar 1995 01:31:02 -0800 Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA09538; Tue, 21 Mar 95 01:31:01 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA20639; Tue, 21 Mar 95 01:26:50 -0800 Received: by xirtlu.zk3.dec.com; id AA16661; Tue, 21 Mar 1995 04:26:41 -0500 Message-Id: <9503210926.AA16661@xirtlu.zk3.dec.com> To: conta@brigit.zk3.dec.com Cc: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM, set@thumper.bellcore.com, bob.gilligan@Eng Subject: Re: (IPng) a few IPv6 API document related comments: In-Reply-To: Your message of "Mon, 20 Mar 95 23:19:44 EST." <9503210419.AA14970@brigit.zk3.dec.com> Date: Tue, 21 Mar 95 04:26:35 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In-Reply-To: Your message of "Mon, 20 Mar 95 22:46:06 EST." <9503210346.AA08006@xirtlu.zk3.dec.com> From: conta@brigit.zk3.dec.com >>We discussed this at length. We concluded with is_ipv4_addr function. >I am not sure who are 'we'. Do you mean you and me, or you, Sue, and Bob? The coauthors. >I have in mind porting an application from IPv4 to dual IPv6 and IPv4. >I would like to replace 'gethostbyname' with 'hostname2addr', and use the >addresses and address family returned to issue subsequent socket calls >without any additional calls, or conversions. The proposed addition will do >just that. This is more simple and requires less from the programmer. >Using 'is_ipv4_addr' as documented, is one more step, and it requires >additionally some more steps, which altough are not difficult to do for one >who knows the details, are still demanding knowledge from a programmer, and >is also less elegant. First we are going to head down a transition discussion and I don't want to get into that one right now, and we may want to take this discussion to ngtrans list. And then come back to the API issue of porting an application from IPv4 to dual IPv6 and IPv4. It would be hard to not get into more depth on the merits of either approach for this purpose without bringing out ones assumptions about how the 'port' can be accomplished. This discussion must happen, but I prefer not here and later? OK? I don't think is_ipv4_addr is many more steps, but elgance may be in the eyes of the beholder? Applications today do not rely on knowledge from the AF paramter of gethostbyname() to determine what socket PF to open. Typically (and in all cases I am aware of) gethostbyname() is done after s=socket(....). Using is_ipv4_addr provides all the uses of the AF in/out approach as a boolean test and the socket family can be selected: if is_ipv4_addr(* ap) then if doing_ipv4_only_stack then /* ipv4 mapped to be ipv4 only */ socket (PF_INET, type, protocol) /* later the low order bits of the ipv4 mapped address will need to be located */ else socket (PF_INET6, type, protocol) /* in this case the address is passed to the socket layer as ipv4 mapped, ipv4 compatible, or ipv6 only. Using the AF approach its a case statement: switch AF_RETURNED (whatever) AF_INET do socket open PF_INET AF_INET6 do socket open PF_INET6 With is_ipv4_addr you have to specifically test for an ipv4 mapped and then parse an ipv4 only address from the returned IPv6 address per hostname2addr(). Where as with the AF in/out approach the ipv4 only address would be there per the out parameter. But in the AF in/out case presented you only receive an AF_INET or AF_INET6 parameter which does not tell one of the cases above that you have an ipv4 mapped address so with the AF approach another condition has to be tested anyway if your interested in knowing you have an ipv4 mapped address in an application. This is where one can head down the transition assumption or options discussion I want to avoid now. The other advantage of is_ipv4_addr is that it can be used to test a peer address from accept or recvfrom to determine if you have recieved and address from an ipv4 only node. So it serves multiple purposes and functions in addition to providing applications the ability to determine socket connection PFs. This IMHO creates elegance when a function can be overloaded in such a manner to solve multiple programming tasks as is_ipv4_addr does in the API spec. As far as programmer knowledge IMHO if the programmer can use hostname2addr and understand its purpose and the hostent structure returned then they are capable of understanding is_ipv4_addr and also will have another tool to use elsewhere in their network programming tasks for accept or recvfrom. It can also be used as a library routine in the kernel for the transport layer depending on how one wants to build the transport layer for IPv6 and the socket layer too, when the address is passed to those layers. is_ipv4_addr is a very versatile function for IPv6. >> One idea presented was to pass a socket structure to is_ipv4_addr and >> have it filled out upon return, which would be more powerful than any >> solution so far. >I am not sure I follow, so the 'is_ipv4_addr' would fill out the 'socket' >structure based on a 'socket' structure and 'in_addr6' structure passed as >input arguments? Would the 'is_ipv4_addr' be still part of the >'Name-to-Address Translation Functions' ? It would be: is_ipv4_addr(struct sockaddr *) It would return TRUE for AF_INET address and for AF_INET6 addresses that are not ipv4 mapped. This permits the function to also receive a family/type field which could be useful too. It basically extends the use of is_ipv4_addr to also take as input to its return family/type parameters too, that could be useful in the future. It just extends the use of is_ipv4_addr. It also may eliminate any transition discussions because of its flexibiltiy to handle all cases. Hence, it can be used to accomplish the variants that users will require to transition from IPv4 to IPv6. It makes the tool more efficient IMHO. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 01:39:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02520; Tue, 21 Mar 95 01:39:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02514; Tue, 21 Mar 95 01:39:04 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13273; Tue, 21 Mar 1995 01:31:24 -0800 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA09558; Tue, 21 Mar 95 01:31:14 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) a few IPv6 API document related comments: To: ipng@sunroof.Eng.Sun.COM Date: Tue, 21 Mar 1995 09:34:11 +0000 (GMT) In-Reply-To: <9503202246.AA18010@brigit.zk3.dec.com> from "conta@zk3.dec.com" at Mar 20, 95 05:46:42 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > 1. On page 6 - 4.3. The Socket Functions - system calls that handle IPv6 > addresses do not mention 'sndmsg' and 'rcvmsg'. This seems sensible. Many non BSD and especially non unix stacks regard sendmsg()/recvmsg() as too esoteric to be worth code space. It had minimal arguable value for OSI, and the unix file descriptor passing hack but its not needed. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 02:05:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02558; Tue, 21 Mar 95 02:05:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02552; Tue, 21 Mar 95 02:05:31 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14237; Tue, 21 Mar 1995 01:57:50 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA11761; Tue, 21 Mar 95 01:57:47 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22982; Tue, 21 Mar 1995 10:57:43 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA11689; Tue, 21 Mar 1995 10:57:41 +0100 Message-Id: <9503210957.AA11689@dxcoms.cern.ch> Subject: (IPng) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Date: Tue, 21 Mar 1995 10:57:41 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9503131750.aa12193@IETF.CNRI.Reston.VA.US> from "Internet-Drafts@CNRI.Reston.VA.US" at Mar 13, 95 05:50:05 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bob, Section 2.4.3 in the address architecture draft is obsolete and refers to an obsolete draft. The new draft is substantially different, introduces a new extension header, and will be reviewed in the nosi BOF at Danvers. Your current text certainly cannot go to PS. If you want to go to PS in the next few weeks, I propose the following: 2.4.3 NSAP Addresses The general mapping of NSAP address into IPv6 addresses is as follows: | 7 | 121 bits | +-------+-+-----+-------+------------+--------+-------------------+ |0000001| to be defined | +-------+-+-----+-------+------------+--------+-------------------+ The draft definition, motivation, and usage are under study [NSAP]. ... [NSAP] "Mechanisms for OSI NSAPs, CLNP and TP over IPv6", B.Carpenter (ed.), Internet Draft, February 1995 (work in progress) Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 06:22:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02651; Tue, 21 Mar 95 06:22:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02645; Tue, 21 Mar 95 06:22:30 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26986; Tue, 21 Mar 1995 06:14:49 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA07902; Tue, 21 Mar 95 06:14:49 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm012-23.dialip.mich.net [141.211.7.191]) by merit.edu (8.6.10/merit-2.0) with SMTP id JAA23737 for ; Tue, 21 Mar 1995 09:14:46 -0500 Date: Tue, 21 Mar 95 13:37:42 GMT From: "William Allen Simpson" Message-Id: <4335.Bill.Simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM After an initial cursory reading, I agree with Brian: > From: "Brian Carpenter CERN-CN" > Your current text certainly cannot go to PS. There are too many forward and backward dependent references between documents, which are likely to change in the future. NOSI is only one of them. Instead, I recommend that all of the parts which reference or are dependent on any draft other than the "basic header" be removed. That would give us a single reference for general terms, and specific drafts for each special case. Much easier to understand. I'm not fond of the new term "region". Too nebulous, invokes/conflicts with older terms such as "Regional Provider". Is that the best we can do? Isn't there a nice graph theory term for a set of nodes which are fully-connected? The Addressing Model section seems reasonable overall, but the words provider and subscriber should be excised everywhere. All of these sections called "reserved" should be called "unassigned", to match Postel's usual labelling. The IPX allocation is much too big! These are only 6 bytes, and should have a 2 byte prefix. I like the new Neutral-Interconnect-Based reference (rather than Geographic), but would really prefer to call it Exchange (to match the term in current use), and don't think it needs any reservation in this draft. I'll handle that in mine, thanks. If you are going to use "region", then you should stop using "subnet prefix". Call it "region prefix", instead. Ditto for "subscriber prefix". Excise the entire "provider-based" section. It has nothing to do with this document. And conceivably is different than Yakov's draft, although I see that you've tried to fix that with registries. I agree with Brian that the NSAP section should be removed. Instead of these sections, you should just have a nice paragraph under the initial allocation map, stating that "Specific unicast allocation and routing strategies are outside the scope of this document. Please refer to the appropriate companion specifications." I known it's silly of me to want some order and logic to the presentation, but I would recommend that the next sections be in the same order as they are in the allocation map: - Unspecified - Loopback - IPv4 ... - Site-Local - Multicast Please change All-Routers to be ::02, which matches IPv4. All-Hosts can be ::03, which is "unassigned" in IPv4. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 08:23:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02685; Tue, 21 Mar 95 08:23:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02679; Tue, 21 Mar 95 08:23:01 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02967; Tue, 21 Mar 1995 08:15:19 -0800 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA21027; Tue, 21 Mar 95 07:37:21 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt To: ipng@sunroof.Eng.Sun.COM Date: Tue, 21 Mar 1995 15:35:32 +0000 (GMT) In-Reply-To: <4335.Bill.Simpson@um.cc.umich.edu> from "William Allen Simpson" at Mar 21, 95 01:37:42 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The IPX allocation is much too big! These are only 6 bytes, and should > have a 2 byte prefix. IPX addresses are 10 byte, and just using the node is not adequate. Token ring addresses may collide with ethernet, and the (far too) many remaining arcnet lans will all collide happily in the node area. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 08:23:26 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02692; Tue, 21 Mar 95 08:23:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02686; Tue, 21 Mar 95 08:23:14 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03007; Tue, 21 Mar 1995 08:15:33 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA18943; Tue, 21 Mar 95 07:22:46 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14603(2)>; Tue, 21 Mar 1995 07:22:17 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12175>; Tue, 21 Mar 1995 07:22:09 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: "William Allen Simpson" , deering@parc.xerox.com Subject: Re: (IPng) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt In-Reply-To: Bill.Simpson's message of Tue, 21 Mar 95 05:37:42 -0800. <4335.Bill.Simpson@um.cc.umich.edu> Date: Tue, 21 Mar 1995 07:22:00 PST From: Steve Deering Message-Id: <95Mar21.072209pst.12175@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I'm not fond of the new term "region". Too nebulous, invokes/conflicts > with older terms such as "Regional Provider". Is that the best we can > do? Isn't there a nice graph theory term for a set of nodes which are > fully-connected? First of all, you mean "connected", not "fully-connected", I believe. Second, according to the authors of the regions text, regions are not required to be connected. > If you are going to use "region", then you should stop using "subnet > prefix". Call it "region prefix", instead. > > Ditto for "subscriber prefix". No. Subnet and subscriber prefixes are specific instances of the general concept of region prefixes, and when speaking of the specific instance it is proper to use the specific name. All subnets are regions, but not all regions are subnets. My lack of response to your other comments should not be interpreted as agreement or disagreement, just as lack of time. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 08:28:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02717; Tue, 21 Mar 95 08:28:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02711; Tue, 21 Mar 95 08:28:50 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03844; Tue, 21 Mar 1995 08:21:08 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA20578; Tue, 21 Mar 95 07:35:36 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA17667; Tue, 21 Mar 1995 16:34:57 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA24394; Tue, 21 Mar 1995 16:34:55 +0100 Message-Id: <9503211534.AA24394@dxcoms.cern.ch> Subject: Re: (IPng) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt To: ipng@sunroof.Eng.Sun.COM Date: Tue, 21 Mar 1995 16:34:55 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <4335.Bill.Simpson@um.cc.umich.edu> from "William Allen Simpson" at Mar 21, 95 01:37:42 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, > After an initial cursory reading, I agree with Brian: > > > From: "Brian Carpenter CERN-CN" > > Your current text certainly cannot go to PS. > > There are too many forward and backward dependent references between > documents, which are likely to change in the future. NOSI is only one > of them. My remark was only intended to refer to the NOSI sub-section. I haven't had time to read the rest yet. ... > I agree with Brian that the NSAP section should be removed. Actually I suggested a specific simplified wording, not total removal. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 08:32:18 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02729; Tue, 21 Mar 95 08:32:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02723; Tue, 21 Mar 95 08:32:07 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04469; Tue, 21 Mar 1995 08:24:24 -0800 Received: from nic1.barrnet.net by Sun.COM (sun-barr.Sun.COM) id AA29911; Tue, 21 Mar 95 08:24:23 PST Received: from ipsilon.com by nic1.barrnet.net (8.6.10/BARRNET-RELAY.1) id IAA02599; Tue, 21 Mar 1995 08:24:22 -0800 Received: from [204.160.240.224] (acacia.ipsilon.COM) by ipsilon.com (4.1/SMI-4.1MDV1.0) id AA02039; Tue, 21 Mar 95 08:22:55 PST X-Sender: hinden@servo.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Mar 1995 08:22:31 -0800 To: ipng@sunroof.Eng.Sun.COM From: hinden@ipsilon.com (Bob Hinden) Subject: Re: (IPng) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Brian, Thanks. Sounds very reasonable. I will make that change. Bob At 10:57 AM 3/21/95, Brian Carpenter CERN-CN wrote: >Bob, > >Section 2.4.3 in the address architecture draft is obsolete >and refers to an obsolete draft. The new draft is substantially >different, introduces a new extension header, and will be >reviewed in the nosi BOF at Danvers. > >Your current text certainly cannot go to PS. If you want to go to PS >in the next few weeks, I propose the following: ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 09:14:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02785; Tue, 21 Mar 95 09:14:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02779; Tue, 21 Mar 95 09:13:59 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09696; Tue, 21 Mar 1995 09:06:16 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA23114; Tue, 21 Mar 95 07:49:04 PST Received: by rodan.UU.NET id QQyiap27287; Tue, 21 Mar 1995 10:48:58 -0500 From: stripes@uunet.uu.net (Josh Osborne) Message-Id: Subject: Re: (IPng) a few IPv6 API document related comments: To: ipng@sunroof.Eng.Sun.COM Date: Tue, 21 Mar 1995 10:48:58 -0500 (EST) In-Reply-To: from "Alan Cox" at Mar 21, 95 09:34:11 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [...] >This seems sensible. Many non BSD and especially non unix stacks regard >sendmsg()/recvmsg() as too esoteric to be worth code space. It had >minimal arguable value for OSI, and the unix file descriptor passing hack but >its not needed. It happens to be the only way (I know of) to do scatter/father I/O when using UDP in unconnected mode (and raw sockets as well I think). I don't do this very offen, but I have used it to make a few things run alot faster. (actually I used sendmsg - I only needed gather, not scatter) (this was actually a source of a ~10% improvment in a comercial package I worked on, which brought it from below the speed goal to just touching it) While it doesn't provide any functionality that can't be entirely and trivally synthised in user space wth sendto()/revcto(), there will be a loss of speed. It would be nice to see them spec'ed, but I can live without them. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 09:39:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02825; Tue, 21 Mar 95 09:39:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02661; Tue, 21 Mar 95 06:45:22 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28123; Tue, 21 Mar 1995 06:37:41 -0800 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA11283; Tue, 21 Mar 95 06:37:41 PST Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA25850; Tue, 21 Mar 95 09:36:01 EST Received: from grenada.wellfleet by wellfleet (4.1/SMI-4.1) id AA12559; Tue, 21 Mar 95 09:40:54 EST Date: Tue, 21 Mar 95 09:40:54 EST From: mdavis@wellfleet.com (Mike Davis) Message-Id: <9503211440.AA12559@wellfleet> Received: by grenada.wellfleet (4.1/SMI-4.1) id AA02748; Tue, 21 Mar 95 09:34:23 EST To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <4335.Bill.Simpson@um.cc.umich.edu> Subject: Re: (IPng) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >>>>> "Bill" == William Allen Simpson writes: Bill> After an initial cursory reading, I agree with Brian: >> From: "Brian Carpenter CERN-CN" Your >> current text certainly cannot go to PS. Bill> There are too many forward and backward dependent references Bill> between documents, which are likely to change in the future. Bill> NOSI is only one of them. Bill> Instead, I recommend that all of the parts which reference Bill> or are dependent on any draft other than the "basic header" Bill> be removed. That would give us a single reference for Bill> general terms, and specific drafts for each special case. Bill> Much easier to understand. It does seemm like a waste of trees to keep defining terms. All implementors will have to read the architecture document anyway. Bill> I'm not fond of the new term "region". Too nebulous, Bill> invokes/conflicts with older terms such as "Regional Bill> Provider". Is that the best we can do? Isn't there a nice Bill> graph theory term for a set of nodes which are Bill> fully-connected? H.T. Lau _Algorithms On Graphs_ calls it a "component." Not sure that quite fits the bill. . . . Bill> Instead of these sections, you should just have a nice Bill> paragraph under the initial allocation map, stating that Bill> "Specific unicast allocation and routing strategies Bill> are outside the scope of this document. Please refer to the Bill> appropriate companion specifications." As Bill notes and I concur, better use of cross-refs would improve the document. . . . Bill> Bill.Simpson@um.cc.umich.edu -mad signoff Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 09:48:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02855; Tue, 21 Mar 95 09:48:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02849; Tue, 21 Mar 95 09:48:14 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14913; Tue, 21 Mar 1995 09:40:31 -0800 Received: from alink-gw.apple.com by Sun.COM (sun-barr.Sun.COM) id AA17555; Tue, 21 Mar 95 09:40:25 PST Received: from federal-excess.apple.com by alink-gw.apple.com with SMTP (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA14252; Tue, 21 Mar 95 09:40:22 -0800 for ipng@sunroof.eng.sun.com Received: from lilith.lansys.apple.com by federal-excess.apple.com (5.0/1-Nov-1994-eef) id AA04670; Tue, 21 Mar 1995 09:38:57 +0800 for ipng@sunroof.eng.sun.com Received: (justin@localhost) by lilith.lansys.apple.com (8.6.9/A/UX 3.1) id JAA04924; Tue, 21 Mar 1995 09:40:34 -0800 Date: Tue, 21 Mar 1995 09:40:34 -0800 From: "Justin C. Walker" Message-Id: <199503211740.JAA04924@lilith.lansys.apple.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: Alan Cox's message of Tue, 21 Mar 1995 15:35:32 +0000 (GMT) Subject: (IPng) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> > The IPX allocation is much too big! These are only 6 bytes, and should >> > have a 2 byte prefix. >> >> IPX addresses are 10 byte, and just using the node is not adequate. Token >> ring addresses may collide with ethernet, and the (far too) many remaining >> arcnet lans will all collide happily in the node area. Geez, I hope not. Do you mean media addresses here? I thought all IEEE Lans used the same address space (with just the bit-order within bytes changing, to help keep life interesting :-}). Regards, Justin Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | They sentenced me to 20 years Apple Business Systems | of boredom Apple Computer, Inc. | For trying to change the system 10500 North De Anza Blvd | from within Cupertino, CA 95014 | LC *---------------------------------------*------------------------------------* ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 10:46:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02886; Tue, 21 Mar 95 10:46:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02880; Tue, 21 Mar 95 10:46:30 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23345; Tue, 21 Mar 1995 10:38:44 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA00803; Tue, 21 Mar 95 10:38:38 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08674; 21 Mar 95 12:18 EST 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 Subject: (IPng) I-D ACTION:draft-ietf-ipngwg-dns-00.txt Date: Tue, 21 Mar 95 12:18:26 -0500 Message-Id: <9503211218.aa08674@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : DNS Extensions to support IP version 6 Author(s) : S. Thomson, C. Huitema Filename : draft-ietf-ipngwg-dns-00.txt Pages : 5 Date : 03/20/1995 This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-dns-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-dns-00.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) 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-dns-00.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: <19950320103137.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-dns-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-dns-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950320103137.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 12:06:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02976; Tue, 21 Mar 95 12:06:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02970; Tue, 21 Mar 95 12:05:59 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08002; Tue, 21 Mar 1995 11:58:14 -0800 Received: from ftp.com by Sun.COM (sun-barr.Sun.COM) id AA20501; Tue, 21 Mar 95 11:58:12 PST Received: from ftp.com by ftp.com ; Tue, 21 Mar 1995 14:58:10 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 21 Mar 1995 14:58:10 -0500 Received: from solensky.beehive.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA22918; Tue, 21 Mar 95 14:56:06 EST Date: Tue, 21 Mar 95 14:56:06 EST Message-Id: <9503211956.AA22918@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) latest IPv6 spec From: solensky@ftp.com (Frank T Solensky) Repository: mailserv-D.ftp.com, [message accepted at Tue Mar 21 14:55:54 1995] Originating-Client: beehive.ftp.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Craig Partridge > > PS: Why discard opportunistic flow state within 6 seconds? (Curious > where the number came from). At the PARC meeting, some people felt 3 seconds was more than enough, others felt 10 seconds might be enough. We split the difference. -- Frank ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 12:08:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02999; Tue, 21 Mar 95 12:08:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02993; Tue, 21 Mar 95 12:07:57 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08431; Tue, 21 Mar 1995 12:00:12 -0800 Received: from mail1.digital.com by Sun.COM (sun-barr.Sun.COM) id AA21027; Tue, 21 Mar 95 12:00:06 PST Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 2/22/95 for V3.2/1.0/WV) id AA19778; Tue, 21 Mar 1995 11:51:26 -0800 Received: by xirtlu.zk3.dec.com; id AA10212; Tue, 21 Mar 1995 14:50:20 -0500 Message-Id: <9503211950.AA10212@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) a few IPv6 API document related comments: In-Reply-To: Your message of "Tue, 21 Mar 95 10:48:58 EST." Date: Tue, 21 Mar 95 14:50:14 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM RE: sendmsg/recvmsg... To add to what Josh said the scatter/gather IO can also be used to support RPC and other 'higher level than tranport APIs', /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 12:13:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03037; Tue, 21 Mar 95 12:13:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03030; Tue, 21 Mar 95 12:13:28 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09543; Tue, 21 Mar 1995 12:05:44 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA22494; Tue, 21 Mar 95 12:05:45 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm036-01.dialip.mich.net [141.211.7.43]) by merit.edu (8.6.10/merit-2.0) with SMTP id PAA08676 for ; Tue, 21 Mar 1995 15:05:41 -0500 Date: Tue, 21 Mar 95 19:19:18 GMT From: "William Allen Simpson" Message-Id: <4339.Bill.Simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: "William Allen Simpson" > The IPX allocation is much too big! These are only 6 bytes, and should > have a 2 byte prefix. > Well, that was a silly mistake. I was thinking of a reasonable address size, of course, not silly-16. Make that there are only 10 bytes, and there should be a 6 byte prefix. I'd recommend it to be 0000:0000:ffff::. It makes no difference how long the prefix is, since IPX is not globally routable. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 13:26:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03161; Tue, 21 Mar 95 13:26:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03155; Tue, 21 Mar 95 13:26:33 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20161; Tue, 21 Mar 1995 13:18:51 -0800 Received: from CLYNN.BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA07848; Tue, 21 Mar 95 13:18:50 PST Message-Id: <9503212118.AA07848@Sun.COM> Date: Tue, 21 Mar 95 16:16:50 EST From: Charles Lynn To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) a few IPv6 API document related comments: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, > [...] This seems sensible. Many non BSD and especially non unix > >stacks regard sendmsg()/recvmsg() as too esoteric to be worth code > >space. It had minimal arguable value for OSI, and the unix file > >descriptor passing hack but its not needed. > > It happens to be the only way (I know of) to do scatter/father I/O when It is also the most efficient way I have found to associate additional information with messages to be sent or received. Just because BSD or OSI didn't make good use of sendmsg/recvmsg does not mean that others haven't in the past or that future applications won't in the future. Charlie ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 13:37:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03173; Tue, 21 Mar 95 13:37:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03167; Tue, 21 Mar 95 13:37:30 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21624; Tue, 21 Mar 1995 13:29:47 -0800 Received: from VNET.IBM.COM by Sun.COM (sun-barr.Sun.COM) id AA10099; Tue, 21 Mar 95 13:29:43 PST Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 4156; Tue, 21 Mar 95 16:29:25 EST Received: by RTP (XAGENTA 4.0) id 2440; Tue, 21 Mar 1995 16:13:52 -0500 Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA14225; Tue, 21 Mar 1995 16:14:43 -0500 Message-Id: <9503212114.AA14225@cichlid.raleigh.ibm.com> To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: Re: (IPng) latest IPv6 spec In-Reply-To: (Your message of Sun, 19 Mar 95 15:43:31 PST.) <95Mar19.154338pst.12175@skylark.parc.xerox.com> Date: Tue, 21 Mar 95 16:14:42 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >4.1 Extension Header Order > >When more than one extension header is used in the same packet, it is >recommended that those headers appear in the following order: > > IPv6 header > Hop-by-Hop Options header > Destination Options header (1) > Routing header > Fragment header > Authentication header > Destination Options header (2) > upper-layer header What is the rational for having the fragmentation header appear before authentication? Isn't there a potential problem when authentication and fragmentation are used simultaneously? Specifically, one can't authenticate a packet until ALL fragments of a fragmented packet have been received and reassembled. But, if bogus fragments appear due to a denial-of-service attack, authentication can fail, even if none of the legitimate packets are lost or corrupted. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 14:56:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03247; Tue, 21 Mar 95 14:56:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02862; Tue, 21 Mar 95 10:04:14 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17194; Tue, 21 Mar 1995 09:56:30 -0800 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA21055; Tue, 21 Mar 95 09:56:13 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt To: ipng@sunroof.Eng.Sun.COM Date: Tue, 21 Mar 1995 17:59:24 +0000 (GMT) In-Reply-To: <199503211740.JAA04924@lilith.lansys.apple.com> from "Justin C. Walker" at Mar 21, 95 09:40:34 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Geez, I hope not. Do you mean media addresses here? I > thought all IEEE Lans used the same address space (with just the > bit-order within bytes changing, to help keep life interesting :-}). ArcNET isn't an IEEE lan. But there are lots of arcnet IPX networks and they are all network:0:0:0:0:0:x This may be a non-issue, unless novell succeed in creating their central registry of networks as most network numbers now are random. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 16:11:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03289; Tue, 21 Mar 95 16:11:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03283; Tue, 21 Mar 95 16:11:19 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11940; Tue, 21 Mar 1995 16:03:37 -0800 Received: from CU.NIH.GOV by Sun.COM (sun-barr.Sun.COM) id AA10784; Tue, 21 Mar 95 16:03:37 PST Message-Id: <9503220003.AA10784@Sun.COM> To: ipng@sunroof.Eng.Sun.COM From: "Roger Fajman" Date: Tue, 21 Mar 1995 19:02:17 EST Subject: Re: (IPng) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >> > The IPX allocation is much too big! These are only 6 bytes, and should > >> > have a 2 byte prefix. > >> > >> IPX addresses are 10 byte, and just using the node is not adequate. Token > >> ring addresses may collide with ethernet, and the (far too) many remaining > >> arcnet lans will all collide happily in the node area. > Geez, I hope not. Do you mean media addresses here? I > thought all IEEE Lans used the same address space (with just the > bit-order within bytes changing, to help keep life interesting :-}). IPX addresses consist of a 32 bit network number and the 48 bit MAC address for the station. That's 80 bits, 10 bytes total. So the IPng prefix could be 6 bytes long and still leave enough room for a full IPX address. P.S. - Novell runs a registry for assigning globally unique IPX network numbers. However, many IPX networks use made up network numbers. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 18:13:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03361; Tue, 21 Mar 95 18:13:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03348; Tue, 21 Mar 95 18:13:01 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB27040; Tue, 21 Mar 1995 18:05:18 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA08951; Tue, 21 Mar 95 18:05:17 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08744; 21 Mar 95 12:18 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) I-D ACTION:draft-simpson-exchanges-00.txt Date: Tue, 21 Mar 95 12:18:42 -0500 Message-Id: <9503211218.aa08744@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Unicast Allocation by Exchange Author(s) : W. Simpson Filename : draft-simpson-exchanges-00.txt Pages : 9 Date : 03/20/1995 This document specifies an administrative plan, wherein unicast node numbering is simply divided for allocation according to the nearest multi-domain interconnection. These are called "Internetwork Exchanges" (*IX). 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-simpson-exchanges-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-exchanges-00.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) 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-simpson-exchanges-00.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: <19950320111950.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-simpson-exchanges-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-exchanges-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950320111950.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 21 18:13:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03360; Tue, 21 Mar 95 18:13:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03342; Tue, 21 Mar 95 18:12:54 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27019; Tue, 21 Mar 1995 18:05:11 -0800 Received: from by Sun.COM (sun-barr.Sun.COM) id AB08910; Tue, 21 Mar 95 18:05:12 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08713; 21 Mar 95 12:18 EST 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 Subject: (IPng) I-D ACTION:draft-ietf-ipngwg-ipv6-spec-01.txt Date: Tue, 21 Mar 95 12:18:35 -0500 Message-Id: <9503211218.aa08713@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --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 : Internet Protocol, Version 6 (IPv6) Specification Author(s) : S. Deering, R. Hinden Filename : draft-ietf-ipngwg-ipv6-spec-01.txt Pages : 34 Date : 03/20/1995 This document specifies version 6 of the Internet Protocol, a proposed successor to IP version 4. All changes from the previous draft are listed in Appendix B. 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-ipv6-spec-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-spec-01.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) 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-ipv6-spec-01.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: <19950320110600.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-spec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-spec-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950320110600.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 22 04:10:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03666; Wed, 22 Mar 95 04:10:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03660; Wed, 22 Mar 95 04:10:05 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25045; Wed, 22 Mar 1995 04:02:23 -0800 Received: from noao.edu by Sun.COM (sun-barr.Sun.COM) id AA15856; Wed, 22 Mar 95 04:02:22 PST Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G100) id AA00349; Wed, 22 Mar 95 05:02:21 MST; for ipng@sunroof.eng.sun.com Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA09279; Wed, 22 Mar 95 05:02:20 MST; for ipng@sunroof.eng.sun.com Message-Id: <9503221202.AA09279@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Wed, 22 Mar 1995 05:02:20 -0700 X-Phone: +1 520 297 9416 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) a few IPv6 API document related comments: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > While it doesn't provide any functionality that can't be entirely and > trivally synthised in user space wth sendto()/revcto(), there will be a > loss of speed. It would be nice to see them spec'ed, but I can live > without them. Two features provided by recvmsg() that none of the other read/recv functions provide: (1) the destination IP address from a UDP datagram, and (2) a flag indicating whether the UDP datagram was truncated or not. Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 22 06:53:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03747; Wed, 22 Mar 95 06:53:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03741; Wed, 22 Mar 95 06:53:31 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01122; Wed, 22 Mar 1995 06:45:48 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AB02636; Wed, 22 Mar 95 06:45:41 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 22 Mar 95 23:44:08 +0900 From: Masataka Ohta Message-Id: <9503221444.AA28275@necom830.cc.titech.ac.jp> Subject: Re: (IPng) revised Flow ID management draft To: ipng@sunroof.Eng.Sun.COM Date: Wed, 22 Mar 95 23:44:06 JST Cc: end2end-interest@isi.edu In-Reply-To: <199503160057.QAA16758@aland.bbn.com>; from "Craig Partridge" at Mar 15, 95 4:57 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The Flow ID is a pseudo-random number between 1 and FFFFFF (hex) that > is unique when combined with the source address. I think it is implied that, if a source host have multiple interfaces and if dynamic rerouting changes the best path and cause a flow originate from the different interface from the initial one, the same "source address" should still be used. > In summary, the view is that the default rule should be that if a > router receives a datagram with an unknown Flow ID, it treats the > datagram as if the Flow ID and traffic class fields are zero. Then, to have consistent routing, that is, to prevent routing loop, all the following routers must treat the datagram as if the Flow ID and traffic class fields are zero. That is, the flow ID and traffic class fields must be reset to zero. > Which Datagrams Should Carry (Non-Zero) Flow IDs? > Interestingly, this is the problem on which the least progress has > been made. I, instead, think the answer is obvious and no progress is necessary. > Real-time flows must obviously always have a > Flow ID, since flows are a primary reason Flow IDs were created. The Why? If it is known that the path is fast enough to satisfy the real-time requirement without any reservation, there are no reason to use flows. > The argument in favor of using Flow IDs on individual TCP connections > is that even if the source does not request special service, a net- > work provider's routers may be able to recognize a large amount of > traffic and use the Flow ID field to establish a special route that > gives the TCP connection better service (e.g., lower delay or bigger > bandwidth). There seems to be complete misunderstanding. It is wrong to interpret TCP "a large amount of traffic". There is no reason to favour TCP connections than UDP connections. As RFC 761, STD 7, says: The Transmission Control Protocol (TCP) is intended for use as a highly reliable host-to-host protocol between hosts in packet-switched computer communication networks, and in interconnected systems of such networks. TCP is for reliable, not necessarily large amount, transport. Smtp is a good example. Finally, you can't allocate "bigger bandwidth" for "a large amount of traffic" unless you can do so without flows and you can't establish a special route for "lower delay" without "long initial delay". Ask "a special route", only when you know "long initial delay" can be tolerated and you can pay extra cost (money for temporal lease of dedicated lines, or slowing down unimportant TCPs, for example) for "bigger bandwidth", that is, let aplications, users or system administrators specify it. > Another argument is to assist in efficient demux at the > receiver (i.e., IP and TCP demuxing could be done once). Wrong. Unless you are requesting that even the transport headers must be identical in each packets, there is no reason that two TCPs can't be packed in a single flow. It is, instead, quite likely for flows for source-routing. For security reason (mentioned in the last paragraph of this mail, you must, anyway, check protocol IDs). > Observe that there is no easy compromise between these positions. > One cannot, for instance, let the application decide whether to use a > Flow ID. WHAT!!!???? How can you say such a thing? It is only the application which can know the requirements for flows. No compromise is necessary. Use flows only when they are required by applications. You can't just say "real-time" flow. Instead, you must specify the exact requirements for real-time-ness, such as delay tolerance, maximum bandwidth, jitter tolerance and so on, which are known only by applications or higher layer entities (such as system administrators). You can't just say "bigger bandwidth", either, without specifying how big it is. > Those who want different Flow IDs for every TCP connection > assume that they may optimize a route without the application's > knowledge. While I don't think each TCP needs a flow, let a system administrator set system-wide default, if he thinks almost all the application he runs use TCP for "a large amount of traffic". > 2. Flow IDs should expire if not refreshed within some number of > minutes (the exact number needs some more consideration) and > flow sources should observe a quiet time equal to this inter- > val after rebooting to avoid confusing Flow IDs The quiet time MUST be longer than the interval plus the expected maximum jitter on packet delay. Otheriwse, the jitter may make previous reservation live longer. As the jitter is expected to be smaller than the interval (otherwise, reservation is lost), we can safely say: 2. Flow IDs should expire if not refreshed within some number of minutes (the exact number needs some more consideration) and flow sources should observe a quiet time euqal to TWICE this inter- val after rebooting to avoid confusing Flow IDs And, I think a security issue must be considered. That is, the destination host must always check that packets with flows satisfies the condition specified by reservation packet and discard bad packets. Otherwise, a flow can be a tunnel through firewalls, which can not check (maybe at the video rate) individual packets and can perform filtering only on reservation requests. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 22 09:06:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03851; Wed, 22 Mar 95 09:06:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03543; Wed, 22 Mar 95 01:05:27 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15996; Wed, 22 Mar 1995 00:57:45 -0800 Received: from mutton.csv.warwick.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA29583; Wed, 22 Mar 95 00:57:32 PST Date: Wed, 22 Mar 1995 08:57:23 GMT From: Ian Dickinson Message-Id: <10992.199503220857@mutton.csv.warwick.ac.uk> Received: by mutton.csv.warwick.ac.uk id IAA10992; Wed, 22 Mar 1995 08:57:23 GMT In-Reply-To: iialan@iifeak.swan.ac.uk (Alan Cox) "Re: (IPng) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt" (Mar 21, 5:59pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Mar 21, 5:59pm, Alan Cox wrote: } Subject: Re: (IPng) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt > > Geez, I hope not. Do you mean media addresses here? I > > thought all IEEE Lans used the same address space (with just the > > bit-order within bytes changing, to help keep life interesting :-}). > > ArcNET isn't an IEEE lan. But there are lots of arcnet IPX networks and they > are all network:0:0:0:0:0:x > > This may be a non-issue, unless novell succeed in creating their central > registry of networks as most network numbers now are random. Most "connected" networks that use Novell seem to encode their 4byte IPv4 network-numbers as the Novell network number - it works well however you subnet, and internal network numbers just use one of the servers own IPv4 addresses. Are Novell avoiding that "small" part of the address space when people pay them real money to register? Cheers, -- Ian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 22 10:17:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03905; Wed, 22 Mar 95 10:17:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03899; Wed, 22 Mar 95 10:17:14 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20726; Wed, 22 Mar 1995 10:09:30 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA12734; Wed, 22 Mar 95 10:09:29 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11253; Thu, 23 Mar 1995 05:09:04 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 payload header Date: Thu, 23 Mar 1995 05:08:06 +1100 Message-Id: <8990.795895686@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Some of you may remember that I gave a brief presentation of a proposal for a "payload" header at one of the IPNG WG sessions in San Jose. I wrote a draft on that last December (which watching the test Cricket between Aus and England in melbuorne if it matters) and have finally gotten around to typing it, and submitting it as an I-D. It will appear soon as draft-kre-ipv6-payload-00.txt If you want, for some reason, to look at it in advance, I have stuck it in the big-internet directory on munnari.OZ.AU that is, ftp://munnari.oz.au/big-internet/draft-kre-ipv6-payload-00.txt Comments appreciated. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 22 12:47:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03961; Wed, 22 Mar 95 12:47:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03955; Wed, 22 Mar 95 12:47:17 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08798; Wed, 22 Mar 1995 12:39:33 -0800 Received: from merit.edu ([35.1.1.42]) by Sun.COM (sun-barr.Sun.COM) id AA09745; Wed, 22 Mar 95 12:34:04 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-24.dialip.mich.net [141.211.7.160]) by merit.edu (8.6.10/merit-2.0) with SMTP id OAA01366 for ; Wed, 22 Mar 1995 14:25:34 -0500 Date: Wed, 22 Mar 95 19:01:14 GMT From: "William Allen Simpson" Message-Id: <4353.Bill.Simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Ian Dickinson > Most "connected" networks that use Novell seem to encode their 4byte IPv4 > network-numbers as the Novell network number - it works well however you > subnet, and internal network numbers just use one of the servers own IPv4 > addresses. Are Novell avoiding that "small" part of the address space when > people pay them real money to register? > Novell has reserved the top byte of 00 for this use. You just slide the IPv4 address 8 bits to the right. Of course, that only works for one link per class C.... Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 22 13:26:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04021; Wed, 22 Mar 95 13:26:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04015; Wed, 22 Mar 95 13:26:49 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12204; Wed, 22 Mar 1995 13:19:06 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA17150; Wed, 22 Mar 95 13:18:58 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA18263; Thu, 23 Mar 1995 08:18:53 +1100 (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 AA03603; Thu, 23 Mar 95 07:00:40 +1000 Received: by dcthq2.datacraft.com.au; Thu, 23 Mar 95 8:18:10 +1100 Date: Thu, 23 Mar 95 7:48:28 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: Re(IPng): remarks to addressing X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM re Lode Coens response on signalling. Thanks - its nice to see some support for the problems. The points I tried to make are this; that where a (address) number is used, it is nice if it is transportable between providers. This is against the thoughts currently being promoted for IP6 addresses. We have no mechanism in IPNG for doing this "provider switching" as it would require global directory systems of some form. If we use personal addresses we will also require separation of the calling information and the connection information. If we require personal addresses we require some horsepower and iron IN the network. Philosophically speaking the ITU (dare I say this) design networks from the inside out so that carriers provide end services (and have the network ownership), therefore network functionality can be and is complex. The Internet approach is to design networks from the end systems (outside in) and keep the network simple ie connectionless. Once one ventures into Security in the network, QOS and Flow in the network and dynamic address reassignement within the network, one has to put in iron and "global" functions. Particulartly if networks rather than treeworks are proposed. Globally meshed networks will need some nailing down of the address space used by the core mesh. As these mesh points will be regionally or nationally based, why not use regional and / or nationally based registrations. I still dont see any concrete text on the above. ie the Internet as a regionally / nationally based mesh and how its addressing is applied. the mechanisms needed for Internet users to switch around the mesh and between providers. AND still be contactable by its normal networked partners and hopefully keep the same number. Possible conflict between switching providers and "home bases". So my understanding at the moment of the above is that we have a few things in conflict. Simple connectionless networks vs complex dynamically addressed networks with user controlled functions (eg security). Regards Alan@Oz PS I understand FTP uses embedded IP addresses, how does this affect reassignement, routing, provider switching in the IP6 env? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 22 18:18:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04175; Wed, 22 Mar 95 18:18:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04169; Wed, 22 Mar 95 18:18:23 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18203; Wed, 22 Mar 1995 18:10:38 -0800 Received: from CU.NIH.GOV by Sun.COM (sun-barr.Sun.COM) id AA28234; Wed, 22 Mar 95 18:10:37 PST Message-Id: <9503230210.AA28234@Sun.COM> To: ipng@sunroof.Eng.Sun.COM From: "Roger Fajman" Date: Wed, 22 Mar 1995 21:08:34 EST Subject: Re: (IPng) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > Most "connected" networks that use Novell seem to encode their 4byte IPv4 > > network-numbers as the Novell network number - it works well however you > > subnet, and internal network numbers just use one of the servers own IPv4 > > addresses. Are Novell avoiding that "small" part of the address space when > > people pay them real money to register? > > > Novell has reserved the top byte of 00 for this use. You just slide the > IPv4 address 8 bits to the right. > > Of course, that only works for one link per class C.... Right. I wonder what they were thinking when they designed that algorithm? With a Class C number or a Class B with an 8-bit subnet mask, it leaves no space for the internal network numbers (different from the wire's number) that Netware servers need. In our case, we have a 7-bit mask with our Class Bs, so we would get 2 numbers per subnet, which is not enough for any subnet with more than one server. So we paid Novell for a separate block of numbers. Maybe that explains it. :-) I appolgize for straying rather far off topic here. I just wanted to complete the thread on IPX numbering. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 22 23:57:01 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04288; Wed, 22 Mar 95 23:57:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04282; Wed, 22 Mar 95 23:56:53 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05119; Wed, 22 Mar 1995 23:49:07 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA16299; Wed, 22 Mar 95 23:49:09 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA07703; Thu, 23 Mar 1995 08:34:59 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA15273; Thu, 23 Mar 1995 08:34:57 +0100 Message-Id: <9503230734.AA15273@dxcoms.cern.ch> Subject: Re: (IPng) I-D ACTION:draft-simpson-exchanges-00.txt To: ipng@sunroof.Eng.Sun.COM Date: Thu, 23 Mar 1995 08:34:56 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9503211218.aa08744@IETF.CNRI.Reston.VA.US> from "Internet-Drafts@CNRI.Reston.VA.US" at Mar 21, 95 12:18:42 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, I must be slowing down, beacuse I find your draft fundamentally difficult to understand. Could you provide some specific examples for pedestrians? Also I don't at all understand how you handle multi-homed organizations (presumably connected to multiple exchanges via multiple providers). Don't they end up with multiple addresses? 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 Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 23 08:51:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04478; Thu, 23 Mar 95 08:51:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04472; Thu, 23 Mar 95 08:51:08 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03113; Thu, 23 Mar 1995 08:43:23 -0800 Received: from itd.nrl.navy.mil (itd-fddi.nrl.navy.mil) by Sun.COM (sun-barr.Sun.COM) id AB21485; Thu, 23 Mar 95 08:43:16 PST Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA21830; Thu, 23 Mar 95 11:43:15 EST Date: Thu, 23 Mar 95 11:43:15 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9503231643.AA21830@itd.nrl.navy.mil> To: ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net Subject: (IPng) new Security Drafts available for ftp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, Revised security drafts are available via anonymous ftp from ftp.nrl.navy.mil. I'm not sending them via email because I'm told the list is now too large for big I-Ds to be posted to it. They have also been submitted to the I-D archive folks at CNRI and should appear at the usual I-D archive sites when those folks get time. They will appear with the prefix draft-ietf-ipsec-*.txt at the I-D archive sites. The online IPng drafts having a prefix of draft-ietf-ipngwg-esp-*, draft-ietf-ipngwg-auth-*, and draft-ietf-ipngwg-sec-* are now obsoleted by these new drafts. Approximate URLs are: ftp://ftp.nrl.navy.mil/pub/security/ip-auth.txt ftp://ftp.nrl.navy.mil/pub/security/ip-esp.txt ftp://ftp.nrl.navy.mil/pub/security/ip-sec.txt Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 23 09:45:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04540; Thu, 23 Mar 95 09:45:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04534; Thu, 23 Mar 95 09:44:53 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09593; Thu, 23 Mar 1995 09:37:07 -0800 Received: from nic1.barrnet.net by Sun.COM (sun-barr.Sun.COM) id AA04234; Thu, 23 Mar 95 09:37:05 PST Received: from ipsilon.com by nic1.barrnet.net (8.6.10/BARRNET-RELAY.1) id JAA21558; Thu, 23 Mar 1995 09:37:04 -0800 Received: from by ipsilon.com (4.1/SMI-4.1MDV1.0) id AB03577; Thu, 23 Mar 95 09:35:40 PST X-Sender: hinden@servo.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Mar 1995 09:35:16 -0800 To: ipng@sunroof.Eng.Sun.COM From: hinden@ipsilon.com (Bob Hinden) Subject: (IPng) IPng W.G. Last Call for Security Drafts Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The constitutes the IPng working group last call for the three security drafts. The period of the last call is one week. Bob >Date: Thu, 23 Mar 95 11:43:15 EST >From: atkinson@itd.nrl.navy.mil (Ran Atkinson) >To: ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net >Subject: (IPng) new Security Drafts available for ftp >Sender: owner-ipng@sunroof.Eng.Sun.COM >Precedence: bulk >Reply-To: ipng@sunroof.Eng.Sun.COM > >Folks, > > Revised security drafts are available via anonymous ftp from >ftp.nrl.navy.mil. I'm not sending them via email because I'm told the >list is now too large for big I-Ds to be posted to it. > > They have also been submitted to the I-D archive folks at CNRI and >should appear at the usual I-D archive sites when those folks get >time. They will appear with the prefix draft-ietf-ipsec-*.txt >at the I-D archive sites. > > The online IPng drafts having a prefix of draft-ietf-ipngwg-esp-*, >draft-ietf-ipngwg-auth-*, and draft-ietf-ipngwg-sec-* are now >obsoleted by these new drafts. > > >Approximate URLs are: > ftp://ftp.nrl.navy.mil/pub/security/ip-auth.txt > ftp://ftp.nrl.navy.mil/pub/security/ip-esp.txt > ftp://ftp.nrl.navy.mil/pub/security/ip-sec.txt > >Ran >atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 23 10:27:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04583; Thu, 23 Mar 95 10:27:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04550; Thu, 23 Mar 95 10:22:15 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14869; Thu, 23 Mar 1995 10:14:28 -0800 Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA11981; Thu, 23 Mar 95 10:14:28 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id NAA22623 for ipng@sunroof.Eng.Sun.COM; Thu, 23 Mar 1995 13:17:32 -0500 (EST) Date: Thu, 23 Mar 1995 13:17:32 -0500 (EST) From: Scott Bradner Message-Id: <199503231817.NAA22623@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPng W.G. Last Call for Security Drafts Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM please do all discussions on these documents on the ipsec mailing list (ipsec@ans.net) ( -request to subscribe ) thanks Scott ----- From owner-ipng@sunroof2.Eng.Sun.COM Thu Mar 23 12:48:52 1995 X-Sender: hinden@servo.ipsilon.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Mar 1995 09:35:16 -0800 To: ipng@sunroof.Eng.Sun.COM From: hinden@ipsilon.com (Bob Hinden) Subject: (IPng) IPng W.G. Last Call for Security Drafts Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The constitutes the IPng working group last call for the three security drafts. The period of the last call is one week. Bob >Date: Thu, 23 Mar 95 11:43:15 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) >To: ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net >Subject: (IPng) new Security Drafts available for ftp >Sender: owner-ipng@sunroof.Eng.Sun.COM >Precedence: bulk >Reply-To: ipng@sunroof.Eng.Sun.COM > >Folks, > > Revised security drafts are available via anonymous ftp from >ftp.nrl.navy.mil. I'm not sending them via email because I'm told the >list is now too large for big I-Ds to be posted to it. > > They have also been submitted to the I-D archive folks at CNRI and >should appear at the usual I-D archive sites when those folks get >time. They will appear with the prefix draft-ietf-ipsec-*.txt >at the I-D archive sites. > > The online IPng drafts having a prefix of draft-ietf-ipngwg-esp-*, >draft-ietf-ipngwg-auth-*, and draft-ietf-ipngwg-sec-* are now >obsoleted by these new drafts. > > >Approximate URLs are: > ftp://ftp.nrl.navy.mil/pub/security/ip-auth.txt > ftp://ftp.nrl.navy.mil/pub/security/ip-esp.txt > ftp://ftp.nrl.navy.mil/pub/security/ip-sec.txt > >Ran >atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 23 14:53:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04777; Thu, 23 Mar 95 14:53:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04771; Thu, 23 Mar 95 14:53:04 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23259; Thu, 23 Mar 1995 14:45:18 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA11045; Thu, 23 Mar 95 14:44:41 PST Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA06102; Thu, 23 Mar 1995 17:44:37 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA23245; Thu, 23 Mar 1995 17:44:14 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA17132; Thu, 23 Mar 1995 17:20:01 -0500 Message-Id: <9503232220.AA17132@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com, set@thumper.bellcore.com, bob.gilligan@Eng, conta@zk3.dec.com Subject: Re: (IPng) a few IPv6 API document related comments: In-Reply-To: Your message of "Tue, 21 Mar 95 04:26:35 EST." <9503210926.AA16661@xirtlu.zk3.dec.com> Date: Thu, 23 Mar 95 17:20:01 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: bound@zk3.dec.com Subject: Re: (IPng) a few IPv6 API document related comments: >I have in mind porting an application from IPv4 to dual IPv6 and IPv4. >I would like to replace 'gethostbyname' with 'hostname2addr', and use the >addresses and address family returned to issue subsequent socket calls >without any additional calls, or conversions. The proposed addition will do >just that. This is more simple and requires less from the programmer. >Using 'is_ipv4_addr' as documented, is one more step, and it requires >additionally some more steps, which altough are not difficult to do for one >who knows the details, are still demanding knowledge from a programmer, and >is also less elegant. This discussion must happen, but I prefer not here and later? OK? If we want a minimum modification in the spec, is it not the time now to do it? .....Typically (and in all cases I am aware of) gethostbyname() is done after s=socket(....). 'gethostbyname' does not require a 'socket', so it can be and it is called in many cases I am aware of, before the 'socket' call, and for good reasons - if the name translation fails, you save two calls that otherwise you'd do - a 'socket' and a 'close'. Using is_ipv4_addr provides all the uses of the AF in/out approach as a boolean test and the socket family can be selected: if is_ipv4_addr(* ap) then if doing_ipv4_only_stack then /* ipv4 mapped to be ipv4 only */ socket (PF_INET, type, protocol) /* later the low order bits of the ipv4 mapped address will need to be located */ else socket (PF_INET6, type, protocol) /* in this case the address is passed to the socket layer as ipv4 mapped, ipv4 compatible, or ipv6 only. Using the AF approach its a case statement: switch AF_RETURNED (whatever) AF_INET do socket open PF_INET AF_INET6 do socket open PF_INET6 The code can be simplified more than that with the modification discussed: int af = 0; ... if ( success = hostname2addr(..., af)) then s = socket (af,...) else exit endif With is_ipv4_addr you have to specifically test for an ipv4 mapped and .... But in the AF in/out case presented you only receive an AF_INET or AF_INET6 parameter which does not tell one of the cases above that you have an ipv4 mapped address so with the AF approach another condition has to be tested anyway if your interested in knowing you have an ipv4 mapped address in an application. The use of 'af=0' is particularly useful when you do not care, whether the address returned is IPv6 or IPv4, or IPv4-mapped IPv6 address. The application can use any of the three addresses, and in a very simple way with the modification discussed. This is where one can head down the transition assumption or options discussion I want to avoid now. The assumption made in the spec is that if: af=AF_INET6 hostname2addr returns an array of IPv6 addresses: - real IPv6 addresses if any IPv6 addresses exist if not - IPv4-mapped IPv6 addresses if any IPv4 addresses exist. af=AF_INET hostname2addr returns an array of IPv4 addresses. If one would be intersted in using IPv4 addresses only, then it should specify af = AF_INET, and not go through the parsing operation. Taking the 'mapped' address out of the picture, you still have 'ipv6' versus 'ipv4' addresses. The other advantage of is_ipv4_addr is that it can be used to test a peer address from accept or recvfrom to determine if you have recieved and address from an ipv4 only node. I see its purpose as being mainly this. So it serves multiple purposes and functions in addition to providing applications the ability to determine socket connection PFs. This function is over-stretched a little. >> One idea presented was to pass a socket structure to is_ipv4_addr and >> have it filled out upon return, which would be more powerful than any >> solution so far. >I am not sure I follow, so the 'is_ipv4_addr' would fill out the 'socket' >structure based on a 'socket' structure and 'in_addr6' structure passed as >input arguments? Would the 'is_ipv4_addr' be still part of the >'Name-to-Address Translation Functions' ? It would be: is_ipv4_addr(struct sockaddr *) This is a 'sockaddr' structure. Your saying 'socket' structure mislead me. It would return TRUE for AF_INET address and for AF_INET6 addresses that are not ipv4 mapped. This permits the function to also receive a family/type field which could be useful too. It basically extends the use of is_ipv4_addr to also take as input to its return family/type parameters too, that could be useful in the future. More combinations can be done with 'af' as value returned by 'hostname2addr' to accomodate both the role of 'address family' in a 'sockaddr...' structure, and the 'protocol family' in a 'socket' call, and the value returned by 'hostname2addr'. It just extends the use of is_ipv4_addr. It also may eliminate any transition discussions because of its flexibiltiy to handle all cases. Hence, it can be used to accomplish the variants that users will require to transition from IPv4 to IPv6. It makes the tool more efficient IMHO. /jim This is a good idea. But having this additional function should not preclude 'hostname2addr' from returning a value in 'af', when 'af' is passed on input as 'zero', which is a minimal addition, but with good use, and a simplifying effect on applications that will run on both IPv6 and IPv4. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 23 20:46:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04945; Thu, 23 Mar 95 20:46:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04939; Thu, 23 Mar 95 20:46:23 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01212; Thu, 23 Mar 1995 20:38:37 -0800 Received: from mail1.digital.com by Sun.COM (sun-barr.Sun.COM) id AA16220; Thu, 23 Mar 95 20:38:38 PST Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 2/22/95 for V3.2/1.0/WV) id AA27627; Thu, 23 Mar 1995 20:30:15 -0800 Received: by xirtlu.zk3.dec.com; id AA01199; Thu, 23 Mar 1995 23:29:01 -0500 Message-Id: <9503240429.AA01199@xirtlu.zk3.dec.com> To: conta@brigit.zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com, set@thumper.bellcore.com, bob.gilligan@Eng Subject: Re: (IPng) a few IPv6 API document related comments: In-Reply-To: Your message of "Thu, 23 Mar 95 17:20:01 EST." <9503232220.AA17132@brigit.zk3.dec.com> Date: Thu, 23 Mar 95 23:28:55 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Thu, 23 Mar 95 17:20:01 -0500 From: conta@brigit.zk3.dec.com >'gethostbyname' does not require a 'socket', so it can be and it is called in >many cases I am aware of, before the 'socket' call, and for good reasons - if >the name translation fails, you save two calls that otherwise you'd do - >a 'socket' and a 'close'. Well most UNIX product manuals and API text books that describe the use of using sockets and gethostbyname with code examples also perform gethostbyname after the socket call. But, I see your point and that it could be done this way. Kind of like session control. But, I am not a fan of session control in APIs generally. If one would want to implement the API that way they can use is_ipv4_addr and its useful for other purposes too. >If one would be intersted in using IPv4 addresses only, then it should >specify > af = AF_INET, and not go through the parsing operation. I completely disagree that this should be the ONLY way to perform this function, but we can debate this someday again in an ngtrans mail list or at an IETF ngtrans meeting, when that time is upon us. > So it serves multiple purposes and > functions in addition to providing applications the ability to > determine socket connection PFs. >This function is over-stretched a little. And as I said before it can be used after accept/recvfrom too. I think it does serve multiple purposes. Thats not over-stretched it is simply true. >> One idea presented was to pass a socket structure to is_ipv4_addr and >> have it filled out upon return, which would be more powerful than any >> solution so far. >I am not sure I follow, so the 'is_ipv4_addr' would fill out the 'socket' >structure based on a 'socket' structure and 'in_addr6' structure passed as >input arguments? Would the 'is_ipv4_addr' be still part of the >'Name-to-Address Translation Functions' ? It would be: is_ipv4_addr(struct sockaddr *) >This is a 'sockaddr' structure. Your saying 'socket' structure mislead me. I see your point, but I figured when you saw 'socket structure' you would think struct: sockaddr_in or sockaddr_in6; NOT in_addr or in6_addr. I will be much more specific in the future. >But having this additional function should not preclude >'hostname2addr' from returning a value in 'af', when 'af' is passed on input >as 'zero', which is a minimal addition, but with good use, and a simplifying >effect on applications that will run on both IPv6 and IPv4. Well I am talked out. I defer to my co-authors and the WG. I suggest we not add what Alex is proposing. thanks for the input, /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 24 09:08:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05153; Fri, 24 Mar 95 09:08:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05047; Fri, 24 Mar 95 02:52:33 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14538; Fri, 24 Mar 1995 02:44:48 -0800 Received: from magna.com.au by Sun.COM (sun-barr.Sun.COM) id AA20906; Fri, 24 Mar 95 02:44:40 PST Received: from atlas.turbosoft.com.au by magna.com.au id aa11419; 22 Mar 95 15:37 PST Received: by atlas.turbosoft.com.au (4.1/TS-0.4) id AA14158; Wed, 22 Mar 95 15:52:21 EST Message-Id: <9503220552.AA14158@atlas.turbosoft.com.au> From: paul@atlas.turbosoft.com.au Date: Wed, 22 Mar 1995 15:52:20 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Thus expounded Alan Cox on Mar 21, 5:59pm: /-------------------- | |ArcNET isn't an IEEE lan. But there are lots of arcnet IPX networks and they |are all network:0:0:0:0:0:x | |This may be a non-issue, unless novell succeed in creating their central |registry of networks as most network numbers now are random. I wish they are random. In real life, the vast majority of IPX networks I've seen are numbered 00001,00002,00003,... within each organisation. Collisions will be almost certain, I'm afraid. -- Paul Brooks | paul@turbosoft.com.au | Ssshhh: Network Specialist | pwb@newt.phys.unsw.edu.au| We're hunting TurboSoft Pty Ltd | | wabbits (in 579 Harris St., Ultimo | Ph : +61 2 281 3155 | Centennial Park) ! Sydney Australia 2007 l Fax: +61 2 281 3350 | ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 24 10:34:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05275; Fri, 24 Mar 95 10:34:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05242; Fri, 24 Mar 95 10:28:24 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19658; Fri, 24 Mar 1995 10:20:36 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA29769; Fri, 24 Mar 95 10:20:35 PST From: Ran Atkinson Message-Id: <9503241317.ZM3275@bodhi> Date: Fri, 24 Mar 1995 13:17:02 -0500 X-Mailer: Z-Mail (3.0.0 15dec93) To: ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net Subject: (IPng) 2 additional Security drafts available for ftp Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, There are two additional security drafts that are now available for anonymous ftp. They are the mandatory algorithm/transform specifications for use with the IP Authentcation Header and the IP Encapsulating Security Payload. They were written by Metzger, Karn, and Simpson. They are products of both IPsec and IPng working groups and are for use both with IPv4 and IPv6. I believe that a Last Call on these will start soon. They are being made available for ftp now because there is the usual last-minute submission crunch in I-D processing at the IETF Secretariat. They are not being emailed because of mailing list size and document size. Approximate URLs for these drafts are: ftp://ftp.nrl.navy.mil/pub/security/draft-ietf-ipsec-esp-des-cbc-*.txt ftp://ftp.nrl.navy.mil/pub/security/draft-ietf-ipsec-ah-md5--*.txt A note about ftp.nrl.navy.mil: Like many modern anonymous ftp sites, you should type either your "loginid@your.domain" or "guest@" for the password instead of just "guest". Also, that system will do an inverse DNS lookup on your IP address -- if that inverse DNS lookup fails you might not be allowed access. Any system properly registered in the DNS should have no technical problems accessing the site. If there are problems and you've followed these instructions, please send email to atkinson@itd.nrl.navy.mil and I'll work on the problem. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 24 14:42:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05452; Fri, 24 Mar 95 14:42:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05443; Fri, 24 Mar 95 14:42:21 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20922; Fri, 24 Mar 1995 14:34:29 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA12339; Fri, 24 Mar 95 14:30:35 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm036-01.dialip.mich.net [141.211.7.43]) by merit.edu (8.6.10/merit-2.0) with SMTP id PAA24531 for ; Fri, 24 Mar 1995 15:40:20 -0500 Date: Fri, 24 Mar 95 18:31:52 GMT From: "William Allen Simpson" Message-Id: <4361.Bill.Simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) draft-simpson-exchanges-00.txt Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: "Brian Carpenter CERN-CN" > I must be slowing down, beacuse I find your draft fundamentally > difficult to understand. "Fundamentally" is quite serious. Could you be more specific about which fundamentals you don't understand? > Could you provide some specific examples > for pedestrians? Sure. As stated in the 1st paragraph of the 1st section: This plan provides for administrative allocation based on each nexus of interconnection of three (3) or more Administrative Domains. These are termed "Internetwork Exchanges" (*IX). Say we have 5 ADs which interconnect at 2 *IXs: +------AD1------+ | | | AD2------* *IX1 | | *IX2 *------AD3------+ | +------AD4------+------AD5 Looking at the AD section: Each Administrative Domain is administratively assigned a prefix which is used as a Routing Domain Identifier (RDI). The RDI is derived from each Exchange to which the Domain has direct access, or is allowed indirect access through another Domain. Assuming that *IX1 is assigned the prefix 7001::, and *IX2 is assigned prefix 7002::, then a possible assignment would be (using assignment per RFC-1219): RDI size AD1 7001:8000:: 24 7002:c000:: 24 AD2 7001:4000:: 23 AD3 7001:c000:: 26 7002:4000:: 26 AD4 7002:8000:: 22 AD5 7002:2000:: 29 Assuming they are not the same size. Changing the prefix-size would allow new ADs to be inserted between existing ADs. Note that AD5 is assigned based on the Exchange, not the indirect access. If AD5 wants to have its own direct link later (bypasses AD4), it just makes the connection. > Also I don't at all understand how you handle > multi-homed organizations (presumably connected to multiple > exchanges via multiple providers). What "providers"? A provider is just an AD that allows transit traffic. AD4 could be called a provider. We don't care what they call themselves, as long as they offer connectivity. > Don't they end up with multiple addresses? > Of course! As written: Because the Domain can utilize more than one Exchange, it can have more than one RDI. Each Domain may chose to limit the number of indirect RDI numbers in use at one time. All IPv6 nodes very frequently end up with multiple addresses, even under "provider/subscriber". But, Exchange assignment won't need as many multiple addresses as under a provider/subscriber scheme, which (as I've repeated many times) could end up with 720 addresses per interface with 7 layers of hierarchy in a fully connected mesh. Otherwise, provider/subscriber won't aggregate. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 24 15:48:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05536; Fri, 24 Mar 95 15:48:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05530; Fri, 24 Mar 95 15:48:43 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01424; Fri, 24 Mar 1995 15:40:54 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA03297; Fri, 24 Mar 95 15:40:54 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02338; 24 Mar 95 16:14 EST To: ipng@sunroof.Eng.Sun.COM, ietf-rip@xylogics.com From: Gary Scott Malkin Cc: mwalnut@CNRI.Reston.VA.US Subject: (IPng) APRIL '95: RIP WG Date: Fri, 24 Mar 95 16:14:24 -0500 Message-Id: <9503241614.aa02338@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM This agenda is also available via the ietf gopher server and the IETF Web Page. Gopher ------- Information pertaining to the 32nd IETF is available on the Gopher Server running on IETF.CNRI.RESTON.VA.US (132.151.1.35) under "Internet Engineering Task Force (IETF) / IETF Meetings / Danvers April 1995 / WG and BOF Agendas (subject to change)". WWW ------- Click on the link for "meetings" and you should find an entry for the Danvers meeting. ----------------- RIP WG (rip) 32nd IETF - Danvers Thursday, April 6, 1995 0900-1130 1 - Review of revised "RIP-II Cryptographic Authentication" Internet Draft 2 - Review of "Demand Circuit RIP" Internet Draft Discussion of Standards Status 3 - RIP-2 -- face-to-face discussions of the recent email debates 4 - Review of "RIPng for IPv6" Internet Draft 5 - Any other issues 6 - Summary of decisions and action items ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 24 16:50:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05691; Fri, 24 Mar 95 16:50:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05685; Fri, 24 Mar 95 16:49:50 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08248; Fri, 24 Mar 1995 16:42:03 -0800 Received: from relay.hp.com by Sun.COM (sun-barr.Sun.COM) id AA12486; Fri, 24 Mar 95 16:42:02 PST Received: from hpindlm.cup.hp.com by relay.hp.com with ESMTP (1.37.109.15/15.5+ECS 3.3) id AA027862121; Fri, 24 Mar 1995 16:42:01 -0800 Received: by hpindlm.cup.hp.com (1.37.109.15/15.5+IOS 3.20+cup+OMrelay) id AA189822093; Fri, 24 Mar 1995 16:41:33 -0800 Date: Fri, 24 Mar 1995 16:41:33 -0800 From: Wan-Yen Hsu Message-Id: <199503250041.AA189822093@hpindlm.cup.hp.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) comments on BSD API Spec Cc: wanyen@hpindlm.cup.hp.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Comments on "IPv6 BSD API Spec" I noticed that u_long is used to define sa_addr and sin6_flowlabel in the "IPv6 BSD API Spec". In the ILP64 and LP64 models, a "u_long" type is 64bit. To avoid size incosistency in various 64bit compiler models, "char" or a word-size independent type should be used to declare sa_addr and sin6_flowlabel in the following sections: > 4.2 IPv6 Address Data Structure > A new data structure to hold a single IPv6 address is defined in > : > struct in_addr6 { > u_long sa_addr[4]; /* ipv6 address */ > ^^^^^^^^^^^^^^^^^^^^^ > } > This data structure contains an array of four 32-bit elements, which ^^^^^^^^^^^^^^^^^^^^ > make up one 128-bit IPv6 address. A new type declaration for sa_addr: struct in_addr6 { char sa_addr[16]; /* ipv6 address */ } or struct in_addr6 { u_int32 sa_addr[4]; /* ipv6 address */ } Also, a u_int32 type can be used to declare sin6_flowlabel in the sockaddr_in6 structre. Wan-yen ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 24 17:36:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05797; Fri, 24 Mar 95 17:36:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05790; Fri, 24 Mar 95 17:36:37 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12946; Fri, 24 Mar 1995 17:28:49 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA20782; Fri, 24 Mar 95 17:28:48 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04563; 24 Mar 95 17:36 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) I-D ACTION:draft-ietf-ipsec-esp-des-cbc-03.txt Date: Fri, 24 Mar 95 17:36:28 -0500 Message-Id: <9503241736.aa04563@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Protocol Security Protocol Working Group of the IETF. Title : The ESP DES-CBC Transform Author(s) : P. Metzger, P. Karn, W. Simpson Filename : draft-ietf-ipsec-esp-des-cbc-03.txt Pages : 8 Date : 03/23/1995 This document describes the DES-CBC security transform for the IP Encapsulating Security Payload (ESP). 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-ipsec-esp-des-cbc-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-des-cbc-03.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) 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-ipsec-esp-des-cbc-03.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: <19950323135417.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-des-cbc-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-des-cbc-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950323135417.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 24 17:36:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05796; Fri, 24 Mar 95 17:36:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05784; Fri, 24 Mar 95 17:36:32 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12928; Fri, 24 Mar 1995 17:28:44 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA20761; Fri, 24 Mar 95 17:28:43 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04544; 24 Mar 95 17:36 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) I-D ACTION:draft-ietf-ipsec-ah-md5-02.txt Date: Fri, 24 Mar 95 17:36:23 -0500 Message-Id: <9503241736.aa04544@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Protocol Security Protocol Working Group of the IETF. Title : IP Authentication using Keyed MD5 Author(s) : P. Metzger, W. Simpson Filename : draft-ietf-ipsec-ah-md5-02.txt Pages : 4 Date : 03/23/1995 This document describes the use of keyed MD5 with the IP Authentication Header. 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-ipsec-ah-md5-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-md5-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) 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-ipsec-ah-md5-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: <19950323134830.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ah-md5-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ah-md5-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950323134830.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 27 06:56:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06543; Mon, 27 Mar 95 06:56:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06537; Mon, 27 Mar 95 06:56:07 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26744; Mon, 27 Mar 1995 06:48:16 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA14394; Mon, 27 Mar 95 06:48:08 PST To: ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net Subject: (IPng) fast DES information Date: Mon, 27 Mar 95 9:43:14 EST From: Ran Atkinson Message-Id: <9503270943.aa05098@bodhi.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In a posting to sci.crypt.research, Bruce Schneier indicates that VLSI's commercial DES chip (the 6868) has a 32 MHz clock and encrypts data at 256 MB/second. Bruce also reports that a DEC Alpha 4000/610 can encrypt DES at 154,000 8-byte encryptions per second. I mention this only in the context of earlier concerns about getting DES to encrypt at high speeds. This is not and must not be misconstrued as a product endorsement of any sort. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 27 08:03:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06565; Mon, 27 Mar 95 08:03:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06559; Mon, 27 Mar 95 08:03:48 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01954; Mon, 27 Mar 1995 07:55:58 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA26936; Mon, 27 Mar 95 07:55:58 PST Received: by rodan.UU.NET id QQyiwt24362; Mon, 27 Mar 1995 10:55:56 -0500 Message-Id: To: ipng@sunroof.Eng.Sun.COM Cc: mo@uunet.uu.net Subject: Re: (IPng) fast DES information In-Reply-To: Your message of "Mon, 27 Mar 1995 09:43:14 EST." <9503270943.aa05098@bodhi.nrl.navy.mil> Date: Mon, 27 Mar 1995 10:55:54 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM did you see the Diffe-Hellman chip that AT&T and VLSI have done? it generates a 1024 bit key internally and unaccessable, will give you the public key, will do DH exchanges to produce session keys, doesn't escrow, and can do DES as well. this might be the chip you mentioned. it's priced at $22 in quantity 10000. i dunno whether this includes tribute for Bidzos. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 27 08:35:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06577; Mon, 27 Mar 95 08:35:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06571; Mon, 27 Mar 95 08:35:41 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05208; Mon, 27 Mar 1995 08:27:50 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA04226; Mon, 27 Mar 95 08:27:49 PST Received: by rodan.UU.NET id QQyiwv29128; Mon, 27 Mar 1995 11:27:48 -0500 Date: Mon, 27 Mar 1995 11:27:48 -0500 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) oh well.... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM didn't mean to send the note about the diffe-hellman chip to ipng, but it is a *very* interesting development which many be of passing interest (!!!!) anyway. one very interesting question is whether the chip price includes a license from PKP to do the public key stuff. -mo Me? speak for UUNET?? i can barely speak for myself. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 27 13:53:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06803; Mon, 27 Mar 95 13:53:16 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06797; Mon, 27 Mar 95 13:53:09 PST Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id NAA23575; Mon, 27 Mar 1995 13:45:15 -0800 Received: by kandinsky.Eng.Sun.COM (5.x/SMI-SVR4) id AA05975; Mon, 27 Mar 1995 13:46:50 -0800 Date: Mon, 27 Mar 1995 13:46:50 -0800 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9503272146.AA05975@kandinsky.Eng.Sun.COM> To: conta@zk3.dec.com, ipng@sunroof Subject: Re: (IPng) a few IPv6 API document related comments: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > 3. On page 17 - 4.13, Name-to-Address Translation Functions. > > To provide more flexibility for writting applications that could use both > IPv6 and IPv4 addresses, it would be usefull to extend the role of the > second argument of the 'host2nameaddr' call from that of an 'input parameter' > to that of an 'input/output parameter'. > > The two cases when 'af=AF_INET' and 'af=AF_INET6' will continue to mean that > 'af' is an input parameter. The third case, when 'af' is specified but > it contains a value 'zero' would mean that 'af' is also an 'output parameter' > to be returned an AF_INET or AF_INET6 value. I think its important to note that the function that this proposed mechanism performs (lookuping either/both A and AAAA records in one call to hostname2addr) is provided by another mechanism which is specified in the document. I don't think that the approach you suggest would add any new functionallity; Instead, it would provide an alternative method to perform the same function. I think we need to consider whether we want to specify multiple mechanisms for the same function, or try to limit ourselves to one mechanism per function. Defining multiple ways to perform one function is one way that specifications can get overly complex. If we do decide that we want only one mechansm, then we have to choose between the two approaches. Unfortunately, this usually comes down to a matter of taste and style. Comparing the two approaches, some of the substantive difference I see are: - The approach you suggest requires that the application perform the hostname2addr() and socket() calls in a specific order: hostname2addr() first, then socket() second. The approach in the current draft of the API spec allows an application to perform these call in either order: socket() first, or hostname2addr() first. - The approach you suggest requires an application to be prepared to deal with two types of address data structures being returned by hostname2addr() -- in_addr or in_addr6. These two structures are different sizes. Using the approach in the current draft, an application need only be prepared to deal with one type of data structure being returned -- in_addr6. Other than that, the two approaches appear to be pretty much the same. I would suggest that, unless someone wishes to argue that the new mechanism provides some new functionally, we leave it out. What do other people think? Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 27 14:03:54 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06815; Mon, 27 Mar 95 14:03:54 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06809; Mon, 27 Mar 95 14:03:46 PST Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id NAA24262; Mon, 27 Mar 1995 13:55:54 -0800 Received: by kandinsky.Eng.Sun.COM (5.x/SMI-SVR4) id AA05984; Mon, 27 Mar 1995 13:57:30 -0800 Date: Mon, 27 Mar 1995 13:57:30 -0800 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9503272157.AA05984@kandinsky.Eng.Sun.COM> To: conta@zk3.dec.com, ipng@sunroof Subject: Re: (IPng) a few IPv6 API document related comments: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > 3. On page 17 - 4.13, Name-to-Address Translation Functions. > > To provide more flexibility for writting applications that could use both > IPv6 and IPv4 addresses, it would be usefull to extend the role of the > second argument of the 'host2nameaddr' call from that of an 'input parameter' > to that of an 'input/output parameter'. > > The two cases when 'af=AF_INET' and 'af=AF_INET6' will continue to mean that > 'af' is an input parameter. The third case, when 'af' is specified but > it contains a value 'zero' would mean that 'af' is also an 'output parameter' > to be returned an AF_INET or AF_INET6 value. Also, the API already has a place to carry the address type of the address returned by hostname2addr(). The "h_addrtype" field of the hostent struct carries this information. So, if we wanted to add the mechanism you suggest, we could do so without changing the "af" argument of hostname2addr() to an input/output parameter. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 27 14:36:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06869; Mon, 27 Mar 95 14:36:24 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06863; Mon, 27 Mar 95 14:36:16 PST Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id OAA27041; Mon, 27 Mar 1995 14:28:19 -0800 Received: by kandinsky.Eng.Sun.COM (5.x/SMI-SVR4) id AA06032; Mon, 27 Mar 1995 14:29:54 -0800 Date: Mon, 27 Mar 1995 14:29:54 -0800 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9503272229.AA06032@kandinsky.Eng.Sun.COM> To: ipng@sunroof, wanyen@hpindlm.cup.hp.com Subject: re: (IPng) comments on BSD API Spec Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Comments on "IPv6 BSD API Spec" > > I noticed that u_long is used to define sa_addr and sin6_flowlabel > in the "IPv6 BSD API Spec". In the ILP64 and LP64 models, a "u_long" type > is 64bit. To avoid size incosistency in various 64bit compiler models, > "char" or a word-size independent type should be used to declare > sa_addr and sin6_flowlabel in the following sections: > > > 4.2 IPv6 Address Data Structure > > > A new data structure to hold a single IPv6 address is defined in > > : > > > struct in_addr6 { > > u_long sa_addr[4]; /* ipv6 address */ > > ^^^^^^^^^^^^^^^^^^^^^ > > } > > > This data structure contains an array of four 32-bit elements, which > ^^^^^^^^^^^^^^^^^^^^ > > make up one 128-bit IPv6 address. A similar point about the in_addr6 structure definition was raised in private email by Dave Borman at Cray. You can't define an array of 32-bit elements on a machine that doesn't have an addressable 32-bit word. For this reason, I think we will have to change the definition of this structure to be: struct in_addr6 { u_char s6_addr[16]; /* IPv6 address */ } > Also, a u_int32 type can be used to declare sin6_flowlabel in the > sockaddr_in6 structre. Our use of u_long in the definition of the sockaddr_in6 structure was intended to be illustrative, not an absolute requirement. You can use whatever type yields a 32-bit value on your system. The problem is that there is no single pre-existing data type that is 32-bits in size on all platforms. We tried to explain in the spec that the system implementor is free to use whatever type definitions yeild the necessary sized structure elements. But I guess we should try to make this clearer. As you suggest, using a type like "u_int32" would get the point across. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 27 15:49:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06944; Mon, 27 Mar 95 15:49:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06938; Mon, 27 Mar 95 15:48:55 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05837; Mon, 27 Mar 1995 15:41:04 -0800 Received: from nic1.barrnet.net by Sun.COM (sun-barr.Sun.COM) id AA22002; Mon, 27 Mar 95 15:41:05 PST Received: from ipsilon.com by nic1.barrnet.net (8.6.10/BARRNET-RELAY.1) id PAA03745; Mon, 27 Mar 1995 15:41:04 -0800 Received: from [204.160.240.224] (acacia.ipsilon.COM) by ipsilon.com (4.1/SMI-4.1MDV1.0) id AA17241; Mon, 27 Mar 95 15:39:40 PST X-Sender: hinden@servo.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Mar 1995 15:39:21 -0800 To: "Thomas Narten" From: hinden@ipsilon.com (Bob Hinden) Subject: Re: (IPng) Last Call for IPng Addressing Architecture Document Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Thomas, At 3:56 PM 3/14/95, Thomas Narten wrote: >Overall, the document reads well. However, when I got to the region >address section, things get confusing really fast. Rather than make I agree this section needs work. The next version of the document will change "region addresses" to "anycast addresses". The new text will make this much clearer. The announcement of the new draft (following this message) will describe the change in more detail. >What exactly is an "anycast" address? The draft spec refers to them, >but never defines them or provides a reference. (The draft needs to be >changed to address this.) This will be defined in the new text. >>2.5 Region Addresses >> >>Region Addresses provide information abstraction for the purpose of >>network layer routing. A subgraph of an internet forms a "Region" with >>an identifier called a "Region-ID" if all the following conditions are >>satisfied. >> >> 1. Associated with each Region is a globally unique identifier called >> a Region-ID. Syntactically, a Region-ID is a 128-bit IPv6 unicast >> address. > >Clear enough, at first glance. However, is a critical point perhaps >*not* made? > >Specifically, is it (or is it not) the case that the addresses for all >nodes within a region (excluding border gateways) contain the >Region-ID number as an address prefix? If the answer is no, what is >the canonical example used for justification? Not in all cases. I think the new anycast text will make this clear. >minor nits: Fixed. Thanks, Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 27 15:51:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06961; Mon, 27 Mar 95 15:51:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06955; Mon, 27 Mar 95 15:51:22 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06034; Mon, 27 Mar 1995 15:43:31 -0800 Received: from nic1.barrnet.net by Sun.COM (sun-barr.Sun.COM) id AA22456; Mon, 27 Mar 95 15:43:31 PST Received: from ipsilon.com by nic1.barrnet.net (8.6.10/BARRNET-RELAY.1) id PAA03772; Mon, 27 Mar 1995 15:43:31 -0800 Received: from [204.160.240.224] (acacia.ipsilon.COM) by ipsilon.com (4.1/SMI-4.1MDV1.0) id AA17253; Mon, 27 Mar 95 15:42:07 PST X-Sender: hinden@servo.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Mar 1995 15:41:47 -0800 To: ipng@sunroof.Eng.Sun.COM From: hinden@ipsilon.com (Bob Hinden) Subject: Re: (IPng) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-addr-arch-00.txt Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, >There are too many forward and backward dependent references between >documents, which are likely to change in the future. NOSI is only one >of them. I agree. Many of the references were useful earlier on, but are no longer necessary. I will remove the ones which I think are not required. >I'm not fond of the new term "region". Too nebulous, invokes/conflicts >with older terms such as "Regional Provider". Is that the best we can >do? Isn't there a nice graph theory term for a set of nodes which are >fully-connected? The region section is being revised. After much discussion with the contributors of the "region" ideas the conclusion is that these are really "anycast" addresses. The text is being revised to define this. The announce of the new draft will describe the motivation for the change. >The Addressing Model section seems reasonable overall, but the words >provider and subscriber should be excised everywhere. I disagree and note this was discussed on the list. >All of these sections called "reserved" should be called "unassigned", >to match Postel's usual labelling. Good idea. I will leave the 0000 0000 prefix reserved and change the others to unassigned. I will also change the NSAP and IPX blocks to say "reserved for xxx". >The IPX allocation is much too big! These are only 6 bytes, and should >have a 2 byte prefix. I am talking to some people at Novell about how IPX in IPv6 addresses should be defined. My hope is that if this can be done well, it will make it easier for users to migrate their IPX machines to IPv6. Until this is settled, I will leave the prefix as is. >I like the new Neutral-Interconnect-Based reference (rather than >Geographic), but would really prefer to call it Exchange (to match the >term in current use), and don't think it needs any reservation in this >draft. I'll handle that in mine, thanks. > >If you are going to use "region", then you should stop using "subnet >prefix". Call it "region prefix", instead. > >Ditto for "subscriber prefix". > >Excise the entire "provider-based" section. It has nothing to do with >this document. And conceivably is different than Yakov's draft, >although I see that you've tried to fix that with registries. I think Steve Deering responded to this. >I agree with Brian that the NSAP section should be removed. This was discussed on the mailing list. >Instead of these sections, you should just have a nice paragraph under >the initial allocation map, stating that > > "Specific unicast allocation and routing strategies are outside > the scope of this document. Please refer to the appropriate > companion specifications." I think it is better to show what we know now. I think this document should reflect the other addressing docs which will be going to proposed standard at the same time. >I known it's silly of me to want some order and logic to the >presentation, but I would recommend that the next sections be in the >same order as they are in the allocation map: > - Unspecified > - Loopback > - IPv4 > ... > - Site-Local > - Multicast Good suggestion. I will make the change. >Please change All-Routers to be ::02, which matches IPv4. > >All-Hosts can be ::03, which is "unassigned" in IPv4. I will make this change. Thanks for the comments. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 27 15:52:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06973; Mon, 27 Mar 95 15:52:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06967; Mon, 27 Mar 95 15:52:25 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06172; Mon, 27 Mar 1995 15:44:34 -0800 Received: from nic1.barrnet.net by Sun.COM (sun-barr.Sun.COM) id AA22763; Mon, 27 Mar 95 15:44:35 PST Received: from ipsilon.com by nic1.barrnet.net (8.6.10/BARRNET-RELAY.1) id PAA03793; Mon, 27 Mar 1995 15:44:34 -0800 Received: from [204.160.240.224] (acacia.ipsilon.COM) by ipsilon.com (4.1/SMI-4.1MDV1.0) id AA17261; Mon, 27 Mar 95 15:43:09 PST X-Sender: hinden@servo.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Mar 1995 15:42:50 -0800 To: ipng@sunroof.Eng.Sun.COM From: hinden@ipsilon.com (Bob Hinden) Subject: (IPng) New IPv6 Address Architecture Draft Cc: hinden@ipsilon.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM A new IPng Addressing Architecture draft has been submitted to be an ID. It can also be found for anonymous ftp at: ftp.ipsilon.com as pub/ipng/draft-ietf-ipngwg-addr-arch-02.txt The version reflects the comments received during the working group last call. The biggest change was the replacement of the region addresses with anycast addresses. I think that "anycast" is a more general service than what was proposed by regions or clusters, provides a complementary service to unicast and multicast addresses, is easier to understand, and can be used to implement the routing concepts that were proposed with region addresses. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 27 18:18:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07364; Mon, 27 Mar 95 18:18:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07358; Mon, 27 Mar 95 18:18:07 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23232; Mon, 27 Mar 1995 18:10:16 -0800 Received: from servo.qualcomm.com by Sun.COM (sun-barr.Sun.COM) id AA23085; Mon, 27 Mar 95 18:10:18 PST Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id SAA00462; Mon, 27 Mar 1995 18:12:58 -0800 Date: Mon, 27 Mar 1995 18:12:58 -0800 From: Phil Karn Message-Id: <199503280212.SAA00462@servo.qualcomm.com> To: rja@bodhi.cs.nrl.navy.mil Cc: ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net In-Reply-To: <199503271448.AA17549@interlock.ans.net> (message from Ran Atkinson on Mon, 27 Mar 95 9:43:14 EST) Subject: (IPng) Re: fast DES information Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Bruce also reports that a DEC Alpha 4000/610 can encrypt DES >at 154,000 8-byte encryptions per second. Here's another data point. I recently upgraded the CPU in my home BSDI box from a 486DX2-66 to a 486DX4-100. That's a 486 with a 100 MHz internal clock and a 33 MHz external bus. In protected (32-bit) mode, the speed of my public domain DES code went up almost directly with the 1.5x increase in internal clock speed: 102,987 8-byte encryptions/sec vs 69,348/sec for the 486DX2-66. That's 6.59 megabits/sec vs 4.4 megabits/sec. My Pentium figures are all for real mode, so they aren't comparable. Phil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 27 19:08:26 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07404; Mon, 27 Mar 95 19:08:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07398; Mon, 27 Mar 95 19:08:18 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27234; Mon, 27 Mar 1995 19:00:27 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA29134; Mon, 27 Mar 95 19:00:28 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA20557; Mon, 27 Mar 95 22:00:27 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503280300.AA20557@wizard.gsfc.nasa.gov> Subject: Re: (IPng) Last Call for IPng Addressing Architecture Document To: ipng@sunroof.Eng.Sun.COM Date: Mon, 27 Mar 1995 22:00:26 -0500 (EST) In-Reply-To: from "Bob Hinden" at Mar 27, 95 03:39:21 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have the following comments on the IPv6 Addressing Architecture document, which overall looks very good: 1. I was also confused by Region Addresses, but since I see there's a new version that's supposed to clarify matters, I'll go check it out. 2. Section 2.2, paragraph 1.: The address 1080:0:0:8:800:200C:417A is missing one 16-bit piece. 3. Section 2.2, paragraph 2.: The phrase "In order to make writing address" should change "address" to either "addresses" or "an address". 4. Section 2.2, paragraph 3.: The address 0:0:0:0:0:0:0:13.1.68.3 has an extra :0. Likewise, the address 0:0:0:0:0:0:FFFF:129.144.52.38 has an extra :0. 5. This may actually be a comment for the unicast addressing architecture document. In that document, they refer to zero-homed routing domains and the addresses they should use. In the IPv6 Addressing Architecture document, it indicates such non-connected routing domains should use the Site Local Use Addresses for such purposes. The unicast addressing architecture document should probably be edited to also explicitly indicate the use of Site Local Use Addresses for zero-homed routing domains. 6. Section 2.4, 2nd paragraph: "Additional addresses types" should be changed to "Additional address types". 7. Section 2.4.1, 1st address format: I would change "m bits" to "80-n bits". 8. Same section, 2nd paragraph below the above: "Advertisement messages send by a router" should be changed to "sent by a router". 9. Section 2.6 on Multicast Addresses: Is there some reason there aren't assigned scopes for national and continental? And is scope F reserved for inter-planetary? I am from NASA after all. :-) 10. Regarding the last paragraph of Section 2.6 (before 2.6.1), is it really intended to not allow a multicast as the last entry in a source route, i.e. to disallow directed multicasts. It seems this might be useful at times. 11. Section 2.7, last part: Won't the Local Use prefixes also need to be predefined? 12. REFERENCES: Some of the references need to be updated since titles have changed. -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 27 21:08:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07469; Mon, 27 Mar 95 21:08:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07463; Mon, 27 Mar 95 21:08:52 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02744; Mon, 27 Mar 1995 21:01:00 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA10549; Mon, 27 Mar 95 21:01:01 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA20696; Tue, 28 Mar 95 00:01:00 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503280501.AA20696@wizard.gsfc.nasa.gov> Subject: Re: (IPng) New IPv6 DNS Draft To: ipng@sunroof.Eng.Sun.COM Date: Tue, 28 Mar 1995 00:00:59 -0500 (EST) In-Reply-To: from "Bob Hinden" at Mar 20, 95 04:52:42 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Was any thought given to decoupling the site portion of an IPv6 address from the exchange or provider portion of an IPv6 address? I am envisioning something like the following DNS setup: My_Site IN PREFIX 010-Registry_ID-Provider1_ID-Site_ID_for_Provider1 64 My_Site IN PREFIX 010-Registry_ID-Provider2_ID-Site_ID_for_Provider2 64 which would represent two different providers for My_Site, where the length of the Site Prefix for My_Site is 64 bits. Non-Internet-connected routing domains could use the Site Local Use prefix. Then a host foo at My_Site might have the following AAAA records: foo IN AAAA My_Site:Subnet1_ID-Interface1_ID foo IN AAAA My_Site:Subnet2_ID-Interface2_ID foo IN AAAA My_Site:Subnet3_ID-Interface3_ID which assumes that foo has 3 interfaces and one IPv6 address per interface for this example. Each address would be 64 bits long (128 - length of My_Site prefix which is 64 bits). These site-specific addresses would be invariant with a change of provider. Then, when someone queried the DNS for host foo's AAAA entries, instead of simply returning a set of 128-bit AAAA entries for host foo, it would return the set of 3 64-bit site-specific addresses for host foo, i.e. the Subnet_ID + Interface_ID (right justified in the smallest number of octets that will hold the address, in this case 8 octets). In an additional section, it would return the list of Site Prefixes for My_Site, in this case the 2 64-bit Site Prefixes representing Provider1 and Provider2 (left justified in the smallest number of octets that will hold the address, in this case 8 octets). Upon receiving the DNS reply, the requesting host would simply combine the AAAA and PREFIX parts to form the various full 128-bit IPv6 addresses for host foo (which would have 6 possible addresses in this example), or use the information in other meaningful ways, such as provider selection. This would not only significantly reduce the possible size of a DNS reply (3*8 + 2*8 = 40 octets versus 2*3*16 = 96 octets for this simple case), but should also be a great help in facilitating change of provider or exchange, and in supporting multi-homed routing domains. -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 27 22:50:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07615; Mon, 27 Mar 95 22:50:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07609; Mon, 27 Mar 95 22:50:12 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06592; Mon, 27 Mar 1995 22:42:20 -0800 Received: from nic1.barrnet.net by Sun.COM (sun-barr.Sun.COM) id AA18670; Mon, 27 Mar 95 22:42:23 PST Received: from ipsilon.com by nic1.barrnet.net (8.6.10/BARRNET-RELAY.1) id WAA07232; Mon, 27 Mar 1995 22:42:22 -0800 Received: from [140.174.164.133] (annex-p133.meer.net) by ipsilon.com (4.1/SMI-4.1MDV1.0) id AA29040; Mon, 27 Mar 95 22:40:56 PST X-Sender: hinden@servo.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Mar 1995 22:40:36 -0800 To: ipng@sunroof.Eng.Sun.COM From: hinden@ipsilon.com (Bob Hinden) Subject: Re: (IPng) Last Call for IPng Addressing Architecture Document Cc: hinden@ipsilon.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 10:00 PM 3/27/95, Bill Fink wrote: >I have the following comments on the IPv6 Addressing Architecture >document, which overall looks very good: Bill, Thanks for the comments. I will double check tomorrow, but I think most of these things you mention have been fixed in the draft which I announced earlier today. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 28 01:33:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07663; Tue, 28 Mar 95 01:33:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07657; Tue, 28 Mar 95 01:33:29 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13411; Tue, 28 Mar 1995 01:25:39 -0800 Received: from concorde.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA07710; Tue, 28 Mar 95 01:25:32 PST Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id LAA11781; Tue, 28 Mar 1995 11:19:57 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id LAA05909; Tue, 28 Mar 1995 11:19:57 +0200 Message-Id: <199503280919.LAA05909@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.Eng.Sun.COM Cc: wanyen@hpindlm.cup.hp.com Subject: Re: (IPng) comments on BSD API Spec In-Reply-To: Your message of Mon, 27 Mar 1995 14:29:54 -0800. <9503272229.AA06032@kandinsky.Eng.Sun.COM> Date: Tue, 28 Mar 1995 11:19:55 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In your previous mail you wrote: A similar point about the in_addr6 structure definition was raised in private email by Dave Borman at Cray. You can't define an array of 32-bit elements on a machine that doesn't have an addressable 32-bit word. => this issue should be resolved by the Cray C compiler but in fact I believe the "u_long s6_addr[4]" specs should be considered as an example because: - if you have bit types then u_long must be replaced by u_int32 or u_int32_t - on a word machine then it must be replaced by the suitable definition (on Crays by " s6_addr[2]") - on 64 bit architecture it can be replaced by a 64 bit type ("u_long s6_addr[2]" or better "u_int64_t s6_addr[2]" on alpha) if it is needed in order to force alignment constraints (but Jim Bound asked for the in_addr6 structure in order to get best (ie on 64 bits) alignment on alphas). I propose to replace the specs by a set of constraints: - IPv6 address is in a "in_addr6" structure with a 16 byte length. - this structure can require by definition an up to 64 bit alignment. - elements of this structure are unsigned integers with the s6_addr name and should have a 32 bit length if possible (the idea is to map s6_addr[3] with the IPv6 s_addr). In fact only kernel and DNS resolver library do direct operations on s6_addr elements, for other applications an opaque 16 byte type seems to be enough (any counter example ?). Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 28 01:41:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07675; Tue, 28 Mar 95 01:41:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07669; Tue, 28 Mar 95 01:41:19 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13644; Tue, 28 Mar 1995 01:33:29 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA08233; Tue, 28 Mar 95 01:33:22 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 28 Mar 95 18:31:30 +0900 From: Masataka Ohta Message-Id: <9503280931.AA26956@necom830.cc.titech.ac.jp> Subject: Re: (IPng) New IPv6 DNS Draft To: ipng@sunroof.Eng.Sun.COM Date: Tue, 28 Mar 95 18:31:29 JST In-Reply-To: <9503280501.AA20696@wizard.gsfc.nasa.gov>; from "Bill Fink" at Mar 28, 95 12:00 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Was any thought given to decoupling the site portion of an IPv6 address > from the exchange or provider portion of an IPv6 address? > > I am envisioning something like the following DNS setup: > > My_Site IN PREFIX 010-Registry_ID-Provider1_ID-Site_ID_for_Provider1 64 > My_Site IN PREFIX 010-Registry_ID-Provider2_ID-Site_ID_for_Provider2 64 > > which would represent two different providers for My_Site, where the length > of the Site Prefix for My_Site is 64 bits. Non-Internet-connected routing > domains could use the Site Local Use prefix. So, the point is that, we have to change only the single node "My_Site" for provider change. And, that's the only way to go to enjoy provider independence without relying on dynamically updatable DNS, which does not work for provider changes. > Then a host foo at My_Site might have the following AAAA records: > > foo IN AAAA My_Site:Subnet1_ID-Interface1_ID > foo IN AAAA My_Site:Subnet2_ID-Interface2_ID > foo IN AAAA My_Site:Subnet3_ID-Interface3_ID As an interface is distinguished by the subnet ID, it should rather be: foo IN AAAA My_Site:Subnet1_ID-Host_ID foo IN AAAA My_Site:Subnet2_ID-Host_ID foo IN AAAA My_Site:Subnet3_ID-Host_ID while a single host may have multiple IDs. foo IN AAAA My_Site:Subnet1_ID-Host_ID1 foo IN AAAA My_Site:Subnet2_ID-Host_ID1 foo IN AAAA My_Site:Subnet3_ID-Host_ID1 foo IN AAAA My_Site:Subnet1_ID-Host_ID2 foo IN AAAA My_Site:Subnet2_ID-Host_ID2 foo IN AAAA My_Site:Subnet3_ID-Host_ID2 foo IN AAAA My_Site:Subnet1_ID-Host_ID3 foo IN AAAA My_Site:Subnet2_ID-Host_ID3 foo IN AAAA My_Site:Subnet3_ID-Host_ID3 Moreover, as colon notation is not so compatible with general DNS syntax to connect two different types of an integer and a domain name, it would better be foo IN AAAA My_Site Subnet1_ID-Host_ID foo IN AAAA My_Site Subnet2_ID-Host_ID foo IN AAAA My_Site Subnet3_ID-Host_ID > These site-specific addresses would > be invariant with a change of provider. Of course. Then, I think we don't have to specify the length of PREFIX. That is, My_Site IN PREFIX Provider1_ID-Site_ID_for_Provider1 > Then, when someone queried the DNS for host foo's AAAA entries, instead > of simply returning a set of 128-bit AAAA entries for host foo, it would > return the set of 3 64-bit site-specific addresses for host foo, i.e. the > Subnet_ID + Interface_ID (right justified in the smallest number of octets > that will hold the address, in this case 8 octets). > > In an additional section, it would return the list of Site Prefixes for > My_Site, in this case the 2 64-bit Site Prefixes representing Provider1 > and Provider2 (left justified in the smallest number of octets that will > hold the address, in this case 8 octets). Note also that, both AAAA and PREFIX should be provided for glue referral for name servers. > This would not only significantly reduce the possible size of a DNS > reply (3*8 + 2*8 = 40 octets versus 2*3*16 = 96 octets for this simple > case), A problem is that "root.cache" will be a little more longer, which easily makes referral by root servers longer than 512 byte. But, if minimal MTU is extended to 1500 (or more), it does not matter. > but should also be a great help in facilitating change of provider > or exchange, and in supporting multi-homed routing domains. As for multi-homing, it is now easy for site administrators to control the preference of providers, I think. That is, My_Site IN PREFIX Provider1_ID-Site_ID_for_Provider1 preference might be doable. The issue, of course, is that it is difficult to have proper metric of preferences meaningful all over the Internet. But, it is at least as useful as MX preferences. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 28 01:56:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07688; Tue, 28 Mar 95 01:56:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07682; Tue, 28 Mar 95 01:56:15 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14106; Tue, 28 Mar 1995 01:48:25 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA09338; Tue, 28 Mar 95 01:48:24 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 28 Mar 95 18:46:47 +0859 From: Masataka Ohta Message-Id: <9503280947.AA27023@necom830.cc.titech.ac.jp> Subject: Re: (IPng) revised Flow ID management draft To: ipng@sunroof.Eng.Sun.COM Date: Tue, 28 Mar 95 18:46:45 JST Cc: end2end-interest@isi.edu In-Reply-To: <199503160057.QAA16758@aland.bbn.com>; from "Craig Partridge" at Mar 15, 95 4:57 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Hi folks: > > Last fall I sent around a draft of this memo and got some comments back. > About 6 weeks ago, Steve Deering asked me if I could revise the draft -- I > finally got time and here it is. Comments welcome. I forgot to mention one thing. > There are > ways to alleviate this problem, such as managing the Flow ID cache as > an LRU cache, in which infrequently used Flow IDs get discarded (and > then recovered later). It is not clear, however, whether this will > cause cache thrashing. It's clear. LRU is the worst algorithm for periodic events like flow ID updates, where the occurence of an event is an assurance that the same event WON'T occur until the update period will pass, at which time, LRU cache entry will be cleared. LRU is useful for bursty events. The solution is to avoid treeworking and flow consentration. Have a densely meshed network with finely balanced traffic pattern. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 28 03:42:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07815; Tue, 28 Mar 95 03:42:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07809; Tue, 28 Mar 95 03:41:56 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17446; Tue, 28 Mar 1995 03:34:05 -0800 Received: from mail.lth.se (nic.lth.se) by Sun.COM (sun-barr.Sun.COM) id AA19988; Tue, 28 Mar 95 03:34:04 PST Received: from maths.lth.se by mail.lth.se with smtp (Smail3.1.28.1 #2) id m0rtZX4-000MTyC; Tue, 28 Mar 95 13:33 MET DST Received: from maths-1.maths.lth.se (tyche-4) by maths.lth.se (4.1/MATHS BL-2.4s); Tue, 28 Mar 95 13:35:11 +0200 (MET) From: Bengt Larsson Message-Id: <9503281135.AA03884@maths.lth.se> Date: Tue, 28 Mar 95 13:35:27 +0200 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: fast DES information Cc: bengtl@maths.lth.se Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Here's another data point. I recently upgraded the CPU in my home BSDI >box from a 486DX2-66 to a 486DX4-100. That's a 486 with a 100 MHz >internal clock and a 33 MHz external bus. In protected (32-bit) mode, >the speed of my public domain DES code went up almost directly with >the 1.5x increase in internal clock speed: 102,987 8-byte >encryptions/sec vs 69,348/sec for the 486DX2-66. Could you point me to an up-to-date version of this code? I've been looking with archie and I've found several versions but they seem different. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 28 04:00:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07828; Tue, 28 Mar 95 04:00:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07822; Tue, 28 Mar 95 04:00:07 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18404; Tue, 28 Mar 1995 03:52:16 -0800 Received: from mail.lth.se (nic.lth.se) by Sun.COM (sun-barr.Sun.COM) id AA21068; Tue, 28 Mar 95 03:52:07 PST Received: from maths.lth.se by mail.lth.se with smtp (Smail3.1.28.1 #2) id m0rtZoa-000MTeC; Tue, 28 Mar 95 13:52 MET DST Received: from gauss.maths.lth.se by maths.lth.se (4.1/MATHS BL-2.4s); Tue, 28 Mar 95 13:53:16 +0200 (MET) From: Bengt Larsson Message-Id: <9503281153.AA03921@maths.lth.se> Date: Tue, 28 Mar 1995 13:52:16 +0200 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: fast DES information Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Phil Karn: >>In protected (32-bit) mode, >>the speed of my public domain DES code went up almost directly with >>the 1.5x increase in internal clock speed: 102,987 8-byte >>encryptions/sec vs 69,348/sec for the 486DX2-66. Me: >Could you point me to an up-to-date version of this code? >I've been looking with archie and I've found several versions >but they seem different. Sorry, it was meant as personal mail ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 28 09:24:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07895; Tue, 28 Mar 95 09:24:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07597; Mon, 27 Mar 95 22:06:45 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04876; Mon, 27 Mar 1995 21:58:52 -0800 Received: from dmssyd.syd.dms.CSIRO.AU by Sun.COM (sun-barr.Sun.COM) id AA14828; Mon, 27 Mar 95 21:58:51 PST Received: from drugs.syd.dms.CSIRO.AU by dmssyd.syd.dms.CSIRO.AU (4.1/5.17) id AA07550; Tue, 28 Mar 95 15:58:37 EST (from Mark.Andrews@dms.csiro.au (Mark Andrews)) Message-Id: <9503280558.AA07550@dmssyd.syd.dms.CSIRO.AU> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) New IPv6 DNS Draft In-Reply-To: Your message of "Tue, 28 Mar 1995 00:00:59 EST." <9503280501.AA20696@wizard.gsfc.nasa.gov> Date: Tue, 28 Mar 1995 15:58:30 +1000 From: Mark Andrews Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Was any thought given to decoupling the site portion of an IPv6 address > from the exchange or provider portion of an IPv6 address? > > I am envisioning something like the following DNS setup: > > My_Site IN PREFIX 010-Registry_ID-Provider1_ID-Site_ID_for_Provid > er1 64 > My_Site IN PREFIX 010-Registry_ID-Provider2_ID-Site_ID_for_Provid > er2 64 > > which would represent two different providers for My_Site, where the length > of the Site Prefix for My_Site is 64 bits. Non-Internet-connected routing > domains could use the Site Local Use prefix. > > Then a host foo at My_Site might have the following AAAA records: > > foo IN AAAA My_Site:Subnet1_ID-Interface1_ID > foo IN AAAA My_Site:Subnet2_ID-Interface2_ID > foo IN AAAA My_Site:Subnet3_ID-Interface3_ID > > which assumes that foo has 3 interfaces and one IPv6 address per interface > for this example. Each address would be 64 bits long (128 - length of > My_Site prefix which is 64 bits). These site-specific addresses would > be invariant with a change of provider. > > Then, when someone queried the DNS for host foo's AAAA entries, instead > of simply returning a set of 128-bit AAAA entries for host foo, it would > return the set of 3 64-bit site-specific addresses for host foo, i.e. the > Subnet_ID + Interface_ID (right justified in the smallest number of octets > that will hold the address, in this case 8 octets). > > In an additional section, it would return the list of Site Prefixes for > My_Site, in this case the 2 64-bit Site Prefixes representing Provider1 > and Provider2 (left justified in the smallest number of octets that will > hold the address, in this case 8 octets). > > Upon receiving the DNS reply, the requesting host would simply combine > the AAAA and PREFIX parts to form the various full 128-bit IPv6 addresses > for host foo (which would have 6 possible addresses in this example), or > use the information in other meaningful ways, such as provider selection. > > This would not only significantly reduce the possible size of a DNS > reply (3*8 + 2*8 = 40 octets versus 2*3*16 = 96 octets for this simple > case), but should also be a great help in facilitating change of provider > or exchange, and in supporting multi-homed routing domains. > > -Bill The problem with this is that currently there is not FIXED boundary between provider and site net. Provider 1 may use 64 bit where provider 2 may use 72 bits. For this to work there had to be an agreed COMMON boundary for all providers delineating 010-Registry_ID-Provider2_ID and Site_ID_for_Provider. This is the start of one thought I had on this. Provider Independent Provider Based Addressing ---------------------------------------------- The purpose of the memo is to describe how to provided Provider Independent addresses through the local provider. The following address pattern is reserved for provider independent addresses within the providers' address space. |010| 60 bit route heirachy | 0 | net | subnet | interface | net is 48 to 60 bits in length Bits 65 through 96 are allocated to the provider in its roll as a network registry. These for the provider independent prefix (PIP). 4000:0000:0000:0000:PPPP:PPPP:XXXX:XXXX Each provider is allocated one or more PIPs, They intern hand out networks at the requested size rounded up to the next power of two. The smallest network will contain 2^4 addresses, the largest 2^24 addresses. An attempt will be made to keep the next three blocks of equal size free from allocation as this will permit request to enlarge the net without renumbering. e.g. Provider-1 prefix 4000:2345:8765:2334:: Provider-2 prefix 4000:2345:9567:2634:: Provider 1 is allocated 4000::1ae3:2378:0:0 and you have requested a net with 2^12 addresses 4000::1ae3:2378:3418:4000 - 4000::1ae3:2378:3418:4fff is allocated to you and 4000::1ae3:2378:3418:5000 - 4000::1ae3:2378:3418:7fff is reserved for growth. HOST 4000::1ae3:2378:3418:401e when accessed via Provider-1 would be 4000:2345:8765:2334:1ae3:2378:3418:401e and by Provider-2 4000:2345:9567:2634:1ae3:2378:3418:401e. Mark -- Mark Andrews, CSIRO Div Maths & Stats Locked Bag 17, North Ryde, NSW 2113, Australia. PHONE: +61 2 325 3148 INTERNET: marka@syd.dms.csiro.au UUCP: ....!uunet!syd.dms.csiro.au!marka ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 28 09:26:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07907; Tue, 28 Mar 95 09:26:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07858; Tue, 28 Mar 95 07:10:25 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00035; Tue, 28 Mar 1995 07:02:33 -0800 Received: from timbuk.cray.com by Sun.COM (sun-barr.Sun.COM) id AA11596; Tue, 28 Mar 95 07:02:33 PST Received: from frenzy.cray.com (frenzy.cray.com [128.162.84.21]) by timbuk.cray.com (8.6.9/CRI-fence-1.4) with SMTP id JAA02639 for ; Tue, 28 Mar 1995 09:01:22 -0600 Received: by frenzy.cray.com id AA04047; 4.1/CRI-5.6; Tue, 28 Mar 95 09:05:26 CST Date: Tue, 28 Mar 95 09:05:26 CST From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9503281505.AA04047@frenzy.cray.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) comments on BSD API Spec Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Francis.Dupont@inria.fr writes: > > In your previous mail you wrote: > > A similar point about the in_addr6 structure definition was raised in > private email by Dave Borman at Cray. You can't define an array of > 32-bit elements on a machine that doesn't have an addressable 32-bit > word. > > => this issue should be resolved by the Cray C compiler but Bzzzt. Wrong answer. The only advantage in defining a 32-bit thingy that is addressable on a Cray computer is that you'd wind up with very slow performing code. Characters are dealt with by the C compiler by having a "software" defined character pointer that contains a word pointer and an offset into that word. All access of characters turns into a series of shifts and masks. Needless to say, character oriented code doesn't perform real well on a Cray... To have an addressable 32-bit thingy would require the same shift/mask game by the compiler. But this is all neither here nor there, the Cray C compiler does not support addressable 32-bit thingys. > in fact I believe the "u_long s6_addr[4]" specs should be > considered as an example because: > - if you have bit types then u_long must be replaced by > u_int32 or u_int32_t > - on a word machine then it must be replaced by the suitable > definition (on Crays by " s6_addr[2]") > - on 64 bit architecture it can be replaced by a 64 bit type > ("u_long s6_addr[2]" or better "u_int64_t s6_addr[2]" on alpha) > if it is needed in order to force alignment constraints (but Jim Bound > asked for the in_addr6 structure in order to get best (ie on 64 bits) > alignment on alphas). Yeah, right. So we have something that is declared in an API that the programmer cannot depend on. Gee, maybe it's an array of 4 32-bit elements, maybe it's an array of 2 64-bit elements. That's not how you encourage the writing of portable code. If you define it, people will use it. For the sockaddr_in6 I don't care that my ints/longs/shorts are all 64 bits. The sockaddr_in6 is a structure that is internal to the machine. But the in_addr6 is defining the size of an IPv6 address, which must be 128 bits long. So the in_addr6 had better be 128 bits long. > I propose to replace the specs by a set of constraints: > - IPv6 address is in a "in_addr6" structure with a 16 byte length. > - this structure can require by definition an up to 64 bit alignment. > - elements of this structure are unsigned integers with the s6_addr name > and should have a 32 bit length if possible (the idea is to map > s6_addr[3] with the IPv6 s_addr). > In fact only kernel and DNS resolver library do direct operations > on s6_addr elements, for other applications an opaque 16 byte type > seems to be enough (any counter example ?). There is nothing wrong with having the in_addr6 be a union rather than a structure, and allowing implementations to define their own best definition, in addition to the 16-byte character array. That allows people to write portable code using the character array, and allows people to access the elements in a method that is fast for the particular machine that is being used if they don't care about portablity. -David Borman, dab@cray.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 28 14:07:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08317; Tue, 28 Mar 95 14:07:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08311; Tue, 28 Mar 95 14:07:03 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21823; Tue, 28 Mar 1995 13:59:10 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA11342; Tue, 28 Mar 95 13:57:19 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA21936; Tue, 28 Mar 95 16:55:45 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503282155.AA21936@wizard.gsfc.nasa.gov> Subject: Re: (IPng) New IPv6 DNS Draft To: ipng@sunroof.Eng.Sun.COM Date: Tue, 28 Mar 1995 16:55:45 -0500 (EST) In-Reply-To: <9503280931.AA26956@necom830.cc.titech.ac.jp> from "Masataka Ohta" at Mar 28, 95 06:31:29 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > Was any thought given to decoupling the site portion of an IPv6 address > > from the exchange or provider portion of an IPv6 address? > > > > I am envisioning something like the following DNS setup: > > > > My_Site IN PREFIX 010-Registry_ID-Provider1_ID-Site_ID_for_Provider1 64 > > My_Site IN PREFIX 010-Registry_ID-Provider2_ID-Site_ID_for_Provider2 64 > > > > which would represent two different providers for My_Site, where the length > > of the Site Prefix for My_Site is 64 bits. Non-Internet-connected routing > > domains could use the Site Local Use prefix. > > So, the point is that, we have to change only the single node "My_Site" > for provider change. Exactly. > And, that's the only way to go to enjoy provider independence without > relying on dynamically updatable DNS, which does not work for > provider changes. I wouldn't say it's the only way, but it's one fairly simple way, and should be easy to implement. > > Then a host foo at My_Site might have the following AAAA records: > > > > foo IN AAAA My_Site:Subnet1_ID-Interface1_ID > > foo IN AAAA My_Site:Subnet2_ID-Interface2_ID > > foo IN AAAA My_Site:Subnet3_ID-Interface3_ID > > As an interface is distinguished by the subnet ID, it should rather be: > > foo IN AAAA My_Site:Subnet1_ID-Host_ID > foo IN AAAA My_Site:Subnet2_ID-Host_ID > foo IN AAAA My_Site:Subnet3_ID-Host_ID > > while a single host may have multiple IDs. > > foo IN AAAA My_Site:Subnet1_ID-Host_ID1 > foo IN AAAA My_Site:Subnet2_ID-Host_ID1 > foo IN AAAA My_Site:Subnet3_ID-Host_ID1 > foo IN AAAA My_Site:Subnet1_ID-Host_ID2 > foo IN AAAA My_Site:Subnet2_ID-Host_ID2 > foo IN AAAA My_Site:Subnet3_ID-Host_ID2 > foo IN AAAA My_Site:Subnet1_ID-Host_ID3 > foo IN AAAA My_Site:Subnet2_ID-Host_ID3 > foo IN AAAA My_Site:Subnet3_ID-Host_ID3 I was using the terminology from the IPv6 Addressing Architecture spec. The Interface ID may happen to be the same for all the subnets (in which case it might be thought of as a Host ID), but in general the Interface IDs may all be different. I also indicated that a host may have multiple IPv6 addresses per interface, but to simplify the discussion, my example foo case assumed there was only one IPv6 address per interface. > Moreover, as colon notation is not so compatible with general DNS > syntax to connect two different types of an integer and a domain name, > it would better be > > foo IN AAAA My_Site Subnet1_ID-Host_ID > foo IN AAAA My_Site Subnet2_ID-Host_ID > foo IN AAAA My_Site Subnet3_ID-Host_ID Yes, the space may be a better choice than the colon to represent this in a DNS zone file. That's a detail to be worked out. > > These site-specific addresses would > > be invariant with a change of provider. > > Of course. > > Then, I think we don't have to specify the length of PREFIX. > > That is, > > My_Site IN PREFIX Provider1_ID-Site_ID_for_Provider1 Yes, you need to specify the length of PREFIX since they may be different arbitrary values for each site, i.e. one site may have a 64 bit Site Prefix, another site a 72 bit Site Prefix, a third site a 68 bit Site Prefix, etc. > > Then, when someone queried the DNS for host foo's AAAA entries, instead > > of simply returning a set of 128-bit AAAA entries for host foo, it would > > return the set of 3 64-bit site-specific addresses for host foo, i.e. the > > Subnet_ID + Interface_ID (right justified in the smallest number of octets > > that will hold the address, in this case 8 octets). > > > > In an additional section, it would return the list of Site Prefixes for > > My_Site, in this case the 2 64-bit Site Prefixes representing Provider1 > > and Provider2 (left justified in the smallest number of octets that will > > hold the address, in this case 8 octets). > > Note also that, both AAAA and PREFIX should be provided for glue > referral for name servers. Yes, anywhere AAAA records would be returned should also return the associated PREFIX records, unless the AAAA records specified full 128-bit IPv6 addresses. > > This would not only significantly reduce the possible size of a DNS > > reply (3*8 + 2*8 = 40 octets versus 2*3*16 = 96 octets for this simple > > case), > > A problem is that "root.cache" will be a little more longer, > which easily makes referral by root servers longer than 512 byte. I didn't fully understand this. Even for the case of a node with only a single provider and a single site-specific address on a single interface, the increase in length of the DNS reply caused by decoupling the Site Prefix from the site-specific address should not be significant. And in the worst case, the cache entry for a root name server could simply use a full 128-bit AAAA entry, which doesn't require any associated PREFIX entries (this is probably what would be done as normal practice anyway). > But, if minimal MTU is extended to 1500 (or more), it does not matter. > > > but should also be a great help in facilitating change of provider > > or exchange, and in supporting multi-homed routing domains. > > As for multi-homing, it is now easy for site administrators to control > the preference of providers, I think. > > That is, > > My_Site IN PREFIX Provider1_ID-Site_ID_for_Provider1 preference > > might be doable. The issue, of course, is that it is difficult to have > proper metric of preferences meaningful all over the Internet. > But, it is at least as useful as MX preferences. I hadn't considered that but it might be a useful addition to allow one to specify a site's preference for providers. > Masataka Ohta -Thanks -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 28 17:03:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08590; Tue, 28 Mar 95 17:03:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08584; Tue, 28 Mar 95 17:03:08 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14866; Tue, 28 Mar 1995 16:55:14 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA18245; Tue, 28 Mar 95 16:55:10 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 29 Mar 95 09:53:37 +0900 From: Masataka Ohta Message-Id: <9503290053.AA00415@necom830.cc.titech.ac.jp> Subject: Re: (IPng) New IPv6 DNS Draft To: ipng@sunroof.Eng.Sun.COM Date: Wed, 29 Mar 95 9:53:35 JST In-Reply-To: <9503282155.AA21936@wizard.gsfc.nasa.gov>; from "Bill Fink" at Mar 28, 95 4:55 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I was using the terminology from the IPv6 Addressing Architecture spec. As the draft ignore the current consensus that host part must be much larger than 48 bits, I ignore the draft. > The Interface ID may happen to be the same for all the subnets (in which > case it might be thought of as a Host ID), but in general the Interface IDs > may all be different. The draft is broken here also, as it say nothing about the uniqueness scope of the ID and seems to be using different scopes at different locations. > I also indicated that a host may have multiple IPv6 > addresses per interface, but to simplify the discussion, my example foo > case assumed there was only one IPv6 address per interface. An IPv6 address, with routing PREFIX, of course, globally identify an interface, which is the IPv6 addressing model. > > That is, > > > > My_Site IN PREFIX Provider1_ID-Site_ID_for_Provider1 > > Yes, you need to specify the length of PREFIX since they may be different > arbitrary values for each site, i.e. one site may have a 64 bit Site Prefix, > another site a 72 bit Site Prefix, a third site a 68 bit Site Prefix, etc. Why do you think a subscriber must have such variable length Site Prefix? For provider independence, all the providers should be forced to offer the same size of site prefixes. For the enforcement, having a single prefix length is the easest way to go. Forcing providers offer the same set of variable length prefixes is difficult and not so efficient. And, why do you think a provider can offer such variable length Site Prefix? As host identification for 10^12 (or 10^15) hosts needs more than 48 bits, most certainly 64 bits, and we also need some bits for intra-site routing, perhaps 16 bits, we can't afford the luxuary of, committee designed, variable length compromises. So, I can see no reason to make it variable length. > > A problem is that "root.cache" will be a little more longer, > > which easily makes referral by root servers longer than 512 byte. > > I didn't fully understand this. Today, the answer to a query of root name servers is almost as long as 512 bytes. > And in the worst > case, the cache entry for a root name server could simply use a full 128-bit > AAAA entry, which doesn't require any associated PREFIX entries That's too dirty, at least, I think. > (this is > probably what would be done as normal practice anyway). No, users should be forced to have provider independence so that they won't be fooled by malicious providers. > > That is, > > > > My_Site IN PREFIX Provider1_ID-Site_ID_for_Provider1 preference > > > > might be doable. The issue, of course, is that it is difficult to have > > proper metric of preferences meaningful all over the Internet. > > But, it is at least as useful as MX preferences. > > I hadn't considered that but it might be a useful addition to allow one > to specify a site's preference for providers. Of course, different hosts in a site may point to My_site1 and My_site2 depending on the hosts' preference of multiple policies of the site. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 28 17:58:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08613; Tue, 28 Mar 95 17:58:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08607; Tue, 28 Mar 95 17:58:37 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21327; Tue, 28 Mar 1995 17:50:45 -0800 Received: from wizard.gsfc.nasa.gov by Sun.COM (sun-barr.Sun.COM) id AA27969; Tue, 28 Mar 95 17:50:46 PST Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA22400; Tue, 28 Mar 95 20:50:44 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9503290150.AA22400@wizard.gsfc.nasa.gov> Subject: Re: (IPng) New IPv6 DNS Draft To: ipng@sunroof.Eng.Sun.COM Date: Tue, 28 Mar 1995 20:50:44 -0500 (EST) In-Reply-To: <9503280558.AA07550@dmssyd.syd.dms.CSIRO.AU> from "Mark Andrews" at Mar 28, 95 03:58:30 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The problem with this is that currently there is not FIXED > boundary between provider and site net. > > Provider 1 may use 64 bit where provider 2 may use 72 bits. For a given site, it will have a certain size address space, say n bits. Thus, each provider for that site will have to allocate a Site Prefix of 128-n bits. I guess it's theoretically possible for a provider to allocate more than is necessary for the site, but it doesn't seem to make a whole lot of sense to me. If you really wanted to do this, you could define the following PREFIX entries: My_Site IN PREFIX 010-Registry_ID-Provider1_ID-Site_ID_for_Provider1 64 My_Site IN PREFIX 010-Registry_ID-Provider2_ID-Site_ID_for_Provider2 72 Then foo could be defined as before: foo IN AAAA My_Site:Subnet1_ID-Interface1_ID foo IN AAAA My_Site:Subnet2_ID-Interface2_ID foo IN AAAA My_Site:Subnet3_ID-Interface3_ID The difference would be that the site-specific addresses for foo (Subnet ID + Interface ID) would be 56 bits in this case, i.e. the minimum of 128-64 (64 is the bit length of My_Site's Site Prefix from Provider1) and 128-72 (72 is the bit length of My_Site's Site Prefix from Provider2), and the two PREFIX entries returned with the AAAA entries for foo would be different lengths (64 bits for Provider1 and 72 bits for Provider2). > For this to work there had to be an agreed COMMON boundary for > all providers delineating 010-Registry_ID-Provider2_ID and > Site_ID_for_Provider. You don't have to have a COMMON boundary for all providers for all sites, but it would make sense in most cases to have a common boundary for all providers for a given site, which will have a specified allocation of the IPv6 address space. > Mark -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 28 19:39:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08665; Tue, 28 Mar 95 19:39:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08652; Tue, 28 Mar 95 19:38:48 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29470; Tue, 28 Mar 1995 19:30:53 -0800 Received: from by Sun.COM (sun-barr.Sun.COM) id AB12567; Tue, 28 Mar 95 19:30:55 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05731; 28 Mar 95 10:52 EST 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 Subject: (IPng) I-D ACTION:draft-ietf-ipngwg-unicast-addr-loc-01.txt Date: Tue, 28 Mar 95 10:52:16 -0500 Message-Id: <9503281052.aa05731@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart Note: This announcement is being re-sent with a new filename. 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 : An Architecture for IPv6 Unicast Address Allocation Author(s) : Y. Rekhter, T. Li Filename : draft-ietf-ipngwg-unicast-addr-loc-01.txt Pages : 25 Date : 03/24/1995 This document provides an architecture for allocating IPv6 unicast addresses in the Internet. This document does not go into the details of an addressing plan. 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-unicast-addr-loc-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-unicast-addr-loc-01.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) 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-unicast-addr-loc-01.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: <19950327150655.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-unicast-addr-loc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-unicast-addr-loc-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950327150655.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 28 19:39:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08666; Tue, 28 Mar 95 19:39:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08653; Tue, 28 Mar 95 19:38:50 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29482; Tue, 28 Mar 1995 19:30:56 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA12590; Tue, 28 Mar 95 19:30:57 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05747; 28 Mar 95 10:52 EST 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 Subject: (IPng) I-D ACTION:draft-ietf-ipngwg-unicast-addr-fmt-01.txt Date: Tue, 28 Mar 95 10:52:19 -0500 Message-Id: <9503281052.aa05747@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart Note: This announcement is being re-sent with a new filename. 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 : An IPv6 Global Unicast Address Format Author(s) : Y. Rekhter, P. Lothberg Filename : draft-ietf-ipngwg-unicast-addr-fmt-01.txt Pages : 10 Date : 03/24/1995 This document defines an IPv6 global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 address allocation architecture [1], and is intended to facilitate scalable Internet routing. The format defined in this document doesn't preclude the use of other address formats. 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-unicast-addr-fmt-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-unicast-addr-fmt-01.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) 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-unicast-addr-fmt-01.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: <19950327151610.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-unicast-addr-fmt-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-unicast-addr-fmt-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950327151610.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 28 19:39:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08664; Tue, 28 Mar 95 19:39:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08646; Tue, 28 Mar 95 19:38:44 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29459; Tue, 28 Mar 1995 19:30:50 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA12567; Tue, 28 Mar 95 19:30:50 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05717; 28 Mar 95 10:52 EST 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 Subject: (IPng) I-D ACTION:draft-ietf-ipngwg-addr-arch-00.txt Date: Tue, 28 Mar 95 10:52:12 -0500 Message-Id: <9503281052.aa05717@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart Note: This announcement is being re-sent with a new filename. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Addressing Architecture Author(s) : R. Hinden Filename : draft-ietf-ipngwg-addr-arch-00.txt Pages : 18 Date : 03/24/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 document editor would like to acknowledge the contributions of Paul Francis, Steve Deering, Jim Bound, Brian Carpenter, Bob Gilligan, Christian Huitema, Greg Minshall, Erik Nordmark, Bill Simpson, and Sue Thomson. Special mention is also given to Yakov Rekhtor, Tony Li, Deborah Estrin, and Peter Ford for the current definition of region addresses. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addr-arch-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-addr-arch-00.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) 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-00.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: <19950327145003.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950327145003.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 28 22:15:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08854; Tue, 28 Mar 95 22:15:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08848; Tue, 28 Mar 95 22:14:58 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06490; Tue, 28 Mar 1995 22:07:03 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA27898; Tue, 28 Mar 95 22:07:04 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA17117; Wed, 29 Mar 1995 08:06:51 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA29255; Wed, 29 Mar 1995 08:06:49 +0200 Message-Id: <9503290606.AA29255@dxcoms.cern.ch> Subject: Re: (IPng) draft-simpson-exchanges-00.txt To: ipng@sunroof.Eng.Sun.COM Date: Wed, 29 Mar 1995 08:06:49 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <4361.Bill.Simpson@um.cc.umich.edu> from "William Allen Simpson" at Mar 24, 95 06:31:52 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, > > > From: "Brian Carpenter CERN-CN" > > I must be slowing down, beacuse I find your draft fundamentally > > difficult to understand. > > "Fundamentally" is quite serious. Could you be more specific about > which fundamentals you don't understand? > > > > Could you provide some specific examples > > for pedestrians? > Thanks, the example made it all clear. I was just dumb the other day. I wondered whether you could rename ADs as "autonomous domains". "Administrative" isn't a popular word in the IETF... ... > > Don't they end up with multiple addresses? > > > Of course! As written: > > Because the Domain can utilize more than one Exchange, it can have > more than one RDI. Each Domain may chose to limit the number of > indirect RDI numbers in use at one time. > > All IPv6 nodes very frequently end up with multiple addresses, even > under "provider/subscriber". Another question of more general scope: have we defined what DNS will do about this? Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 29 05:04:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09143; Wed, 29 Mar 95 05:04:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09137; Wed, 29 Mar 95 05:04:39 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23457; Wed, 29 Mar 1995 04:56:46 -0800 Received: from venera.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA08693; Wed, 29 Mar 95 04:56:33 PST Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 29 Mar 1995 04:56:32 -0800 From: bmanning@ISI.EDU Posted-Date: Wed, 29 Mar 1995 04:55:21 -0800 (PST) Message-Id: <199503291255.AA24935@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 29 Mar 1995 04:55:22 -0800 Subject: Re: (IPng) New IPv6 DNS Draft To: ipng@sunroof.Eng.Sun.COM Date: Wed, 29 Mar 1995 04:55:21 -0800 (PST) In-Reply-To: <9503290150.AA22400@wizard.gsfc.nasa.gov> from "Bill Fink" at Mar 28, 95 08:50:44 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > You don't have to have a COMMON boundary for all providers for all sites, > but it would make sense in most cases to have a common boundary for all > providers for a given site, which will have a specified allocation of > the IPv6 address space. > > -Bill This sounds like the same problem that we had in doing the NASP mapping. To design for the general case you -must- assume that the boundary is not common and you can/will have different provider alignments for any given site. --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 29 07:25:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09161; Wed, 29 Mar 95 07:25:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09155; Wed, 29 Mar 95 07:25:10 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00142; Wed, 29 Mar 1995 07:17:16 -0800 Received: from VNET.IBM.COM by Sun.COM (sun-barr.Sun.COM) id AA28591; Wed, 29 Mar 95 07:17:16 PST Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 7489; Wed, 29 Mar 95 10:16:55 EST Received: by RTP (XAGENTA 4.0) id 4134; Wed, 29 Mar 1995 10:15:40 -0500 Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA12300; Wed, 29 Mar 1995 10:16:34 -0500 Message-Id: <9503291516.AA12300@cichlid.raleigh.ibm.com> To: ipng@sunroof.Eng.Sun.COM Cc: hinden@ipsilon.com Subject: Re: (IPng) New IPv6 Address Architecture Draft In-Reply-To: (Your message of Mon, 27 Mar 95 15:42:50 PST.) Date: Wed, 29 Mar 95 10:16:33 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >The biggest change was the replacement of the region addresses with anycast >addresses. I think that "anycast" is a more general service than what was >proposed by regions or clusters, provides a complementary service to >unicast and multicast addresses, is easier to understand, and can be used >to implement the routing concepts that were proposed with region addresses. Overall, much clearer. Here are some more comments. >2.1 Addressing Model > >IPv6 Addresses of all types are assigned to interfaces, not nodes. >Since each interface belongs to a single node, any of that node's >interfaces' unicast addresses may be used as an identifier for the node. > >An IPv6 unicast address refers to a single interface. A single >interface may be assigned multiple IPv6 addresses of any type (unicast, >anycast, and multicast). There are two exceptions to this model. These >are: Is it the case that an interface must have at least one unicast address associated with it? I would assume the answer is yes, but the above text is ambiguous. >IPv6 continues the IPv4 model that a subnet is associated with one link. >Multiple subnets may be assigned to the same link. I think it would be helpful to more precisely define the term "subnet" (maybe even in the overview document, so that it has consistent meaning across all documents?). Correct me if I'm wrong, but to me a subnet means: 1) a unicast address together with a prefix size. 2) a node can directly reach all nodes on the subnet *without* going through an intermediate router. This is the v4 model, and I'm assuming it is also the v6 model. The reason I mention this is that the above text simply says a subnet is associated with a link. It is more precise to say that a subnet is associated with a specific address on the link (after all, it doesn't make sense to have a subnet associated with a link, if the link/interface doesn't even have an address on that subnet). Being more precise is helpful when dealing with an interface that has multiple unicast addresses and thus connects to multiple subnets. >A node may discover a subnet ID by listening to General >Advertisement messages send by a router on its attached link(s), and >then fabricating a IPv6 address for itself by using its IEEE MAC address >as the interface ID on that subnet. There needs to be a reference to the document(s) that discuss General Advertisements. The term is used without any sort of definition/reference. Also "send" should be "sent". >2.4.3 The Loopback Address > >The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. It >may be used by a node to send a IPv6 datagram to itself. It may never >be assigned to any interface. > >The loopback address must not be used as the source address in IPv6 >datagrams that are sent outside of a single node. Should it be stated that a a packet addressed to the loopback address should never be sent to a neighboring node? I assume that is the intent, but the text doesn't make it explicit. >2.5 Anycast Addresses > >An IPv6 anycast address is an address that is assigned to more than one >interface (typically belonging to different nodes), with the property >that a packet sent to an anycast address is routed to the nearest ^^^^^^^ >interface having that address, according to the routing protocols' >measure of distance. I'm a little uncomfortable with the term "nearest". To me it says something about the precise path the packet will take that I don't think should be implied as fact. I can't think of a better word right off, but it would be preferable to use a term that is a bit more neutral. Given a choice of two or more possible destinations, the routing subsystem will chose one. I don't think the architecture should mandate which destination will used (e.g., by saying "nearest"), since the actual path depends on the flow id or priority as well, and might not always be what folks consider to be intuitively "nearest". >For any assigned anycast address, there is a longest address prefix P >that identifies the topological region in which all interfaces belonging >to that anycast address reside. Within the region identified by P, each >member of the anycast set must be advertised as a separate entry in the >routing system (commonly referred to as a "host route"); outside the >region identified by P, the anycast address may be aggregated into the ^^^^^^ >routing advertisement for prefix P. I take it the intent is "may" rather than "must". What is an example of where it is desirable to advertise (outside a region) a separate route for the anycast address in addition to the prefix route for the region as a whole? I can imagine that advertising a separate anycast address allows for different paths into a region, one being the generic path all packets take, the second being the anycast path. The anycast path, however, could be either better or worse, and there is no way of really knowing for sure. How would this be useful? > o An anycast address MUST NOT be used as the source address of an > IPv6 packet. > > o An anycast address MUST NOT be assigned to an IPv6 host, that is, > it may be assigned to an IPv6 router only. I note that it is not explicitely forbidden to send transport-level packets (tcp, udp) to anycast addresses. I see a number of problems with using tcp/udp and anycast addresses, making it unclear to me how useful anycast addresses are to anything above IP. Is the intention here to be deliberately vague on this topic? Just what are anycast addresses good for, other than for specifying (loose) source routes? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 29 08:16:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09185; Wed, 29 Mar 95 08:16:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09179; Wed, 29 Mar 95 08:16:02 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04162; Wed, 29 Mar 1995 08:08:09 -0800 Received: from nic1.barrnet.net by Sun.COM (sun-barr.Sun.COM) id AB07413; Wed, 29 Mar 95 08:08:09 PST Received: from ipsilon.com by nic1.barrnet.net (8.6.10/BARRNET-RELAY.1) id IAA19027; Wed, 29 Mar 1995 08:08:05 -0800 Received: from [140.174.164.131] (annex-p132.meer.net) by ipsilon.com (4.1/SMI-4.1MDV1.0) id AA08317; Wed, 29 Mar 95 08:06:39 PST X-Sender: hinden@servo.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Mar 1995 08:06:21 -0800 To: ipng@sunroof.Eng.Sun.COM From: hinden@ipsilon.com (Bob Hinden) Subject: Re: (IPng) I-D ACTION:draft-ietf-ipngwg-addr-arch-00.txt Cc: IETF-Announce@CNRI.Reston.VA.US Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM To avoid confusion, the draft which was just announced is not the current version of this document. The current version is draft-ietf-ipngwg-addr-arch-02.txt. The current version was submitted to be an ID and can be found for anonymous ftp at: ftp.ipsilon.com as pub/ipng/draft-ietf-ipngwg-addr-arch-02.txt This version reflects the comments received during the working group last call. Bob At 10:52 AM 3/28/95, Internet-Drafts@CNRI.Reston.VA.US wrote: >Note: This announcement is being re-sent with a new filename. > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the IPNG Working Group >of the IETF. > > > Title : IP Version 6 Addressing Architecture > Author(s) : R. Hinden > Filename : draft-ietf-ipngwg-addr-arch-00.txt > Pages : 18 > Date : 03/24/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]. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 29 18:48:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09562; Wed, 29 Mar 95 18:48:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09556; Wed, 29 Mar 95 18:48:40 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21094; Wed, 29 Mar 1995 18:40:46 -0800 Received: from mentat.com by Sun.COM (sun-barr.Sun.COM) id AA25126; Wed, 29 Mar 95 18:40:41 PST Received: from orna.mentat.com ([192.88.122.155]) by mentat.com (4.1/SMI-4.1) id AA12197; Wed, 29 Mar 95 18:40:02 PST Received: by orna.mentat.com (5.0/SMI-SVR4) id AA17770; Wed, 29 Mar 1995 18:40:01 +0800 Date: Wed, 29 Mar 1995 18:40:01 +0800 From: mark@mentat.com (Marc Hasson) Message-Id: <9503300240.AA17770@orna.mentat.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Minor bsd-api comments X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Comments on bsd-api dated 3/13/95: Looks good to me, except for a non-BSD (!!) implementation issue it raises which I'll post in a separate note. Minor technical: 1) section 4.2, struct in_addr6 Strongly support the u_char[16] version. I believe this was mentioned the other day as being fixed up. This also lessens any potential issues of endian'ness. 2) section 4.3, sockaddr_in6 All fine but there's no mention of enlarging the base "struct sockaddr" that this larger struct sockaddr_in6 "maps" into. I guess this has to be, in order to satisfy the first bullet under "Design Considerations". But won't some converting apps be bit by having an underlying template sockaddr_in6 that is larger than the generic "struct sockaddr" which may be the one used to actually allocate storage by the caller doing sockaddr-based "transport independent" stuff? Most systems define "struct sockaddr" to only be 16 bytes but that always covers the specific sockaddr_xxxx types, as far as I know. At least a warning should be added to the document since we probably shouldn't enlarge "struct sockaddr" which applications may have buried in other structures. The warning is that "struct sockaddr" is no longer large enough to allocate space for the sockaddr_in6 guy. (Yep, I know this seems trivial.) 3) sections 4.10, 4.11, 4.12, socket options What is the behavior of the API when IP_ADDRFORM has been set to PF_INET and the options defined in these sections are used? Assuming the underlying support is actually IPv6 then its fine(?) to have the IP_UNICAST_HOPS & IP_MULTICAST_HOPS do what they're supposed to even though not part of the older PF_INET API. But clearly IP_RCVSRCRT shouldn't be allowed in PF_INET mode since it can't be used until PF_INET6. Or we can say explicitly that IP_RCVSRCRT is allowed any time but inactive until mode PF_INET6 is set. Either is fine to me. What happens if the underlying transport is actually IPv4 (due to one of the future IPv4/IPv6 interoperability modes) when the above options are used? Map IPv6 "hops" to IPv4 "ttl" and definitely error IP_RCVSRCRT? Typographic errors: 1) Section 2, bullet 3 "should not need know" -> "should not need to know" 2) Sections 4.2, 4.3: Fix the lines containing "in in network byte order". 3) Section 4.9, first paragraph, last word: Shouldn't "send" be "receive"? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 29 18:51:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09575; Wed, 29 Mar 95 18:51:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09569; Wed, 29 Mar 95 18:51:51 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21300; Wed, 29 Mar 1995 18:43:55 -0800 Received: from mentat.com by Sun.COM (sun-barr.Sun.COM) id AA25520; Wed, 29 Mar 95 18:43:23 PST Received: from orna.mentat.com ([192.88.122.155]) by mentat.com (4.1/SMI-4.1) id AA12357; Wed, 29 Mar 95 18:42:44 PST Received: by orna.mentat.com (5.0/SMI-SVR4) id AA17778; Wed, 29 Mar 1995 18:42:44 +0800 Date: Wed, 29 Mar 1995 18:42:44 +0800 From: mark@mentat.com (Marc Hasson) Message-Id: <9503300242.AA17778@orna.mentat.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) bsd-api IP_ADDRFORM and Streams X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM This note should be skipped by anyone not interested in STREAMS implementations of IPv6, TLI, or XTI interfaces. I think that the IP_ADDRFORM option described in the bsd-api draft is a great idea but I have one concern about that option in a STREAMS TLI or XTI application libraries environment. I would think that users of those interfaces may also have engaged in exec() and passing file descriptors, I know our libraries have to support this. But since TLI or XTI communicate the IP_ADDRFORM option to the underlying protocols via STREAMS TPI messages there is a "race" between setting the IP_ADDRFORM to PF_INET and having TPI messages in PF_INET6 form already headed application-ward (these messages are actually at a kernel/user boundary where underlying kernel protocol code "shouldn't reach" them). I've been pursuing a few implementation solutions (TLI/XTI IPv6 application rules/procedures/restrictions, protocol-specific code in the libraries, etc.) with folks here and elsewhere. If anyone else out there has internals knowledge of their TLI/XTI and/or STREAMS implementations I'd appreciate hearing some implementation suggestions or just discussing this further with you. I suggest it would be most efficient to do this off-line from the main list and group (perhaps in an IETF hallway next week) and then bring in some concrete suggestions, if necessary. Maybe a small TLI/XTI streams-api draft document will be needed so that multiple implementers do this in an application consistent way. Perhaps someone has a simple idea I've overlooked... -- Marc -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 29 19:47:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09612; Wed, 29 Mar 95 19:47:15 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09606; Wed, 29 Mar 95 19:47:08 PST Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id TAA13702; Wed, 29 Mar 1995 19:39:11 -0800 Received: by bobo.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id TAA24597; Wed, 29 Mar 1995 19:39:04 -0800 Date: Wed, 29 Mar 1995 19:39:04 -0800 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199503300339.TAA24597@bobo.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) bsd-api IP_ADDRFORM and Streams Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The problem you are pointing out (changing IP_ADDRFORM when there is data queued for reception) potentially exist in BSD implemementations as well. In BSD implementations the protocol code (e.g. UDP) calls sbappendaddr() to queue datagrams for reception by the application. Thus if a datagram was queued on the socket receive buffer before the IP_ADDRFORM a subsequent recvfrom/recvmsg would present the wrong address form to the application. (Note that the socket layer in BSD is protocol independent so it doesn't know anything about different address families and address formats.) The only advantage in the BSD framework (over STREAMS) is that it is feasible for the protocol code to reach into the socket buffer and update any queued datagrams when the IP_ADDRFORM is changed. IMHO doing this is still rather ugly. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 30 02:07:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09948; Thu, 30 Mar 95 02:07:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09942; Thu, 30 Mar 95 02:07:18 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10882; Thu, 30 Mar 1995 01:59:26 -0800 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA22029; Thu, 30 Mar 95 01:59:23 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) bsd-api IP_ADDRFORM and Streams To: ipng@sunroof.Eng.Sun.COM Date: Thu, 30 Mar 1995 10:19:18 +0100 (BST) In-Reply-To: <199503300339.TAA24597@bobo.Eng.Sun.COM> from "Erik Nordmark" at Mar 29, 95 07:39:04 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > In BSD implementations the protocol code (e.g. UDP) calls > sbappendaddr() to queue datagrams for reception by the application. > Thus if a datagram was queued on the socket receive buffer before > the IP_ADDRFORM a subsequent recvfrom/recvmsg would present > the wrong address form to the application. (Note that the socket > layer in BSD is protocol independent so it doesn't know anything > about different address families and address formats.) Im really glad someone pointed this lot out, as although I totally missed the problem, the same will also be true under Linux although the window is much much smaller than in BSD and you'd need two threads running on the same socket for it to happen. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 30 12:17:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10442; Thu, 30 Mar 95 12:17:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10436; Thu, 30 Mar 95 12:17:35 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29106; Thu, 30 Mar 1995 12:09:39 -0800 Received: from itd.nrl.navy.mil (itd-fddi.nrl.navy.mil) by Sun.COM (sun-barr.Sun.COM) id AA29107; Thu, 30 Mar 95 12:09:39 PST Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA28086; Thu, 30 Mar 95 15:09:34 EST Date: Thu, 30 Mar 95 15:09:34 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9503302009.AA28086@itd.nrl.navy.mil> To: ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net Subject: (IPng) new Photuris draft available for ftp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, I've put Phil Karn's most recent Photuris key mgmt protocol draft out for anonymous ftp from ftp.nrl.navy.mil in pub/security/draft-karn-*.txt; I did so at his and Bill's request. This draft was too late to make the pre-Danvers I-D submission deadline, but it seemed useful to make it widely available prior to next week's IPsec meeting where it will be discussed. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 30 12:59:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10472; Thu, 30 Mar 95 12:59:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10466; Thu, 30 Mar 95 12:59:51 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03734; Thu, 30 Mar 1995 12:51:56 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA07782; Thu, 30 Mar 95 12:51:42 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14386; Fri, 31 Mar 1995 06:51:31 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Cc: ipsec@ans.net Subject: Re: (IPng) new Photuris draft available for ftp In-Reply-To: Your message of "Thu, 30 Mar 1995 15:09:34 EST." <9503302009.AA28086@itd.nrl.navy.mil> Date: Fri, 31 Mar 1995 06:42:14 +1000 Message-Id: <1448.796596134@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Thu, 30 Mar 95 15:09:34 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-ID: <9503302009.AA28086@itd.nrl.navy.mil> This draft was too late to make the pre-Danvers I-D submission deadline, but it seemed useful to make it widely available prior to next week's IPsec meeting where it will be discussed. I have no interest in this particular draft, so I'm going to comment on it rather than others that are in a similar position. There's a reason there's a deadline for drafts, and its not only because the secretariat have better things to do in the week before the IETF. Its that there needs to be time before the IETF's for people to obtain and digest the draft before the IETF meeting. Even a week before is tight (lots of people are at interop this week I gather). I know that no I'm at home, I leave for the airport in a couple of hours, and I'm not going anywhere near a printer in the meantime. If I wanted to fetch that draft and understand it before the IETF I'd have no chance, which would mean any attempt to work out what is going on would have to depend on what I picked up at the meeting itself, which is absolutely not the way things are supposed to work. Drafts that don't make it to the I-D directories before the IETF should (must) be totally out of bounds for discussions in the WG meetings, they're for next time. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 30 15:16:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10535; Thu, 30 Mar 95 15:16:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10511; Thu, 30 Mar 95 14:42:20 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18023; Thu, 30 Mar 1995 14:34:26 -0800 Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA29362; Thu, 30 Mar 95 14:32:43 PST Received: from [129.191.63.3] (jimsmac.network.com) by nsco.network.com (4.1/1.34) id AA14869; Thu, 30 Mar 95 16:48:58 CST Message-Id: <9503302248.AA14869@nsco.network.com> X-Sender: hughes@129.191.63.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Mar 1995 16:37:44 -0600 To: ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net From: hughes@hughes.network.com (James P Hughes) Subject: (IPng) New Photuris draft available for ftp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Phil Karn's most recent Photuris key mgmt protocol draft is also available for anonymous ftp from ftp.network.com in ftp://ftp.network.com/IETF/IPSEC/draft-karn-photuris-01.txt This is in addition to the nrl copy. Jim ---------------------- James P Hughes Key fingerprint = 68 E7 D5 75 3C 88 86 71 D4 34 36 C3 8E DD 48 17 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 30 17:33:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10579; Thu, 30 Mar 95 17:33:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10571; Thu, 30 Mar 95 17:32:57 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09084; Thu, 30 Mar 1995 17:25:02 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA01307; Thu, 30 Mar 95 17:25:03 PST Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14609(1)>; Thu, 30 Mar 1995 17:24:53 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Thu, 30 Mar 1995 17:24:46 -0800 To: "Thomas Narten" Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) New IPv6 Address Architecture Draft In-Reply-To: narten's message of Wed, 29 Mar 95 07:16:33 -0800. <9503291516.AA12300@cichlid.raleigh.ibm.com> Date: Thu, 30 Mar 1995 17:24:36 PST From: Steve Deering Message-Id: <95Mar30.172446pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Thomas, > >An IPv6 unicast address refers to a single interface. A single > >interface may be assigned multiple IPv6 addresses of any type (unicast, > >anycast, and multicast). There are two exceptions to this model. These > >are: > > Is it the case that an interface must have at least one unicast > address associated with it? I would assume the answer is yes, but the > above text is ambiguous. There is the 2nd exception listed below the text you quoted, that allows routers to not have an address for their point-to-point interfaces. I would be possible (i.e., beyond our power to prevent) for a host to have an interface that is assigned only multicast and/or anycast addresses, but no unicast address. However, that interface could then not be addressed directly by any node, could not be used as the origin of any packet, and could not be used for any protocol that requires that the response to a multicast or anycast query come from the interface on which the query is received. So it doesn't sound like a very useful idea. > I think it would be helpful to more precisely define the term "subnet" > (maybe even in the overview document, so that it has consistent > meaning across all documents?). The SIPP spec carried the following definition: subnet - in the SIPP unicast addressing hierarchy, a lowest-level (finest-grain) aggregation of addresses sharing a common prefix, i.e., high-order address bits. but it got deleted when we went to IPv6, not because the idea of subnet changed, but because the term was never used in the base IPv6 spec. > Correct me if I'm wrong, but to me a subnet means: > > 1) a unicast address together with a prefix size. It is the longest meaningful prefix, less than 128 bits. > 2) a node can directly reach all nodes on the subnet *without* going > through an intermediate router. Generally true, but mobile hosts are the exception to this rule, since they may be transiently connected to links other than their home subnet's link. > This is the v4 model, and I'm assuming it is also the v6 model. Right. > >2.4.3 The Loopback Address > > > >The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. It > >may be used by a node to send a IPv6 datagram to itself. It may never > >be assigned to any interface. > > > >The loopback address must not be used as the source address in IPv6 > >datagrams that are sent outside of a single node. > > Should it be stated that a a packet addressed to the loopback address > should never be sent to a neighboring node? I assume that is the > intent, but the text doesn't make it explicit. That is the intent. Adding an explicit statement to that effect is fine with me. > I'm a little uncomfortable with the term "nearest". To me it says > something about the precise path the packet will take that I don't > think should be implied as fact. I can't think of a better word right > off, but it would be preferable to use a term that is a bit more > neutral. Given a choice of two or more possible destinations, the > routing subsystem will chose one. I don't think the architecture > should mandate which destination will used (e.g., by saying > "nearest"), since the actual path depends on the flow id or priority > as well, and might not always be what folks consider to be intuitively > "nearest". The use of the word "nearest" is qualified by "according to the routing protocols' measure of distance", about which I assume most folks have no intuition. Would it help if the word "nearest" always appeared in quotation marks? By the way, the priority field does not effect routing. An explicit flow set-up protocol may well be able to cause packets with a particular flow label to be routed differently than those without, but I'm not sure that setting up a flow to an anycast address is a sensible thing to support. > >For any assigned anycast address, there is a longest address prefix P > >that identifies the topological region in which all interfaces belonging > >to that anycast address reside. Within the region identified by P, each > >member of the anycast set must be advertised as a separate entry in the > >routing system (commonly referred to as a "host route"); outside the > >region identified by P, the anycast address may be aggregated into the > ^^^^^^ > >routing advertisement for prefix P. > > I take it the intent is "may" rather than "must". No, the intent was "can". > What is an example of where it is desirable to advertise (outside a > region) a separate route for the anycast address in addition to the > prefix route for the region as a whole? I can imagine that advertising > a separate anycast address allows for different paths into a region, > one being the generic path all packets take, the second being the > anycast path. The anycast path, however, could be either better or > worse, and there is no way of really knowing for sure. How would this > be useful? That doesn't sound likely to be useful, but I don't think we should outlaw it. > > o An anycast address MUST NOT be used as the source address of an > > IPv6 packet. > > > > o An anycast address MUST NOT be assigned to an IPv6 host, that is, > > it may be assigned to an IPv6 router only. > > I note that it is not explicitely forbidden to send transport-level > packets (tcp, udp) to anycast addresses. Since anycast addresses are syntactically indistinguishable from unicast addresses, there's no way for a transport protocol to know that it is sending to one, so it seems unreasonable to forbid it. Note, however, that the members of an anycast group *do* know that the address of the group is an anycast, and are forbidden from sending a packet with that address as a source; thus an attempt, for example, to establish a TCP connection to an anycast address will fail. > I see a number of problems with using tcp/udp and anycast addresses, Yes. See Partridge et al's RFC on anycasting. > Is the intention here to be deliberately vague on this topic? Yes, until we learn more about the benefits, hazards, and complications of anycasting. > Just what are anycast addresses good for, other than for specifying > (loose) source routes? That remains to be seen. Perhaps service location, where the response to a query identifies a unicast address of an instance of a service. Perhaps someone will define a new option for TCP, or a new version of TCP, that will allow a member of an anycast group to reply to a connection attempt with a response that says "use my unicast address, x, for subsequent packets on this connection", and says it in a way that can be authenticated. Then we might consider lifting the prohibition on assigning anycast addresses to hosts. But I think we should be conservative and avoid using anycast for functions that are better, or just as well, supported by other, existing mechanisms, such as multicast or the DNS. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 31 08:41:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10940; Fri, 31 Mar 95 08:41:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10934; Fri, 31 Mar 95 08:41:01 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29424; Fri, 31 Mar 1995 08:33:05 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA16752; Fri, 31 Mar 95 08:33:04 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm037-13.dialip.mich.net [141.211.7.86]) by merit.edu (8.6.10/merit-2.0) with SMTP id LAA08031 for ; Fri, 31 Mar 1995 11:33:01 -0500 Date: Fri, 31 Mar 95 15:59:53 GMT From: "William Allen Simpson" Message-Id: <4423.Bill.Simpson@um.cc.umich.edu> To: ipsec@ans.net Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: new Photuris draft available for ftp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Robert Elz > Its that there needs to be time before the IETF's for people to > obtain and digest the draft before the IETF meeting. Even a week > before is tight (lots of people are at interop this week I > gather). > As a person who pushed for the Internet-Draft deadline, I absolutely agree. Two weeks would have been even better. > I leave for the airport in a couple of > hours, and I'm not going anywhere near a printer in the meantime. It is particularly important for those like KRE who are travelling long distances. On the other hand, KRE has previously announced that he refuses to take a laptop on the road, merely because he doesn't like the operating systems available. A laptop would solve many of his problems, and he'd be able to read on the plane. > Drafts that don't make it to the I-D directories before the IETF > should (must) be totally out of bounds for discussions in the WG > meetings, they're for next time. > I agree. Fortunately, in this case there was the -00 draft. The -01 draft merely adds information from implementation experience, including revised packet formats and editorial matters. I'll make sure we cover those differences during the presentation for people who are only familiar with the earlier draft. Thanks for the reminder. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 31 15:00:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11194; Fri, 31 Mar 95 15:00:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11188; Fri, 31 Mar 95 15:00:34 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16350; Fri, 31 Mar 1995 14:52:38 -0800 Received: from mentat.com by Sun.COM (sun-barr.Sun.COM) id AA05160; Fri, 31 Mar 95 14:52:36 PST Received: from orna.mentat.com ([192.88.122.155]) by mentat.com (4.1/SMI-4.1) id AA00455; Fri, 31 Mar 95 14:51:56 PST Received: by orna.mentat.com (5.0/SMI-SVR4) id AA04859; Fri, 31 Mar 1995 14:51:55 +0800 Date: Fri, 31 Mar 1995 14:51:55 +0800 From: mark@mentat.com (Marc Hasson) Message-Id: <9503312251.AA04859@orna.mentat.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) New IPv6 Address Architecture Draft X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve Deering replies to Thomas Narten: > The SIPP spec carried the following definition: > > subnet - in the SIPP unicast addressing hierarchy, a lowest-level > (finest-grain) aggregation of addresses sharing a common > prefix, i.e., high-order address bits. > > but it got deleted when we went to IPv6, not because the idea of subnet > changed, but because the term was never used in the base IPv6 spec. > > > Correct me if I'm wrong, but to me a subnet means: > > > > 1) a unicast address together with a prefix size. > > It is the longest meaningful prefix, less than 128 bits. > > > 2) a node can directly reach all nodes on the subnet *without* going > > through an intermediate router. > > Generally true, but mobile hosts are the exception to this rule, since they > may be transiently connected to links other than their home subnet's link. > > > This is the v4 model, and I'm assuming it is also the v6 model. > > Right. I'd assume that another exception is that of a host connected via a SLIP/PPP server? While reading this document I came up with a related concern about subnets when used with a SLIP/PPP server. To conserve address space I may want all my (possibly dialup) client hosts of a certain user community to have the same subnet prefix/id. This is desirable both from the address conservation standpoint and advertising a minimum number of subnet prefixes for routing purposes. However, the following texts in the addr-arch document seem to state that I can't do this and each of my links would have to have its own subnet prefix/id: From end of section 2.1 Addressing Model: IPv6 continues the IPv4 model that a subnet is associated with one link. Multiple subnets may be assigned to the same link. From end of section 2.4.7 Provider-Based Global Unicast Addresses: The subnet ID identifies a specific physical link. There can be multiple subnets on the same physical link. A specific subnet can not span multiple physical links. The term "subnet prefix" refers to the high-order part of the address up to and including the subnet ID. The group of nodes identified by the subnet ID must be attached to the same link. The interface ID identifies a single interface among the group of interfaces identified by the subnet prefix. To satisfy the above statements a SLIP/PPP server would have to have unique subnet ids for each link it handled. This definitely wastes address bits. I doubt this is whats intended for an IPv6 SLIP/PPP server and is certainly not what you're forced to do in today's world, despite the above comment about "IPv4 model". Or have I missed something? Assuming I do have a valid concern, perhaps we could move the above subnet ID "addressing model" text from section 2.4.7 up into a section 2.1 Addressing Model "subnet section" and add information for the SLIP/PPP case about subnets not necessarily being constrained to one physical link? It seems that both the mobile host and the SLIP/PPP example allow the same subnet prefix/ID on multiple physical links that have at least one (special?) agent/router in common servicing those links. I'm a bit confused as to the true status of the Discovery specs these days but the Contiguous bit which is in the Router Advertisement's Prefix-Information extension seems like a concept which is applicable here. That is, it seems reasonable to think of an IPv6 SLIP/PPP server with multiple client hosts on the same subnet prefix/id as serving all those hosts on a single non-contiguous subnet. The server/router provides the "glue" holding them together. Unlike IPv4, it seems to me that an IPv6 SLIP/PPP server *has* to be a full-up router and autoconfig/address server. So, it can also easily dispense the Contiguous information on its Router Advertisements. Admittedly, client SLIP/PPP hosts with a point-to-point link to the server probably don't *need* to have this non-contiguous knowledge in order to send packets for someone with the same subnet prefix/id to the server/router. But its nice that our addressing concepts "hang together" and this should probably also be mentioned under the above-suggested "Addressing Model" subnet section. -- Marc -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com