From owner-ipng Sun Apr 2 19:03:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11981; Sun, 2 Apr 95 19:03:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11975; Sun, 2 Apr 95 19:03:16 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13858; Sun, 2 Apr 1995 18:55:17 -0700 Received: from nic1.barrnet.net by Sun.COM (sun-barr.Sun.COM) id AA22190; Sun, 2 Apr 95 18:55:18 PDT Received: from ipsilon.com by nic1.barrnet.net (8.6.10/BARRNET-RELAY.1) id SAA00243; Sun, 2 Apr 1995 18:55:14 -0700 Received: from [140.174.164.132] (annex-p132.meer.net) by ipsilon.com (4.1/SMI-4.1MDV1.0) id AA13047; Sun, 2 Apr 95 18:53:48 PDT X-Sender: hinden@servo.ipsilon.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 2 Apr 1995 17:53:31 -0800 To: ipng@sunroof.Eng.Sun.COM From: hinden@ipsilon.com (Bob Hinden) Subject: Re: (IPng) new Photuris draft available for ftp Cc: ipsec@ans.net Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Robert, At 6:42 AM 3/31/95, Robert Elz wrote: >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. While I would agree that we should all try to get our drafts out as early as possible, I would leave it up to the working group chair(s) to decide if a particular draft should be discussed at a working group session. Sometimes, a new draft is an incremental update to a previous one. Other times a late draft might be very important for what a working group is doing. Having a blanket bureaucratic rule is probably not the best approach. 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 Apr 3 05:01:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12143; Mon, 3 Apr 95 05:01:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12137; Mon, 3 Apr 95 05:01:12 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00866; Mon, 3 Apr 1995 04:53:13 -0700 Received: from mulga.cs.mu.OZ.AU by Sun.COM (sun-barr.Sun.COM) id AA10089; Mon, 3 Apr 95 04:53:11 PDT Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA05961 Mon, 3 Apr 1995 21:53:09 +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 "Sun, 02 Apr 1995 17:53:31 PST." Date: Mon, 03 Apr 1995 21:51:25 +1000 Message-Id: <1707.796909885@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Sun, 2 Apr 1995 17:53:31 -0800 From: hinden@ipsilon.com (Bob Hinden) Message-ID: Having a blanket bureaucratic rule is probably not the best approach. I agree with that largely. But I'm afraid that if you do away with a bureaucratic rule that way, you also need to do away with the rule that expects people to have read the drafts before attending the meetings (and expecting to contribute). That means read any drafts - personally I don't have time to read everything as its published, I try to catch up on the latest drafts just before the IETF's so I have an idea what most are about. But if I'm not sure they're going to be the latest, as somethig new is going to appear (or might appear) the day before the IETF, then I'm not going to read any of them probably. Too much risk of wasting 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 Tue Apr 4 11:04:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13212; Tue, 4 Apr 95 11:04:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13047; Tue, 4 Apr 95 06:52:23 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00139; Tue, 4 Apr 1995 06:44:23 -0700 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA22797; Tue, 4 Apr 95 06:44:17 PDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa00790; 4 Apr 95 9:39 EDT To: IETF-Announce:;@CNRI.Reston.VA.US Cc: addrconf@cisco.com, ipng@sunroof.Eng.Sun.COM, mwalnut@CNRI.Reston.VA.US Subject: (IPng) DANVERS ON-SITE: Addrconf/Ipngwg Reschedule Date: Tue, 04 Apr 95 09:39:28 -0400 From: Megan Davies Walnut Message-Id: <9504040939.aa00790@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The IPNGWG session originally scheduled to meet today, Tuesday April 4 at 1300-1500 in Tara III has been moved to Wednesday, April 5 at 1530-1730 in Ferncroft East. It will not be multicast. The ADDRCONF session originally scheduled to meet tomorrow, Wednesday, April 5 at 1530-1730 in Ferncroft East will meet TODAY, Tuesday at 1300-1500 in TARA III. It will be multicast. Megan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Apr 6 22:25:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14832; Thu, 6 Apr 95 22:25:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14826; Thu, 6 Apr 95 22:25:29 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28320; Thu, 6 Apr 1995 22:17:23 -0700 Received: from conch.vast.unsw.edu.au by Sun.COM (sun-barr.Sun.COM) id AA27545; Thu, 6 Apr 95 22:17:19 PDT Received: from mucket.vast.unsw.edu.au by conch.vast.unsw.edu.au with SMTP id AA29675 (5.65c/IDA-1.4.4 for ); Fri, 7 Apr 1995 15:12:55 +1000 From: Alex Lam Received: by mucket.vast.unsw.edu.au (5.65c/client-1.3) id AA17529; Fri, 7 Apr 1995 15:12:54 +1000 Message-Id: <199504070512.AA17529@mucket.vast.unsw.edu.au> Subject: (IPng) Some questions on IPng To: ipng@sunroof.Eng.Sun.COM Date: Fri, 7 Apr 1995 15:12:52 +1000 (EST) In-Reply-To: <9503312251.AA04859@orna.mentat.com> from "Marc Hasson" at Mar 31, 95 02:51:55 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi, I am not sure if this is an appropriate place to ask this sort of question, but here it goes.. 1) When will the NEXT HEADER field of a header contain "NO NEXT HEADER" ? Is there a case when we do not have any upper layer headers ? 2) With regarding to addressing, what exactly do you mean by "provider" and "subscriber" 3) I guess this might be a bit silly to ask, but is there any ipng.c written up ? If so, where I can get a copy ? 4) Finally, if you think this is not a right place to ask these sort of question, can you suggest some other places ? newsgroup ? Thanks Alex Lam -- ****************** | _ |\/| _ Computer Science and Engineering, UNSW |___|_|_| |_ , |-| L E X email: alexl@vast.unsw.edu.au | | alexl@cse.unsw.edu.au ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Apr 10 06:43:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15926; Mon, 10 Apr 95 06:43:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15920; Mon, 10 Apr 95 06:43:44 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16400; Mon, 10 Apr 1995 06:35:35 -0700 Received: from concorde.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA03120; Mon, 10 Apr 95 06:34:56 PDT 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 PAA24737 for ; Mon, 10 Apr 1995 15:34:36 +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 PAA29115 for ; Mon, 10 Apr 1995 15:34:34 +0200 Message-Id: <199504101334.PAA29115@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) flow labels and FOOBAR Date: Mon, 10 Apr 1995 15:34:33 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have two related questions about flow labels and FOOBAR (ie RFC 1639 FTP Operation Over Big Address Records): 1- there are two flow labels for a connection between two hosts A and B. One is used in packets from A to B, the second is used from B to A. The API spec says: * the outgoing flow label can be specified by connect(), sendto() and bind() system calls. * the outgoing flow label can be accessed but it seems to be a typo? * the incoming flow label can be accessed by recvfrom() and accept() system calls. * nothing is available for getsockname() and getpeername() (I have already pointed out this then it should be resolved in the next version :-) The semantic of flow label in the receipt side is not clear, I believe there are two options: * loose semantic: flow label is only used for speedup (no more processing than TOS) * strict semantic: if flow labels don't match the packet is rejected. It supposed a wildcard value (0 of course) and a way to specify the incoming flow label (then I suppose the proposed semantic is the loose one). 2- If the flow label semantic is strict we need a way to specify the flow label for FTP data connection, ie we'd have to extend LPRT and LPSV in order to include a flow label. In fact perhaps it is useful with loose semantics too to have the same flow label for following data connections (but it can be easily done without extending LPRT/LPSV). 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 Mon Apr 10 10:02:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16052; Mon, 10 Apr 95 10:02:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15933; Mon, 10 Apr 95 06:56:20 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17040; Mon, 10 Apr 1995 06:48:11 -0700 Received: from maxstrat.com by Sun.COM (sun-barr.Sun.COM) id AA04988; Mon, 10 Apr 95 06:48:11 PDT Received: from sunroof2.Eng.Sun.COM by maxstrat.com (920330.SGI/1.34) id AA09373; Mon, 10 Apr 95 06:47:20 -0700 Date: Mon, 10 Apr 95 06:47:20 -0700 From: owner-ipng@sunroof2.Eng.Sun.COM Message-Id: <9504101347.AA09373@maxstrat.com> Apparently-To: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ***** UNDELIVERABLE MAIL sent to ron, being returned by bookem!ron ***** mail: Error # 2 'Problem with mailfile' encountered on system bookem Received: from koriel.Sun.COM by maxstrat.com (920330.SGI/1.34) id AA09366; Mon, 10 Apr 95 06:47:10 -0700 Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (koriel.Sun.COM) id AA13544; Mon, 10 Apr 95 06:33:49 PDT Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3) id AA16349; Mon, 10 Apr 1995 06:37:10 -0700 Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15926; Mon, 10 Apr 95 06:43:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15920; Mon, 10 Apr 95 06:43:44 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16400; Mon, 10 Apr 1995 06:35:35 -0700 Received: from concorde.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA03120; Mon, 10 Apr 95 06:34:56 PDT 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 PAA24737 for ; Mon, 10 Apr 1995 15:34:36 +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 PAA29115 for ; Mon, 10 Apr 1995 15:34:34 +0200 Message-Id: <199504101334.PAA29115@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) flow labels and FOOBAR Date: Mon, 10 Apr 1995 15:34:33 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have two related questions about flow labels and FOOBAR (ie RFC 1639 FTP Operation Over Big Address Records): 1- there are two flow labels for a connection between two hosts A and B. One is used in packets from A to B, the second is used from B to A. The API spec says: * the outgoing flow label can be specified by connect(), sendto() and bind() system calls. * the outgoing flow label can be accessed but it seems to be a typo? * the incoming flow label can be accessed by recvfrom() and accept() system calls. * nothing is available for getsockname() and getpeername() (I have already pointed out this then it should be resolved in the next version :-) The semantic of flow label in the receipt side is not clear, I believe there are two options: * loose semantic: flow label is only used for speedup (no more processing than TOS) * strict semantic: if flow labels don't match the packet is rejected. It supposed a wildcard value (0 of course) and a way to specify the incoming flow label (then I suppose the proposed semantic is the loose one). 2- If the flow label semantic is strict we need a way to specify the flow label for FTP data connection, ie we'd have to extend LPRT and LPSV in order to include a flow label. In fact perhaps it is useful with loose semantics too to have the same flow label for following data connections (but it can be easily done without extending LPRT/LPSV). 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 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Apr 10 10:06:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16064; Mon, 10 Apr 95 10:06:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14838; Thu, 6 Apr 95 22:36:39 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28799; Thu, 6 Apr 1995 22:28:33 -0700 Received: from maxstrat.com by Sun.COM (sun-barr.Sun.COM) id AA28687; Thu, 6 Apr 95 22:28:34 PDT Received: from sunroof2.Eng.Sun.COM by maxstrat.com (920330.SGI/1.34) id AA20556; Thu, 6 Apr 95 22:27:46 -0700 Date: Thu, 6 Apr 95 22:27:46 -0700 From: owner-ipng@sunroof2.Eng.Sun.COM Message-Id: <9504070527.AA20556@maxstrat.com> Apparently-To: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ***** UNDELIVERABLE MAIL sent to ron, being returned by bookem!ron ***** mail: Error # 2 'Problem with mailfile' encountered on system bookem Received: from koriel.Sun.COM by maxstrat.com (920330.SGI/1.34) id AA20549; Thu, 6 Apr 95 22:27:38 -0700 Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (koriel.Sun.COM) id AA29924; Thu, 6 Apr 95 22:16:20 PDT Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3) id AA25483; Thu, 6 Apr 1995 22:19:01 -0700 Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14832; Thu, 6 Apr 95 22:25:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14826; Thu, 6 Apr 95 22:25:29 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28320; Thu, 6 Apr 1995 22:17:23 -0700 Received: from conch.vast.unsw.edu.au by Sun.COM (sun-barr.Sun.COM) id AA27545; Thu, 6 Apr 95 22:17:19 PDT Received: from mucket.vast.unsw.edu.au by conch.vast.unsw.edu.au with SMTP id AA29675 (5.65c/IDA-1.4.4 for ); Fri, 7 Apr 1995 15:12:55 +1000 From: Alex Lam Received: by mucket.vast.unsw.edu.au (5.65c/client-1.3) id AA17529; Fri, 7 Apr 1995 15:12:54 +1000 Message-Id: <199504070512.AA17529@mucket.vast.unsw.edu.au> Subject: (IPng) Some questions on IPng To: ipng@sunroof.Eng.Sun.COM Date: Fri, 7 Apr 1995 15:12:52 +1000 (EST) In-Reply-To: <9503312251.AA04859@orna.mentat.com> from "Marc Hasson" at Mar 31, 95 02:51:55 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi, I am not sure if this is an appropriate place to ask this sort of question, but here it goes.. 1) When will the NEXT HEADER field of a header contain "NO NEXT HEADER" ? Is there a case when we do not have any upper layer headers ? 2) With regarding to addressing, what exactly do you mean by "provider" and "subscriber" 3) I guess this might be a bit silly to ask, but is there any ipng.c written up ? If so, where I can get a copy ? 4) Finally, if you think this is not a right place to ask these sort of question, can you suggest some other places ? newsgroup ? Thanks Alex Lam -- ****************** | _ |\/| _ Computer Science and Engineering, UNSW |___|_|_| |_ , |-| L E X email: alexl@vast.unsw.edu.au | | alexl@cse.unsw.edu.au ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: 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 Mon Apr 10 17:55:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16721; Mon, 10 Apr 95 17:55:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16715; Mon, 10 Apr 95 17:55:21 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08280; Mon, 10 Apr 1995 17:47:11 -0700 Received: from conch.vast.unsw.edu.au by Sun.COM (sun-barr.Sun.COM) id AA12092; Mon, 10 Apr 95 17:47:06 PDT Received: from mucket.vast.unsw.edu.au by conch.vast.unsw.edu.au with SMTP id AA12056 (5.65c/IDA-1.4.4 for ); Tue, 11 Apr 1995 10:46:24 +1000 From: Alex Lam Received: by mucket.vast.unsw.edu.au (5.65c/client-1.3) id AA23024; Tue, 11 Apr 1995 10:46:21 +1000 Message-Id: <199504110046.AA23024@mucket.vast.unsw.edu.au> Subject: (IPng) prototype - ipng.c ? To: ipng@sunroof.Eng.Sun.COM (ipng) Date: Tue, 11 Apr 1995 10:46:20 +1000 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi, Does anyone know where I can find an ipng prototype ? (even if it is incomplete) ie ipng.c ? Thanks Alex Lam -- ****************** | _ |\/| _ Computer Science and Engineering, UNSW |___|_|_| |_ , |-| L E X email: alexl@vast.unsw.edu.au | | alexl@cse.unsw.edu.au ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Apr 11 12:32:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17337; Tue, 11 Apr 95 12:32:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17331; Tue, 11 Apr 95 12:32:47 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00532; Tue, 11 Apr 1995 12:24:36 -0700 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA27530; Tue, 11 Apr 95 12:24:35 PDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08068; 11 Apr 95 15:17 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng) I-D ACTION:draft-ietf-ipngwg-addr-arch-01.txt Date: Tue, 11 Apr 95 15:17:21 -0400 Message-Id: <9504111517.aa08068@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 : IP Version 6 Addressing Architecture Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-01.txt Pages : 17 Date : 04/10/1995 This specification defines the addressing architecture of the IP Version 6 protocol. It includes a detailed description of the address formats for IPv6 [IPV6]. The editors would like to acknowledge the contributions of Paul Francis, Jim Bound, Brian Carpenter, Deborah Estrin, Peter Ford, Bob Gilligan, Christian Huitema, Tony Li, Greg Minshall, Erik Nordmark, Yakov Rekhtor, Bill Simpson, and Sue Thomson. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addr-arch-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-addr-arch-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-addr-arch-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: <19950410164552.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950410164552.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 Apr 12 05:59:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17716; Wed, 12 Apr 95 05:59:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17710; Wed, 12 Apr 95 05:59:27 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16692; Wed, 12 Apr 1995 05:51:15 -0700 Received: from concorde.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA03790; Wed, 12 Apr 95 05:51:13 PDT 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 OAA06176 for ; Wed, 12 Apr 1995 14:48:28 +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 OAA02412 for ; Wed, 12 Apr 1995 14:48:27 +0200 Message-Id: <199504121248.OAA02412@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) prototype - ipng.c ? In-Reply-To: Your message of Tue, 11 Apr 1995 10:46:20 +1000. <199504110046.AA23024@mucket.vast.unsw.edu.au> Date: Wed, 12 Apr 1995 14:48:25 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In your previous mail you wrote: Does anyone know where I can find an ipng prototype ? (even if it is incomplete) ie ipng.c ? => My plan is to made my IPv6 implementation based on NetBSD for Sparc (but easily portable to any 4.4BSD-Lite derived OS) freely available as soon as I find the time to write a basic documentation. (I expect to find it before the end of this month :-) Francis.Dupont@inria.fr PS: please send a mail to me if you believe you need more infos. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Apr 12 14:12:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18003; Wed, 12 Apr 95 14:12:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17997; Wed, 12 Apr 95 14:12:24 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11258; Wed, 12 Apr 1995 14:04:12 -0700 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA06554; Wed, 12 Apr 95 14:04:00 PDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09089; 12 Apr 95 16:52 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng) I-D ACTION:draft-ietf-ipngwg-unicst-addr-allo-01.txt Date: Wed, 12 Apr 95 16:51:56 -0400 Message-Id: <9504121652.aa09089@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-unicst-addr-allo-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-unicst-addr-allo-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-unicst-addr-allo-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-unicst-addr-allo-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: <19950411160234.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-unicst-addr-allo-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-unicst-addr-allo-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950411160234.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 Sun Apr 16 22:53:18 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19656; Sun, 16 Apr 95 22:53:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19650; Sun, 16 Apr 95 22:53:10 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04947; Sun, 16 Apr 1995 22:44:50 -0700 Received: from conch.vast.unsw.edu.au ([149.171.224.3]) by Sun.COM (sun-barr.Sun.COM) id AA15667; Sun, 16 Apr 95 22:44:09 PDT Received: from oyster.vast.unsw.edu.au by conch.vast.unsw.edu.au with SMTP id AA29081 (5.65c/IDA-1.4.4 for ); Mon, 17 Apr 1995 15:43:43 +1000 From: Alex Lam Received: by oyster.vast.unsw.edu.au (5.65c/client-1.3) id AA08158; Mon, 17 Apr 1995 15:43:42 +1000 Message-Id: <199504170543.AA08158@oyster.vast.unsw.edu.au> Subject: (IPng) Some Questions To: ipng@sunroof.Eng.Sun.COM Date: Mon, 17 Apr 1995 15:43:42 +1000 (EST) In-Reply-To: from "Bob Hinden" at Apr 2, 95 05:53:31 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi, I have two question I want to ask.. 1) What is the difference between Hop-by-Hop Options and Destination Options ? There seems to be some contradiction as to when Destination Options Header is examined.. Do routers need to look at the destination options header ? What if a routing header is in used such at the router's address is in the IPv6 header (ie it becomes a destination host ?) 2) Routing header only allows 24 entries, can there be more ? Can one put in more than one routing header ? Your help will be very much appreciated.. Thanks Alex Lam PS I am still looking for an IPNG prototype.. let me know if you have one.. -- ****************** | _ |\/| _ Computer Science and Engineering, UNSW |___|_|_| |_ , |-| L E X email: alexl@vast.unsw.edu.au | | alexl@cse.unsw.edu.au ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Apr 17 01:13:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19689; Mon, 17 Apr 95 01:13:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19683; Mon, 17 Apr 95 01:13:27 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08478; Mon, 17 Apr 1995 01:05:09 -0700 Received: from mulga.cs.mu.OZ.AU by Sun.COM (sun-barr.Sun.COM) id AA26156; Mon, 17 Apr 95 01:05:07 PDT Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA19056 Mon, 17 Apr 1995 18:04:52 +1000 (from kre@munnari.OZ.AU) To: Alex Lam Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Some Questions In-Reply-To: Your message of "Mon, 17 Apr 1995 15:43:42 +1000." <199504170543.AA08158@oyster.vast.unsw.edu.au> Date: Mon, 17 Apr 1995 18:03:06 +1000 Message-Id: <2989.798105786@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 17 Apr 1995 15:43:42 +1000 (EST) From: Alex Lam Message-ID: <199504170543.AA08158@oyster.vast.unsw.edu.au> 1) What is the difference between Hop-by-Hop Options and Destination Options ? Hop-By-Hop is (like the basic IPv6 header) a magic header, in that it has to be examined at every node through which the packet passes. Dest Options are only examined when the IPv6 header "destination address" represents the current node (and the Dest Options is the next header in the chain). There seems to be some contradiction as to when Destination Options Header is examined.. What? Do routers need to look at the destination options header ? If the router's address (or an address that represents the router) appears in the IP dest addr field, then yes. But not otherwise. What if a routing header is in used such at the router's address is in the IPv6 header (ie it becomes a destination host ?) Then the dest options header is examined, if it appears before the routing header (otherwise the routing header will be seen first, the IPv6 dest addr will be changed, and the dest opts header would not be seen). 2) Routing header only allows 24 entries, can there be more ? No. Can one put in more than one routing header ? This is a question that I ponder from time to time. Every time I do I end up concluding that it wouldn't mean anything rational. 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 Apr 17 10:10:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19929; Mon, 17 Apr 95 10:10:59 PDT Received: from picadilly.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19923; Mon, 17 Apr 95 10:10:47 PDT Received: from picadilly by picadilly.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id KAA06378; Mon, 17 Apr 1995 10:01:44 -0700 Message-Id: <199504171701.KAA06378@picadilly.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng 1) Important mailing list changes, and some FYI stuff... Date: Mon, 17 Apr 1995 10:01:39 -0700 From: Steve Parker Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >From this point on, you will notice that Subject lines will include a tag including a message serial number. This feature is especially meaningful to those who have intermittent mail problems. It is immediately evident if messages to you are lost. You will also notice that the Reply-To: field has been dropped. Although the reply-to field creates the open style of forum the IPng list attempts to foster, many mailers do not follow the RFC-821/822 guidelines for handling this field. ** In the future, if you do not use your "reply all" style of reply, only ** the sender of the message will receive your reply. In addition, the archive of the history of all e-mail messages to the IPng list is available via e-mail from the majordomo server. You can find out what is available via e-mail by sending a message with: To: majordomo@sunroof.eng.sun.com Subject: index ipng You will find the archives of past IPng mailing list discussion broken into one-month chunks, named as ipng.YYMM, where YY is the year, and MM is the month. For example, you can retrieve all mail from March '95 with: To: majordomo@sunroof.eng.sun.com get ipng ipng.9503 And the other addresses for the mailing list: ipng@sunroof.eng.sun.com: Post to the list majordomo@sunroof.eng.sun.com: Subscribe, unsubscribe, change of address owner-ipng@sunroof.eng.sun.com: Reports of mail problems, or other things requiring human intervention. Cheers, ~sparker ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Apr 17 18:09:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20373; Mon, 17 Apr 95 18:09:37 PDT Received: from jurassic.eng.sun.com (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20367; Mon, 17 Apr 95 18:09:26 PDT Received: from picadilly.Eng.Sun.COM by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA20875; Mon, 17 Apr 1995 18:01:04 -0700 Received: by picadilly.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id SAA07446; Mon, 17 Apr 1995 18:00:03 -0700 Date: Mon, 17 Apr 1995 18:00:03 -0700 From: sparker@jurassic-248 (Steve Parker) Message-Id: <199504180100.SAA07446@picadilly.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng 2) Reply-to is really gone... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk My last message inadvertently still had the reply-to field. As of this point reply-to is turned off. ==> So you must use "reply all" for future replies to the list to be seen by list members. Cheers, ~sparker ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Apr 18 19:21:01 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21226; Tue, 18 Apr 95 19:21:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21220; Tue, 18 Apr 95 19:20:51 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02588; Tue, 18 Apr 1995 19:12:29 -0700 Received: from conch.vast.unsw.edu.au by Sun.COM (sun-barr.Sun.COM) id AA21521; Tue, 18 Apr 95 19:12:29 PDT Received: from mucket.vast.unsw.edu.au by conch.vast.unsw.edu.au with SMTP id AA18895 (5.65c/IDA-1.4.4 for ); Wed, 19 Apr 1995 12:12:06 +1000 From: Alex Lam Received: by mucket.vast.unsw.edu.au (5.65c/client-1.3) id AA03175; Wed, 19 Apr 1995 12:12:04 +1000 Message-Id: <199504190212.AA03175@mucket.vast.unsw.edu.au> Subject: (IPng 3) More Questions To: ipng@sunroof.Eng.Sun.COM Date: Wed, 19 Apr 1995 12:12:04 +1000 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi, It's me again... :) I have a few more questions..... 1) If a packet needs to be a) Authenticated b) Encapsulated c) Fragmented d) Route specificed e) With Hop-by-Hop and Destination options What should be the correct procedure of processing it ? Should we encapsulate the fragmented packet or should we fragment the encapsulated packet ? What about authentication ? Should we do auth. twice, one before encapsulation and other after encapsulation ? 2) Where does the magic number of MTU 576 octet come from, how was this worked out ? Thanks, Alex Lam -- ****************** | _ |\/| _ Computer Science and Engineering, UNSW |___|_|_| |_ , |-| L E X email: alexl@vast.unsw.edu.au | | alexl@cse.unsw.edu.au ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Apr 18 23:50:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21270; Tue, 18 Apr 95 23:50:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21264; Tue, 18 Apr 95 23:50:22 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13822; Tue, 18 Apr 1995 23:42:01 -0700 Received: from conch.vast.unsw.edu.au by Sun.COM (sun-barr.Sun.COM) id AA16594; Tue, 18 Apr 95 23:41:54 PDT Received: from mucket.vast.unsw.edu.au by conch.vast.unsw.edu.au with SMTP id AA24214 (5.65c/IDA-1.4.4 for ); Wed, 19 Apr 1995 16:41:35 +1000 From: Alex Lam Received: by mucket.vast.unsw.edu.au (5.65c/client-1.3) id AA03412; Wed, 19 Apr 1995 16:41:34 +1000 Message-Id: <199504190641.AA03412@mucket.vast.unsw.edu.au> Subject: (IPng 4) Even more questions... To: ipng@sunroof.Eng.Sun.COM Date: Wed, 19 Apr 1995 16:41:33 +1000 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi, May I ask a few more questios.... :) 1) Flow label Does the flow label cache store Hop Limits Fields ? If so, we are ensuring every packet to travel in the same route (even those that are not specified by the Routing header) 2) Fragmenting an encapsulated packet After re-assembling the fragmented packets, how can one identified whether the data is an encapsulated packet or not. Even if the re-assembled data begins with an encapsulation header, how do we identify it without an extra IPv6 header ? Does that mean we have to include an extra IPv6 header to the data before fragmenting ? Please reply.... May I ask more questions if I got into trouble again ? In fact, we are student from Uni. New South Wales Australia and we are trying to implement a hardware IPv6 processor (co-processor ?) Thanks Alex Lam -- ****************** | _ |\/| _ Computer Science and Engineering, UNSW |___|_|_| |_ , |-| L E X email: alexl@vast.unsw.edu.au | | alexl@cse.unsw.edu.au ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Apr 19 00:05:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21285; Wed, 19 Apr 95 00:05:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21279; Wed, 19 Apr 95 00:05:29 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14485; Tue, 18 Apr 1995 23:57:08 -0700 Received: from conch.vast.unsw.edu.au by Sun.COM (sun-barr.Sun.COM) id AA18180; Tue, 18 Apr 95 23:57:05 PDT Received: from mucket.vast.unsw.edu.au by conch.vast.unsw.edu.au with SMTP id AA24517 (5.65c/IDA-1.4.4 for ); Wed, 19 Apr 1995 16:56:50 +1000 From: Alex Lam Received: by mucket.vast.unsw.edu.au (5.65c/client-1.3) id AA03437; Wed, 19 Apr 1995 16:56:49 +1000 Message-Id: <199504190656.AA03437@mucket.vast.unsw.edu.au> Subject: (IPng 5) Questions To: ipng@sunroof.Eng.Sun.COM Date: Wed, 19 Apr 1995 16:56:48 +1000 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi, I have a question... Supposed I have a message to send and we need to do the following a) Authentication b) Encapsulation c) Fragmentation d) Add routing header and Hop-by-Hop header e) Destination option header What should be the correct order of processing the message ? Thanks, Alex Lam -- ****************** | _ |\/| _ Computer Science and Engineering, UNSW |___|_|_| |_ , |-| L E X email: alexl@vast.unsw.edu.au | | alexl@cse.unsw.edu.au ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Apr 19 06:20:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21386; Wed, 19 Apr 95 06:20:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21380; Wed, 19 Apr 95 06:20:27 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02380; Wed, 19 Apr 1995 06:12:06 -0700 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA26714; Wed, 19 Apr 95 06:11:58 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19051; Wed, 19 Apr 1995 23:11:50 +1000 (from kre@munnari.OZ.AU) To: Alex Lam Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 6) Re: (IPng 4) Even more questions... In-Reply-To: Your message of "Wed, 19 Apr 1995 16:41:33 +1000." <199504190641.AA03412@mucket.vast.unsw.edu.au> Date: Wed, 19 Apr 1995 23:10:38 +1000 Message-Id: <3107.798297038@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Wed, 19 Apr 1995 16:41:33 +1000 (EST) From: Alex Lam Message-ID: <199504190641.AA03412@mucket.vast.unsw.edu.au> 1) Flow label Does the flow label cache store Hop Limits Fields ? I'm afraid I don't understand this question, perhaps someone else might. 2) Fragmenting an encapsulated packet After re-assembling the fragmented packets, how can one identified whether the data is an encapsulated packet or not. The frag header contains a "next header" field, after the packet is reassembled, and the frag header and all before it removed, the value of that field from the frag header will tell you what is now the first header of the reassembled packet. If that tells you you now have an IP packet, and that IP packet is IPv6, then you have an encapsulated packet (actually so you do if its not IPv6 inside but IPv4). Even if the re-assembled data begins with an encapsulation header, There is no such thing. how do we identify it without an extra IPv6 header ? You don't, encapsulated packets, by their nature, contain an included IPv6 header (or an IPv4 header if it was an IPv4 packet that was encapsulated). Does that mean we have to include an extra IPv6 header to the data before fragmenting ? Not before fragmenting, if you're encapsulating though you'll have the IPv6 header of the encapsulated packet, then after encapsulating you'll have the IPv6 header of the encapsulated packet as well. You may have been missing the "next header" field of the fragmentation header, or its use, however. May I ask more questions if I got into trouble again ? You may want to try asking one or two of the people on the list for basic questions like these, rather than sending to the entire list. Then, from your other message... From: Alex Lam Message-Id: <199504190656.AA03437@mucket.vast.unsw.edu.au> Subject: (IPng 5) Questions Date: Wed, 19 Apr 1995 16:56:48 +1000 (EST) Supposed I have a message to send and we need to do the following a) Authentication b) Encapsulation c) Fragmentation d) Add routing header and Hop-by-Hop header e) Destination option header What should be the correct order of processing the message ? You process the message in the order the headers are present in it as received, in general there is no other way. If you mean in which order should you build the message, then that might depend, esp wrt encapsulation, but the basic order is set out in the spec... Hop-by-hop options come first (always). You might have dest options next, if you want them processed by every router in the routing header Routing header comes next Fragmentation header next Authentication header next (some debate about order of Frag/Auth) Destination options next, if they're just for the destination (which in this case is the end point of the tunnel) Encapsulated packet header is next (and is followed by all headers from the packet that was encapsulated). There may be some cases where for good reason you might require the headers in some other order, but they would need to be good reasons (personally I can imagine uses for sticking dest options before the frag header, or before the auth header, if we pre-suppose the existance of options that might control reassembly or authentication in some way - so far there are no such options however). kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Apr 19 06:43:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21398; Wed, 19 Apr 95 06:43:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21392; Wed, 19 Apr 95 06:43:45 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03403; Wed, 19 Apr 1995 06:35:23 -0700 Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA29462; Wed, 19 Apr 95 06:35:23 PDT Subject: (IPng 7) Do you mean ESP? To: alexl@vast.unsw.edu.au, IPng Mailing list Date: Wed, 19 Apr 1995 09:34:53 -0500 (EST) From: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9504191434.aa16557@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk You are asking about preparing an outgoing packet with the following: a) Authentication b) Encapsulation Do you mean Encapsulating Security Payload? If so, read on, otherwise, I think KRE had you covered in his answer. c) Fragmentation d) Add routing header and Hop-by-Hop header e) Destination option header I'd encode/encrypt/whatever your data (for example, a UDP datagram), then prepend an unfilled Authentication header, then prepend the routing header, then prepend the hop-by-hop header. Now that you have the whole packet, you perform the authentication calculation, and send the packet to your fragmentation engine, which finds the dividing point between pre- and post-fragment options (Hop-by-hop and routing are pre-fragment headers), and chop the post-fragment options and data (which is encrypted in an ESP) per fragment. Hope this helps. -- Daniel L. McDonald | Mail: danmcd@itd.nrl.navy.mil OR danmcd@cs.nrl.navy.mil + Computer Scientist | WWW: http://wintermute.cs.nrl.navy.mil/danmcd.html | Naval Research Lab | Phone: (202) 404-7122 #include | Washington, DC | "Rise from the ashes, A blaze of everyday glory" - Rush + ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Apr 21 13:53:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22814; Fri, 21 Apr 95 13:53:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22806; Fri, 21 Apr 95 13:53:46 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03849; Fri, 21 Apr 1995 13:45:20 -0700 Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA14738; Fri, 21 Apr 95 13:43:53 PDT Subject: (IPng 8) IPv4 prefix? To: IPng Mailing list , ngtrans@sunroof2.Eng.Sun.COM Date: Fri, 21 Apr 1995 16:35:15 -0500 (EST) From: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9504212135.aa19666@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I see conflicting values for the prefix that follows the v4 portion of an IPv6 address that denotes a v4 node. Is it ::FFFF: (according to Deering/Hinden's addressing document) or ::0000: (according to Gilligan's transition document)? Enquriring minds (and people who are rewriting PCB code) want to know. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Apr 21 16:26:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23085; Fri, 21 Apr 95 16:26:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23079; Fri, 21 Apr 95 16:26:36 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21814; Fri, 21 Apr 1995 16:18:10 -0700 Received: from mail1.digital.com by Sun.COM (sun-barr.Sun.COM) id AA14697; Fri, 21 Apr 95 16:17:33 PDT Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA23587; Fri, 21 Apr 1995 16:10:56 -0700 Received: by xirtlu.zk3.dec.com; id AA11805; Fri, 21 Apr 1995 19:08:15 -0400 Message-Id: <9504212308.AA11805@xirtlu.zk3.dec.com> To: ipng@sunroof2.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: (IPng 9) IPv6 Implementors Mail List and IPv6 Testing Date: Fri, 21 Apr 95 19:08:08 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk This message will go to ipng, dns, dhc, addrconf, ipsec, and sdrp mail lists. I will be setting up an IPv6 Implementors mail alias to provide a place to discuss: 1. Minimal Testing of IPv6 specifications (Level 1) 2. Extended Testing of IPv6 specifications (Level 2) 3. IPv6 Testing Scenarios 4. IPv6 Test Scripts In addition we will try to get implementors to chip in and work as a team on a set of test scripts for both Level 1 and Level 2 testing. And testing scenarios. One good test scenario is the Dan McDonald Dentist Office problem as an example. I just about have an outline and text complete that can be enhanced on the mail list once I get it set up regarding the above so we won't start from scratch. I will work with Bob Hinden on how we define an address space and if we can get a SIXBONE set up on the Internet. But in the interim we can use tunneling as INRIA and Digital have been doing already. There is a TCP/IP EXPO scheduled in San Jose Aug 8-12. I am trying to get an IPv6 show subnet so those that are ready can come and at least do Level 1 Testing. Please send your email address to bound@zk3.dec.com and I will add you to the list. Also, users please participate, I think we need real life scenarios that those of us could miss sitting in the code and specs very closely (e.g. myopic technical tunnel vision). thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Apr 21 17:10:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23119; Fri, 21 Apr 95 17:10:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23112; Fri, 21 Apr 95 17:10:17 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27389; Fri, 21 Apr 1995 17:01:51 -0700 Received: from venera.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA26054; Fri, 21 Apr 95 17:01:51 PDT Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 17:01:49 -0700 From: bmanning@ISI.EDU Posted-Date: Fri, 21 Apr 1995 17:00:25 -0700 (PDT) Message-Id: <199504220000.AA11751@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Fri, 21 Apr 1995 17:00:25 -0700 Subject: (IPng 10) Re: (IPng 9) IPv6 Implementors Mail List and IPv6 Testing To: bound@zk3.dec.com Date: Fri, 21 Apr 1995 17:00:25 -0700 (PDT) Cc: ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9504212308.AA11805@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Apr 21, 95 07:08:08 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > This message will go to ipng, dns, dhc, addrconf, ipsec, and sdrp mail > lists. you might want to add the IDRP folks as well... (You do want to route this stuff I assume) -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Apr 22 04:11:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23329; Sat, 22 Apr 95 04:11:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23323; Sat, 22 Apr 95 04:11:12 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24388; Sat, 22 Apr 1995 04:02:47 -0700 Received: from concorde.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA21710; Sat, 22 Apr 95 04:02:43 PDT 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 NAA16887; Sat, 22 Apr 1995 13:02:41 +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 NAA16524; Sat, 22 Apr 1995 13:02:40 +0200 Message-Id: <199504221102.NAA16524@givry.inria.fr> From: Francis Dupont To: Dan McDonald Cc: IPng Mailing list , ngtrans@sunroof2.Eng.Sun.COM Subject: (IPng 11) Re: (IPng 8) IPv4 prefix? In-Reply-To: Your message of Fri, 21 Apr 1995 16:35:15 CDT. <9504212135.aa19666@sundance.itd.nrl.navy.mil> Date: Sat, 22 Apr 1995 13:02:37 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: I see conflicting values for the prefix that follows the v4 portion of an IPv6 address that denotes a v4 node. Is it ::FFFF: (according to Deering/Hinden's addressing document) or ::0000: (according to Gilligan's transition document)? Enquiring minds (and people who are rewriting PCB code) want to know. => Today there are two *different* IPv4-embedded IPv6 address types: - ::FFFF: aka IPv4-mapped IPv6 addresses which are really IPv4 addresses of IPv4-only hosts injected into IPv6 domain in order to be able to use the same API for IPv4 and IPv6. For the PCB code they are really IPv4 addresses and IPv4 "old" functions must be called with the trail part. These kind of addresses are not supposed to be used on cables by dual stack hosts without the not yet specified translation stuff. - ::0000: aka IPv4-compatible addresses which are true IPv6 addresses with a special form used by SIT (IPv6 over IPv4) tunnels. For the PCB code they are regular IPv6 addresses. Only the SIT code needs to recognize them in order to setup "automatic" end-to-end SIT tunnels. For more confusion last year the two prefixes were reversed (:-). In fact there is a third kind of IPv4-* IPv6 address type which must be dealt with by the PCB code: it is the unspecified address :: ! The specs are not very clear on this point but a passive server bound to an unspecified address (common case) must be able to accept connection or packets from both IPv4 and IPv6 active clients. Regards Francis.Dupont@inria.fr PS: this is my personal current understanding only... ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Apr 24 10:39:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24060; Mon, 24 Apr 95 10:39:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24054; Mon, 24 Apr 95 10:39:11 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02182; Mon, 24 Apr 1995 10:30:40 -0700 Received: from concorde.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA16896; Mon, 24 Apr 95 10:30:40 PDT 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 TAA12588 for ; Mon, 24 Apr 1995 19:30:35 +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 TAA20266 for ; Mon, 24 Apr 1995 19:30:30 +0200 Message-Id: <199504241730.TAA20266@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 12) IPv6 experimental implementation Date: Mon, 24 Apr 1995 19:30:28 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk My IPv6 experimental implementation is freely available by anonymous FTP at ftp://ftp.inria.fr/network/ipv6/ It is based on NetBSD for Sparcs, a free Unix derived from 4.4BSD Lite. Unfortunately if you want to install the corresponding base NetBSD the world distribution host, ftp.netbsd.org (aka sun-lamp.cs.berkeley.edu) crashed this weekend and left the distribution tree in an incoherent state then you should wait a few days... Please send an E-Mail to me if you need more infos. Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Apr 26 07:22:46 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25213; Wed, 26 Apr 95 07:22:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25207; Wed, 26 Apr 95 07:22:38 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14865; Wed, 26 Apr 1995 07:14:06 -0700 Received: from ceres.fokus.gmd.de by Sun.COM (sun-barr.Sun.COM) id AA13847; Wed, 26 Apr 95 07:13:57 PDT Message-Id: <9504261413.AA13847@Sun.COM> Received: from fokus.gmd.de by ceres.fokus.gmd.de id <14591-0@ceres.fokus.gmd.de>; Wed, 26 Apr 1995 16:08:13 +0200 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 13) IPv6 Implementations X-Sun-Charset: US-ASCII Date: Wed, 26 Apr 1995 16:08:13 +0200 From: Lutz Henckel Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Does there exist any IPv6 Prototype Implementation for Solaris 2 or other UNIX-OS which is available for research purposes? Thanks Lutz ___________________________________________________________________ Lutz Henckel Address : Research Institute for Open Communication Systems GMD FOKUS, Hardenbergplatz 2, D-10623 Berlin, Germany Phone : ++49 / (0)30 / 254 99 - 237 Fax : ++49 / (0)30 / 254 99 - 202 X.400 : G=lutz;S=henckel;OU=fokus;OU=berlin;P=gmd;A=d400;C=de Internet : lutz.henckel@fokus.gmd.de WWW : http://www.fokus.gmd.de/usr/hel ___________________________________________________________________ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Apr 27 12:39:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26231; Thu, 27 Apr 95 12:39:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26225; Thu, 27 Apr 95 12:39:05 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22660; Thu, 27 Apr 1995 12:30:32 -0700 Received: from atlas.xylogics.com by Sun.COM (sun-barr.Sun.COM) id AA29664; Thu, 27 Apr 95 12:30:19 PDT Received: by atlas.xylogics.com id AA16950 (5.65c/UK-2.1-950310); Thu, 27 Apr 1995 15:18:23 -0400 From: Gary Scott Malkin Date: Thu, 27 Apr 1995 15:18:23 -0400 Message-Id: <16950.199504271918@atlas.xylogics.com> To: ietf-rip@xylogics.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng 14) RIPng Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk As many of you know, the latest RIPng spec is out as: draft-ietf-rip-ripng-01.txt I'd like to get any last comments on it before it goes to the IESG with the rest of the IPng drafts. ---------------------------------------------------------------------- Gary Malkin Cheap, Fast, Good (617) 272-8140 Pick two! ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Apr 28 04:48:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26725; Fri, 28 Apr 95 04:48:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26719; Fri, 28 Apr 95 04:48:45 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06694; Fri, 28 Apr 1995 04:40:11 -0700 Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA12587; Fri, 28 Apr 95 04:40:08 PDT Received: from Q.icl.co.uk by flow.pipex.net with SMTP (PP); Fri, 28 Apr 1995 12:38:10 +0100 Received: from relay1.pipex.net by Q.icl.co.uk (4.1/icl-2.12-server) id AB00817; Fri, 28 Apr 95 12:42:22 BST From: x.gosselin.rea0803@oasis.icl.co.uk Received: from trojan.oasis.icl.co.uk by ming.oasis.icl.co.uk over SMTP id KAA21484; Fri, 28 Apr 1995 10:17:50 GMT Message-Id: <9504281001.AA16137@getafix.oasis.icl.co.uk> Date: Fri, 28 Apr 95 11:01:45 BST Reply-To: x.gosselin.rea0803@oasis.icl.co.uk Subject: (IPng 15) Internet Securiy Interoperability: Final year project To: ipsec@ans.net To: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I'm a computing student, and in October I'll start my final year. I start collecting information for my project. On of my lecturer told me "check what already exist before rushing everywhere", so I follow his advise : This study will identify the variables which affect secure interworking in the Internet environment, and develop a model for achieving interoperability at different layers in the Internet Protocol Suite. I will work on IPv4 and on the emerging work on Internet key management (IPv6), Domain Name Service Security, network management security and initiatives for common authentication in the application layer. * Does anynome know if a similar project is in progress somewhere or has already been done ? * Some recommendations ? * Some ideas ? * Some advises ? I don't want copy the work of someone else but I'd like studying what already exist and what people thinks about that, to develop my own model by taking considerations of everyone. Thanks for your help Xavier Gosselin ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Apr 28 10:41:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26877; Fri, 28 Apr 95 10:41:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26871; Fri, 28 Apr 95 10:41:49 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06732; Fri, 28 Apr 1995 10:33:14 -0700 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA15239; Fri, 28 Apr 95 10:33:14 PDT Received: from vbormc.vbo.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA03113; Fri, 28 Apr 95 10:29:14 -0700 Received: by vbormc.vbo.dec.com; id AA05933; Fri, 28 Apr 95 19:19:49 +0200 Message-Id: <9504281719.AA05933@vbormc.vbo.dec.com> Received: from nestvx.enet; by vbormc.enet; Fri, 28 Apr 95 19:19:50 MET DST Date: Fri, 28 Apr 95 19:19:50 MET DST From: Markus Jork To: ipng@sunroof.Eng.Sun.COM Cc: jork@nestvx.enet.dec.com Apparently-To: ipng@sunroof.eng.sun.com Subject: (IPng 16) Neighbor Discovery and ATM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk At the last IETF, Bill Simpson promised to rewrite the discovery spec for better understandability. I couldn't wait and, based on the latest spec I had around (draft-simpson-ipv6-discov-process-02.txt), made an attempt to see how neighbor discovery would work on an ATM network. The Neighbor Discovery mechanism tries to utilize multicasting whenever possible. Unless it has some idea about the destination from the past. In that case, it sends a unicast General Solicitation message directly, assuming that nothing has changed. There is still no IP multicasting over ATM but work is in progress. I am assuming here that it will at least resemble the mechanism described in draft-ietf-ipatm-ipmc-04.txt: To find out where to send an IP multicast datagram, a Multicast Address Resolution Server (MARS) is asked. The request contains the IP address and the reply provides us with a list of ATM addresses. These might be the ATM addresses of all nodes in the multicast group or the ATM addresses of multicast servers. It doesn't matter. A point-to-multipoint VC can be opened and the datagram is send out. Ok, now what's happening when host A wants to send a unicast datagram to host B on the same ATM network and host A doesn't know B's ATM address? When there's no router on the ATM network, a General Solicitation is send to an IP multicast address computed out of B's IP address. This is quite clever and for any IEEE 802 type LAN this IP multicast address can easily be mapped to a corresponding link layer muliticast address. In the case of ATM, however, we need to ask MARS. MARS provides us with a list of ATM addresses. We have to open a point-to-mulitpoint VC to these addresses, finally send the Solicitation out and wait for B to respond with an Advertisement. For this General Advertisement, B either has to open a VC to A or send it as an All-Nodes multicast. When A knows that there's a router somewhere on the ATM network, it doesn't need to send a General Solicitation. Instead, it lets the router do all the work by sending the datagram to the router and waiting for a redirect. It seems this would just shift the problem from one place to the other. Or is there some other magic associated with a router that solves the address resolution problem more elegantly? So does all this make sense? Especially when compared to the IPv4 ATMARP model which is simpler and much more efficient. Note that in either case you would have to manually configure the address of some kind of address resolution server. So there's also no advantage for Neighbor Discovery considering this issue. What is the problem here? a) I don't understand Neighbor Discovery and I got something wrong in my description above. b) My assumption about IP over ATM multicasting is wrong and there will be some other way in IPv6 which perfectly supports Neighbor Discovery. c) Neighbor Discovery was designed with ATM in mind but with the misconception of an Ethernet-like multicasting mechanism. If c) is true: are we doing it anyway? Does Neighbor Discovery need redesign? Or should we fall back into using an ATMARP like mechanism? Markus ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Apr 28 12:10:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26991; Fri, 28 Apr 95 12:10:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26985; Fri, 28 Apr 95 12:10:37 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18308; Fri, 28 Apr 1995 12:02:01 -0700 Received: from nbkanata.newbridge.com (Newbridge.COM) by Sun.COM (sun-barr.Sun.COM) id AA03904; Fri, 28 Apr 95 12:02:01 PDT Received: from thor.Newbridge.com by nbkanata.newbridge.com (4.1/SMI-4.1) id AA11252; Fri, 28 Apr 95 15:00:06 EDT Received: from mako.newbridge.com by thor.Newbridge.com (4.1/SMI-4.0) id AA15745; Fri, 28 Apr 95 15:00:20 EDT Received: from lobster.Newbridge.COM by mako.newbridge.com (4.1/SMI-4.1) id AA05943; Fri, 28 Apr 95 14:59:19 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA15749; Fri, 28 Apr 1995 14:59:40 +0500 Date: Fri, 28 Apr 1995 14:59:40 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9504281859.AA15749@lobster.Newbridge.COM> To: ipng@sunroof.Eng.Sun.COM, jork@nestvx.enet.dec.com Subject: (IPng 17) Re: Neighbor Discovery and ATM X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk If I understand Mr. Jork's proposal, he suggests using a multicast server to send out neighbor discovery frames to a "subnet" over ATM. While this is possible, I think it is the wrong model. There are two approaches which I think work better. Approach 1 is to do what RFC 1577 does for IP/ATM. Everyone in a subnet registers with the ARP server for that subnet. And queries are sent to the ARP server. Work is underway to generalize this to multiple arp servers so that redundancy is possible. Approach 2, which I like better, is to use the NHRP model. This is very similar from the point of view of the host. The difference is that the ATM attached host never learns about a subnet mask. No matter what the destination, a query is sent to the local server for resolution. This model works with the general view that subnets on ATM are for restricting broadcast scopes for useful broadcasts. Address resolution and "neighborness" should have nothing to do with such restrictions (excepting of course where the site administrator wants such boundaries). Both of these move the neighbor discovery away from using multicast, which is important when operating over a non-broadcast media. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Apr 28 17:10:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27225; Fri, 28 Apr 95 17:10:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27219; Fri, 28 Apr 95 17:10:14 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22580; Fri, 28 Apr 1995 17:01:36 -0700 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA28636; Fri, 28 Apr 95 17:01:35 PDT Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA17646; Fri, 28 Apr 95 20:00:02 EDT Received: from cabernet.wellfleet by wellfleet (4.1/SMI-4.1) id AB01303; Fri, 28 Apr 95 20:04:46 EDT Date: Fri, 28 Apr 95 20:04:46 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9504290004.AB01303@wellfleet> To: minutes@CNRI.Reston.VA.US Subject: (IPng 18) Draft Minutes of IPng Working Group Cc: dlegare@CNRI.Reston.VA.US, ipng@sunroof.Eng.Sun.COM, rcallon@pobox.wellfleet.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Enclosed are the draft minutes for the IPng working group meeting at the IETF. Sorry for the delay. I haven't gotten any comments back from Bob or Steve (making me suspect that either they are vacationing on a Caribean island, drinking too much vodka in Eastern Europe, or that someone's mailer isn't working). Comments should be sent ASAP to me, Steve, and Bob. Thanks, Ross ------------------------------------------------------------ Minutes from the IPng working group The main agenda item was to review the documents which were (hopefully) ready to go to proposed standard status. The authors of each document presented the status of the document, and any changes that have been fixed due to the last call process. The hope/goal is to prepare these documents to go forward as proposed standards immediately following this IETF. After these documents are done, one of the next "major piece of work" is to straighten out mobility for IPv6. This however was not planned for this IETF. There is still some thrashing out to be done by the IESG regarding which group is to complete the work on IPv6 mobility (eg, the IPv4 mobility group, the IPv6 group, or a new group). Core IPv6 documents to be reviewed / progressed: IPv6 base spec (Steve Deering) addressing architecture (Bob Hinden) unicast addressing architectre (Yakov Rehkter) unicast addressing format (Yakov Rehkter) ICMPv6 (including IGMP; Alex Conta) security (Ran Atkinson) DNS (Sue Thompson) neighbor discovery (Bill Simpson) Masataka Ohta requested a discussion of alternative unicast addressing methods. This was added to the agenda. Brian Carpenter raised the issue of the ultimate authority for the IPv6 address space, which it has been suggested rests with the IANA (Internet Assigned Numbers Authority). This was included under the extended addressing discussion. Steve Deering: IPv6 Base Specification Issues brought up as a result of the last call incluce: - How higher levels compute pseudo headers if the jumbogram option is included. This is straightforward and was fixed prior to the IETF. - Destination Options Type that identifies the Destination Options Header was assigned number 60. - The source routing header that was submitted as last call included a bit mask. There was a minor error, related to which bit applied to which address in the source route. This again was corrected. - It was proposed to ban the use of the Jumbo Payload option for packets which are smaller than 64k (ie, which do not require the Jumbo option). Question: How does the group feel about this (clearly either would work)? If we ban the use of Jumbo Payload option for smaller packets, this would allow implementations to not implement this unless they are attached to links which can handle large datagrams. There was consensus on banning the use of the option for small packets. We agreed to add a note that if you don't implement this option, then you restrict the use of your implementation on links which can handle larger packets. - The recording of the path during forwarding of source routed IP packets has not been carried over to IPv6 (you just swap addresses, leaving the original list of addresses in the packet rather than replacing them with the addresses of the outgong interfaces). One motivation for this is that cluster addresses want to be left alone (you might not go back via the same routers, even if you do go back via the same clusters). This relates to the reversing of source routes. A suggestion is that you don't reverse the source route if there is any route available. The consensus if to leave this as it is in the spec. - The relative ordering of the authentication and fragmention header: A concern is that if you first reassemble and then authenticate, then bogus fragments can break the whole packet (representing a denial of service attack). However, if you authenticate fragments, then bogus fragments are discarded, and the correct fragments can be reassembled (with more overhead). The current approach allows either order, but recommends authenticating the entire packet (not each fragment). However, authenticating the entire packet (rather than each fragment) implies substantially less overhead. Consensus: the spec is already clear that implementations must be able to receive packets in either order. The current order is fine in terms of what is recommended to be sent. Thus no change is necessary. - In the introduction of the spec there is a reference to the "region address". This needs to be either removed or changed to "Anycast address". The one corresponding sentence needs to be fixed. Author's choice regarding how to fix this (this is an editorial nit). - ERP (Explicit Routing Header): This is not currently in the base spec in detail. The Route header in the base spec will remain compatible with the current state of Explicit Routing Header format, by reserving the space but not defining the flag fields. The proposal is that this is not ready to be added, and therefore should not be added to the base spec. Consensus is to leave the spec the way that it is. - Privacy header: Why isn't the code point in the IPv6 protocol spec? This is largely a style issue (given that the privacy header is specified in one of the base documents which will go to proposed standard). Bill Simpson proposed removing the authentication header from this spec also, and have all security, authentication, and privacy stuff in other specs. The consensus was to delete the authentication header section in the IPv6 protocol spec, except to include mention of authentication and ESP headers in the order of headers section. It was also agreed to have a small section listing all the existing header types, but referring for code points back to assigned numbers. Bob Hinden: Addressing Architecture Output of the PARC meeting was listed as document version -01. However version -02 just came out since based on comments received, but didn't quite get to ID (came out at the last minute). Bob therefore described the delta between the -01 (just after PARC interim meeting) and the -02 version. - Loopback address: An explicit note will be added that a packet addressed to the loopback address is never sent out of a single node. What it means to be a "node" or "device" is up to the implementor of the node/device. - The definition of the term "nearest" is somewhat unknown. The notion is that this is "According to the routing protocol's measure of distance". The word "nearest" will be surrounded by quotes in the spec, as a minor clarification. - The scopes for multicast addresses was discussed. It was agreed to remove the notion of a "community" scope. - Directed multicast (ie, a multicast as the last entry of a source route): This is dis-allowed intentionally in the spec. This is a problem due to the fact that the directed multicast would have the wrong source address to work correctly with current multicast routing protocols. Thus the currect text is correct. A different (future) mechanism would be needed for directed multicast. - Won't local use prefixes need to be predefined? Yes, Bob will add this to the document. - Question: What about clusters, packs, anycast, etc (whatever it is called this week)? Anycast goes to the nearest (or some one) of a group. Cluster is a special constrained form of anycast, applied to any address prefix. There was a problem with cluster addresses related to how a cluster address was identified. The Pack proposal was to generalize how a particular address was chosen to be the pack address corresponding to a particular prefix, plus some generalization of topological restriction. The name was changed to region, and folks noticed that the definition of regional addresses had been generalized to be nothing more than a renamed anycast address (perhaps made more complex). Thus, we now have returned to just having Anycast addresses. Any unicast address can be assigned to more than one machine, which cause it to become an anycast address. Any machine to which an anycast address has been assigned must know that this is an anycast address. There is a proposal to assign a particular anycast address to the set of all routers on any subnet. Bob will add a clarification of the anycast addresses to the current document. There followed a lengthy discussion of a possible multicast address space proposed by Masataka Ohta. It was agreed that this was an interesting proposal that is worth discussing and considering in the future, but that we will not be able to resolve the scheme and understand its implications in this meeting, and therefore should go forward with the base spec as it currently stands. We would like Mr Ohta's proposal to be written up in more detail and distributed prior to the next IETF (clearly it is beneficial to have an Internet Draft early enough to allow considerable discussion and comments prior to any particular IETF). We agreed to progress the first two documents (IPv6 base spec, IPv6 addressing architecture). We therefore started a discussion of the provider based addressing specifications (the two documents by Yakov Rehkter). There was considerable discussion pro and con. this was basically based on whether people like provider based addresses. The basic opinions ranged from "provider based addressing is the best that we know how to do" to "provider based addresses are not ideal in many ways". The continuation of this discussion was postponed to later. Alex Conta: ICMPng (including IGMP) There were several typos and spelling errors corrected. References to ICMP were replaced with ICMPv6 (different protocol value). Section 2, introductory section entitled ICMP for IPv6, was divided into several subsections: - message general format - meesage source address determination - message checksum calculation - message processing runed TBD fields were replaces with the ICMPv6 next header value (58). Source address determination was clarified in the case of error reports sent in response to a packet with an anycast destination address. Also in the case of "destination unreachable -- communication administratively prohibited" or "destination unreachable -- address unreachable", and "Address Too Big". There was some concern that this is somewhat complex, and/or not so clear. The consensus is that we will add a sentence saying essentially "use the address which returns the most information", then say "for example..." and include the current text with "should" instead of "must". Fields used in the checksum computation have been clarified in the case of a Jumbogram. (question, would there every be an ICMP jumbogram -- yes, if it were a ping; thus it is worth specifying what to do in this case). The handling of unknown error messages was separated from the handling of unknown informational messages. Similarly, references to ICMP messages in general was clarified to separate error and informational messages. Some minor editorial corrections were discussed. An error message was added for the case of strict source routing when the next hop is not a neighbor. Source address determination was clarified for time exceeded message. The pointer for use in parameter problem message was also clarified. The consensus was that ICMP is ready to go to proposed standard. DNS (AAAA records): Sue Thompson Bill Fink was proposing to split the addresses into two pieces: A provider part plus a rest (local) part. then if you change providers, you change the higher level part only. Question: Why not just assign addresses this way: So that when you change only the provider part, you only change one entry in DNS, not all addresses for one domain. However, this seems to be a research topic. Bill Simpson thinks that we have discussed this for a long time, and he doesn't want to get back to it now. Consensus: The DNS for IPv6 document is ready to go to proposed standard, and represents the state of the art today. Additional work may go on as experimental. The earlier discussion at the Palo Alto interim meeting and on the mailing list about replacing the reverse tree lookup was not extended by the working group. The WG decided that the current text on reverse tree was acceptable for elevation of the spec to proposed standard, and that future design of secure, less cumbersome approaches would not be precluded by starting from this point. Bill Simpson: Neighbor Discovery A significant issue here is the handling of the node heard mechanism. It has been suggested that there is not enough explanation in the neighbor discovery spec regarding why the document is written the way that it is. When router discovery was being defined, they went through existing protocols and decided what they liked, what they didn't like, and what they were trying to solve. They wanted neighbor discovery to work for a wide range of types of networks. A lot of thought has gone into Neighbor discovery for Non-Broadcast Multi Access media (NBMA): Here you cannot necessarily hear folks who can hear you. Also, neighbor discovery needs to work in a no-router environment, and in via-a-router-when-necessary environment. Neighbor discovery specifies: - the manner for a node to solicit another node (using a certain multicast address hashed from IPv6 address) - the manner for a node to answer another node (using all nodes multicast) The neighbor discovery messages include an indication of link quality. It was agreed that a link quality value needs to be defined for the case when the interface is not able to measure the link quality (the node can specify a zero error rate, the link quality is then assumed to be good). Suggestion: Allow solitication to be unicast if the address is known. Also, allow response to also be sent using unicast. Issue: if overhearing the other guys messages is a sustantial advantage, then the node heard field is useless. Brian Carpenter: Doubt in NMBA case (eg, look at 1577) that use of multicast / broadcast is dubious. A different model is necessary for some NBMA networks (ATM, for example). Several comments were made regarding whether node heard should be in the packet. Some folks would like to remove node heard. If there is a problem is that you might have heard from too many folks implying too long a list, you could put an indicator which says "lots of folks" in the packet without being specific (however, the notetaker thinks that Bill Simpson explained that you will never have such a long list in the "node heard" field -- there was some misunderstanding in the room on this issue). In the general case (where subnet does not provide cheap multicast) when a router is there, (suppose node A is attempting to contact node B): A just sends data to a router. The router then looks for B (The apparent notion is that routers have to find the hosts anyway). However, in sending the solicitation the router semi-lies, using its own link address along with host A's IPv6 address in the solicitation. B responds with a response sent to the all nodes multicast address, which should imply that A will receive it. It was suggested that non-transitive or non-reflexive failures can also happen (with significant frequency) on Ethernet. A proposal was made that node-heard should be in a separate document (which might not apply to all types of links). The term "Asymmetric reachability" as used includes error cases: "A can hear B but B can't hear A", and "A can hear B and B can hear C but A can't hear C". Bill is assuming that ATM will solve the multicast / broadcast issue (ie, allow efficient multicast over ATM). However, it appears to the notetaker that if ATM does not come up with a multicast that one would actually want to use in this case, then an alternative approach may be necessary. Further discussion of neighbor discovery was deferred to later in the week. IPv6 Security: Ran Atkinson Delta's since last time: - merged IPv6 and IPv4 work since differences were minor. - moved next header field to the end of the encrypted data - someone came up with a transform that perserves 64 bit alignment - changed the way the MD-5 hash was computed - moved transforms into separate more clearly written drafts. Jim Bound has a major objection to having this go forward as a proposed standard. His issue is that security being a MUST forces him to build a non-exportable product. There is some question as to whether DES is really exportable (with a license) or not. There appears to be some strong feeling that security is needed, and that exportability is needed. After some discussion, it was agreed: agreed: From a technical perspective, security including privacy must be implemented, and is needed for Internet commerce to work. agreed: Some users from outside the US have expressed an interest in purchasing systems which include security. IPNG, continued Wednesday late afternoon Two issues were left: neighbor discovery and addressing Masataka Ohta presented his reason for being opposed to progression of the two provider-based addressing documents (by Yakov Rehkter). He is against progressing provider based addressing to proposed standard because it contains known problems. This will lead to a compatibility problem when we have to change addresses in the future. Also using part of the address space for provider based addresses is a potential waste of space if we assign a significant part of the addressing space to addresses which will become obsolete. Ohta presented some aspects of his proposal. However, we did not get into enough detail for the minute taker to be sure that he understood what was being proposed. Matt Crawford pointed out that the entire address guarantees global uniqueness, not just the low order part. Also, 46 bits (the useful part of the IEEE space) is much larger than 10^12th (the anticipated eventual size of the Internet). Brian Carpenter, and then the group as a whole, agreed with Ohta's suggestion to do initial assignment conservatively, to preserve as much as possible of even the provider-based IPv6 space. There are two places where this should be done: Assignments of prefixes to providers, and assignments from providers to sites. There was strong agreement that we need to continue addressing work. The provider-based documents that Yakov has written are NOT the end point. Bill Simpson is opposed to publishing the provider based addressing documents as proposed standards. He feels that architecture draft is incorrect. He does not feel that there are multiple interoperable implementations. He questioned whether we need address assignment for initial experimentation with IPv6. Rather, we should plan on telling folks that they are going to have to renumber in order to do initial experimentation with IPv6. A gentleman from the national institute of health is concerned about renumbering. For example, this could happen if your connection is moved within a provider. Renumbering is going to be hard in spite of our efforts. Support for renumbering needs to be in place before the wide deployment of IPv6. There are really four issues: Addressing; multiple addresses for an interface (multi-homed addresses); how is local portion of address assigned; how does all this work with DHCP. A proposal was made that the addressing document should be **really** a request for comments (as opposed to an "RFC", which is of course often interpreted as a "standard"). Ross was concerned that we haven't heard any new arguements for a year plus. In the Internet tradition, when we don't have a perfect solution and we aren't making progress, we have to go with the best that we have (regardless of however imperfect that may be). We will then learn from our experience. An informal show of hands regarding whether the architecture draft should be published as an RFC in some form: yes by about 3 to 1, with a lot of abstentions. Informational was the rough consensus regarding which form the document should take. Same informal show of hands but regarding the address assignments: There has already been a rough consensus on adding text regarding conservative assignment. Overwheming support for publishing in some form. Also consensus that it should be informational. We then continued with neighbor discovery: Several folks had questions regarding detailed operation, and presented detailed examples so that Bill Simpson could explain the protocol operation. Erik Nordmark brought up an example with two routers (R1 and R2) and two hosts (A and B). A can hear R1, but R1 cannot hear A (ie, there is an error in the net, the type of error that node heard is intended to fix). A and R2 can hear each other correctly. Erik's interpretation of the spec is that A will end up picking one of the two routers according to a criteria, and may pick R1. However, when A tries to send the packet to R1, it doesn't arrive. How does node heard fix this problem? Bill's response: this has nothing to do with node heard, and node heard is not supposed to fix this. If R1 has a higher preference than R2, this just won't work. This lead to the counter-question: What does node heard do then? (apparently it is useful in the host to host case). There seemed to be a significant amount of discomfort and lack of understanding of the approach (including amongst some implementors who had read the spec), which is clearly different from there being known problems. There were some folks who feel that this is no worse than and probably an improvement over what we have now (ARP). Matt Crawford suggested that we might need "router discovery light" and "router discovery dark". John V. was hearing that this is a complicated problem, that is not fully understood and not fully explained in the current document. Some implementors in this room are saying that they are not comfortable. We need to either strip this protocol down to something better understood, or make it (whether the description or the protocol) more complete. The AD suggested that we need a well understood protocol which does the equivalent of both ARP and Router Discovery for networks which don't need to survive assymetric reachability. Ross suggested that if we are uncertain about the node heard mechanism, then the spec should be very clear about what an implementation should do if it expects the field and it is missing, or vice versa (so that we have the option of changing the mechnism in the future). Steve would prefer a small set of protocols for a small set of overall basic network types (ie, not just one mechanim for all links, but not a separate mechanism for every single type of subnetwork either). Bill Simpson agreed to excise node heard, and questioned how much that will simplify things. There appear to be two issues: Clarity of document, and correctness of (or comfort with) the technical approach. The group expressed (by show of hands) a mild preference for taking node heard out of the document, and putting into another document. We haven't reached a consensus. Bill will revise the document. We will put it out for working group last call. Bill will not put it out for three weeks. The working group official editor (Bob Hinden) offered to make an effort to edit the document for completeness and clarity. It was left somewhat unclear how Bob and Bill would interact on this (although presumeably they can work this out offline). We may need an interim meeting: This will be arranged offline. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Apr 29 02:19:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27528; Sat, 29 Apr 95 02:19:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27522; Sat, 29 Apr 95 02:19:36 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12440; Sat, 29 Apr 1995 02:11:02 -0700 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA04617; Sat, 29 Apr 95 02:10:59 PDT Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Sat, 29 Apr 1995 18:08:46 +0859 From: Masataka Ohta Message-Id: <199504290909.SAA22116@necom830.cc.titech.ac.jp> Subject: (IPng 19) Re: Neighbor Discovery and ATM To: jork@nestvx.enet.dec.com (Markus Jork) Date: Sat, 29 Apr 95 18:08:44 JST Cc: ipng@sunroof.Eng.Sun.COM, jork@nestvx.enet.dec.com In-Reply-To: <9504281719.AA05933@vbormc.vbo.dec.com>; from "Markus Jork" at Apr 28, 95 7:19 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > At the last IETF, Bill Simpson promised to rewrite the discovery spec > for better understandability. I couldn't wait and, based on the latest spec I > had around (draft-simpson-ipv6-discov-process-02.txt), made an attempt to see > how neighbor discovery would work on an ATM network. As I pointed out at the meeting, ATM neighbour discovery works only when you pre-configure what the neighbour is. That is, with the practical sense of terminology, neighbour discovery does not work. > The Neighbor Discovery mechanism tries to utilize multicasting whenever > possible. ATM multicasting is possible by manually configuring a multicast server. Or, you can automatically configure multicasting by manually configuring the location of automatic-multicast-configure server. :-) > There is still no IP multicasting over ATM but work is in progress. I am > assuming here that it will at least resemble the mechanism described in > draft-ietf-ipatm-ipmc-04.txt: To find out where to send an IP multicast > datagram, a Multicast Address Resolution Server (MARS) is asked. The problem is that, with LIS model, where logical topology is different from physical topology, address of MARS can not be well known. NHRP makes everything more complicated and needs a lot more configuration but solves no configuration issues. > What is the problem here? > a) I don't understand Neighbor Discovery and I got something wrong in my > description above. > b) My assumption about IP over ATM multicasting is wrong and there will be some > other way in IPv6 which perfectly supports Neighbor Discovery. > c) Neighbor Discovery was designed with ATM in mind but with the misconception > of an Ethernet-like multicasting mechanism. > Both IPv4 ARP and IPv6 neighbor discovery are good enough. The problems are in ATM. > It seems this would just shift the problem from one place to the other. Or is > there some other magic associated with a router that solves the address > resolution problem more elegantly? If we seriously think IP should work over ATM without extra manual configuration effort, we had better request ATM forum that all ATM switches should support spanning tree algorithm for broadcast or, at least, all-IP multicast without any manual configuration. The problem is that, people of phone companies take it granted that they have the priviledge to be paid to configure their equipments and don't want it be automatic. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Apr 29 03:57:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27552; Sat, 29 Apr 95 03:57:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27546; Sat, 29 Apr 95 03:57:28 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13502; Sat, 29 Apr 1995 03:48:54 -0700 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA10523; Sat, 29 Apr 95 03:48:43 PDT Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Sat, 29 Apr 1995 19:46:41 +0900 From: Masataka Ohta Message-Id: <199504291046.TAA22547@necom830.cc.titech.ac.jp> Subject: (IPng 20) Re: Re: Neighbor Discovery and ATM To: jhalpern@Newbridge.COM (Joel Halpern) Date: Sat, 29 Apr 95 19:46:39 JST Cc: ipng@sunroof.Eng.Sun.COM, jork@nestvx.enet.dec.com In-Reply-To: <9504281859.AA15749@lobster.Newbridge.COM>; from "Joel Halpern" at Apr 28, 95 2:59 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Approach 1 is to do what RFC 1577 does for IP/ATM. Everyone in a subnet > registers with the ARP server for that subnet. It works as long as the address of the ARP server is preconfigured. > Approach 2, which I like better, is to use the NHRP model. This is very > similar from the point of view of the host. The difference is that the > ATM attached host never learns about a subnet mask. No matter what the > destination, a query is sent to the local server for resolution. It requires that the address of the local (note, it is logically, not physically, local so that it can not be automagically reached with a well know address) server is preconfigured. But, don't forget that NHRP has a lot of other problems such as stable routing loops, lack of security ... > Both of these move the neighbor discovery away from using multicast, which > is important when operating over a non-broadcast media. It implies that you can't multicast if you can't broadcast. The simplest and the easiest way to go is to make ATM broadcast media. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Apr 29 06:51:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27590; Sat, 29 Apr 95 06:51:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27584; Sat, 29 Apr 95 06:50:59 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17822; Sat, 29 Apr 1995 06:42:25 -0700 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA15470; Sat, 29 Apr 95 06:41:08 PDT Received: by rodan.UU.NET id QQynog11930; Sat, 29 Apr 1995 09:41:02 -0400 Message-Id: To: Masataka Ohta Cc: jork@nestvx.enet.dec.com (Markus Jork), ipng@sunroof.Eng.Sun.COM Subject: (IPng 21) Re: Re: Neighbor Discovery and ATM In-Reply-To: Your message of "Sat, 29 Apr 1995 18:08:44 +0200." <199504290909.SAA22116@necom830.cc.titech.ac.jp> Date: Sat, 29 Apr 1995 09:41:02 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The fact that neighbor discover doesn't work unless the underlying fabric can do some kind of broadast or multicast is neither surprising nor particularly troubling. All this means is that some types of fabric are not well-suited to some uses without significant assistance in the form of "ARP servers" or some such. It is certainly NOT an indictment of "neighbor discover" in general. While it might be nice in the abstract for neighbor discovery to be able to search out and configure an entire network of routers, I would certainly never use it that way and would recommend in the strongest possible terms that it NEVER be used that way. Nothing is more terrifying that to watch a run-away "network discovery virus" get lose on a large, fast network. The notion that it would also "help you" by fiddling with addresses gives me cold sweats. So neighbor discovery doesn't work when there are no directly reachable neighbors. This doesn't sound broken to me. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Apr 30 20:13:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28036; Sun, 30 Apr 95 20:13:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28030; Sun, 30 Apr 95 20:13:43 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB26551; Sun, 30 Apr 1995 20:05:04 -0700 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA12295; Sun, 30 Apr 95 20:05:04 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Mon, 1 May 1995 13:01:52 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Mon, 1 May 1995 13:03:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Mon, 1 May 1995 13:00:54 +1000 Date: Mon, 1 May 1995 13:00:54 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof2.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL May 01 13:00:54 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 530013010595 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <530013010595*/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 22) Re: Draft Minutes of IPng Working Group Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >Jim Bound has a major objection to having this go forward as a proposed >standard. His issue is that security being a MUST forces him to build a >non-exportable product. I don't see the problem. Either the law will change or the companies will produce off shore. You can't build standards based on laws in one country or another. > There is some question as to whether DES is really >exportable (with a license) or not. There appears to be some strong feeling >that security is needed, and that exportability is needed. The issue was importability. Build off shore and import to the US and I am sure that laws will change. >After some discussion, it was agreed: > agreed: From a technical perspective, security including privacy must > be implemented, and is needed for Internet commerce to work. > agreed: Some users from outside the US have expressed an interest in > purchasing systems which include security. Surely the international nature of the Internet drives the argument that the issues for security are the same for the rest of the world as for the US. Trade is a major target for espionage which even governments engage. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com