From owner-ipng Mon Oct 2 07:51:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10425; Mon, 2 Oct 95 07:51:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10419; Mon, 2 Oct 95 07:51:31 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03502; Mon, 2 Oct 1995 07:39:22 -0700 Received: from venera.isi.edu by mercury.Sun.COM (Sun.COM) id HAA19310; Mon, 2 Oct 1995 07:39:23 -0700 From: bmanning@ISI.EDU Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 2 Oct 1995 07:39:18 -0700 Posted-Date: Mon, 2 Oct 1995 07:36:14 -0700 (PDT) Message-Id: <199510021436.AA11797@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Mon, 2 Oct 1995 07:36:14 -0700 Subject: (IPng 707) Re: WG Last Call: Address Formats & Experimental Allocation (fwd) To: ipng@sunroof.Eng.Sun.COM Date: Mon, 2 Oct 1995 07:36:14 -0700 (PDT) Cc: cidrd@iepg.org 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 Hi, I saw a fairly impressive demo of a couple of IPv6 stacks last week. One item jumped out at me that needs clarification. I think that this was talked about previously, and that someone has agreed to write up a simple explaination, which I have not yet seen. The item was the interface configuration. It was somthing like: ::45.35.130.13/118 which implies, to me, CIDR style masking. If this is the case, how small a value is allowable? Can we have, say, ::39.2.118.6/24 or smaller? --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 2 08:52:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10488; Mon, 2 Oct 95 08:52:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10482; Mon, 2 Oct 95 08:51:59 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09774; Mon, 2 Oct 1995 08:39:48 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id IAA02531; Mon, 2 Oct 1995 08:39:40 -0700 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 QAA07944; Mon, 2 Oct 1995 16:36:09 +0100 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 QAA21645; Mon, 2 Oct 1995 16:36:08 +0100 Message-Id: <199510021536.QAA21645@givry.inria.fr> From: Francis Dupont To: bmanning@isi.edu Cc: ipng@sunroof.Eng.Sun.COM, cidrd@iepg.org Subject: (IPng 708) Re: WG Last Call: Address Formats & Experimental Allocation (fwd) In-Reply-To: Your message of Mon, 02 Oct 1995 07:36:14 MST. <199510021436.AA11797@zed.isi.edu> Date: Mon, 02 Oct 1995 16:36:05 +0100 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: I saw a fairly impressive demo of a couple of IPv6 stacks last week. One item jumped out at me that needs clarification. I think that this was talked about previously, and that someone has agreed to write up a simple explaination, which I have not yet seen. The item was the interface configuration. It was somthing like: ::45.35.130.13/118 which implies, to me, CIDR style masking. => yes, / gives the IPv6 mask with one bits and 128- zero bits. This restricts netmask to this particular form but it is what we want! If this is the case, how small a value is allowable? => obviously valid values must be between 0 and 128 (bounds included). Can we have, say, ::39.2.118.6/24 or smaller? => yes but with an IPv4-compatible IPv6 address only prefix lengths between 96 and 128 have an useful meaning... This syntax has already been proposed and accepted (in fact everybody used it :-). I have some code for decoding it for the nslookup tool (and you should find several other instances of it elsewhere). 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 Mon Oct 2 20:33:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10980; Mon, 2 Oct 95 20:33:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10974; Mon, 2 Oct 95 20:33:35 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07025; Mon, 2 Oct 1995 20:21:02 -0700 Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id UAA04324; Mon, 2 Oct 1995 20:20:26 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA31121; Mon, 2 Oct 1995 20:12:41 -0700 Received: by xirtlu.zk3.dec.com; id AA02151; Mon, 2 Oct 1995 23:12:27 -0400 Message-Id: <9510030312.AA02151@xirtlu.zk3.dec.com> To: hinden@ipsilon.com (Bob Hinden) Cc: ipng@sunroof.Eng.Sun.COM, addrconf@cisco.com, bound@zk3.dec.com Subject: (IPng 709) Re: IPng and AddrConf Interm Meeting Location and Travel Info In-Reply-To: Your message of "Wed, 27 Sep 95 17:28:16 PDT." Date: Mon, 02 Oct 95 23:12:21 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Bob, Is ND the only item on the agenda? Not fair to have addr conf now I think cause we should have been able to have some mail discussion for those that are not coming. How about start/stop times too? Can we get a list of the potential attendees to us too? 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 Tue Oct 3 08:49:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11273; Tue, 3 Oct 95 08:49:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11267; Tue, 3 Oct 95 08:49:44 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15190; Tue, 3 Oct 1995 08:37:14 -0700 Received: from world-net.sct.fr by mercury.Sun.COM (Sun.COM) id IAA22060; Tue, 3 Oct 1995 08:32:11 -0700 Received: from client86.sct.fr (client86.sct.fr [194.2.128.116]) by world-net.sct.fr (8.6.12/8.6.10) with SMTP id QAA08384 for ; Tue, 3 Oct 1995 16:29:38 +0100 Date: Tue, 3 Oct 1995 16:29:38 +0100 Message-Id: <199510031529.QAA08384@world-net.sct.fr> X-Sender: ces-oxa@world-net.sct.fr X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.Eng.Sun.COM From: cesmo-oxara Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I'm looking for up to date informations about ipng. Does it exist anywhere an IPv6 overview for normal people (with a poor background on the subject) ? I known the overwiew on the ipng Web server but it seems too technical especially on the adressing scheme ? Thanks for help. Sincerely. Eric GAILLARD ___________________________________ CESMO - OXARA 83-87 av. d'Italie 75013 PARIS FRANCE Tel: (33 1) 45 83 77 11 Fax: (33 1) 45 83 69 00 Email: ces-oxa@world-net.sct.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 Tue Oct 3 14:25:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11464; Tue, 3 Oct 95 14:25:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11458; Tue, 3 Oct 95 14:25:27 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02692; Tue, 3 Oct 1995 14:13:12 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id OAA03472; Tue, 3 Oct 1995 14:12:51 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15626(5)>; Tue, 3 Oct 1995 14:12:40 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 3 Oct 1995 14:12:23 -0700 To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, addrconf@cisco.com Subject: (IPng 710) Re: IPng and AddrConf Interm Meeting Location and Travel Info In-Reply-To: bound's message of Mon, 02 Oct 95 20:12:21 -0800. <9510030312.AA02151@xirtlu.zk3.dec.com> Date: Tue, 3 Oct 1995 14:12:12 PDT From: Steve Deering Message-Id: <95Oct3.141223pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Is ND the only item on the agenda? Not fair to have addr conf now I > think cause we should have been able to have some mail discussion for > those that are not coming. So, let's discuss whatever outstanding issues there are with addrconf over the next week, before the interim meeting. If we resolve them, great; if not, we'll take them up at the meeting. (Myself, I owe a message on the loopback issue, which I'll try to get to later today or tomorrow.) > How about start/stop times too? I propose that we start at 9 am on Wednesday, and finish around 3:30 or 4:00 on Thursday (to let left-coasters catch 6 pm flights out of Dulles). If a later start on Wednesday would enable right-coasters to catch early Wednesday morning flights to DC and save one hotel night, please let me know. I assume we can extend the meeting into Tuesday evening, if that turns out to be necessary to cover everything. (I should check with the local hosts about the room availability in the evening: Allison?) As far as I know, the two main topics will be ND and addrconf. We will *not* be discussing mobility, since we decided in Stockholm that that work will take place in the mobileip WG. If there are other topics that folks would like to include on the agenda, please post them on the ipng list. > Can we get a list of the potential attendees to us too? Bob H.: could you please post the list of people who said they are attending? Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 3 14:56:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11503; Tue, 3 Oct 95 14:56:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11497; Tue, 3 Oct 95 14:56:48 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07701; Tue, 3 Oct 1995 14:44:36 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id OAA13196; Tue, 3 Oct 1995 14:44:22 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id OAA03462; Tue, 3 Oct 1995 14:44:01 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Oct 1995 14:47:20 -0700 To: ipng@sunroof.Eng.Sun.COM, addrconf@cisco.com, bound@zk3.dec.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 711) Re: IPng and AddrConf Interm Meeting Location and Travel Info Cc: hinden@Ipsilon.COM, sbehnke@dyncorp-is.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >Can we get a list of the potential attendees to us too? The people who have said they are attending are: Steve Silverman BTNA Jim Bound Digital Richard Colella NIST Ran Atkinson NRL (maybe) Bao Phan NRL Dan McDonald NRL Thomas Narten IBM Wenken Ling Baynetworks Erik Nordmark Sun Steve Deering Xerox PARC Allison Mankin ISI Bob Hinden Ipsilon Peter Grehan Ipsilon Bob Gilligan Sun Matt Thomas Digital Dan Harrington Digital A few other folks said they might attend. If anyone else decides to attend please let me and our local host [Scott Behnke ] know. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 3 16:03:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11595; Tue, 3 Oct 95 16:03:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11589; Tue, 3 Oct 95 16:02:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17476; Tue, 3 Oct 1995 15:50:43 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id PAA03026; Tue, 3 Oct 1995 15:50:40 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15210(1)>; Tue, 3 Oct 1995 15:50:17 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 3 Oct 1995 15:50:08 -0700 To: mankin@isi.edu, sob@newdev.harvard.edu Cc: ipng@sunroof.Eng.Sun.COM, rcallon@wellfleet.com, deering@parc.xerox.com Subject: (IPng 712) request for publication as Experimental RFC: OSI NSAPs and IPv6 Date: Tue, 3 Oct 1995 15:50:02 PDT From: Steve Deering Message-Id: <95Oct3.155008pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Allison and Scott, The IPNG Working Group requests that the following document be published as an Experimental status RFC; no comments on this document were received during the Working Group Last Call which commenced on August 27. Title : OSI NSAPs and IPv6 Author(s) : J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd Filename : draft-ietf-ipngwg-nsap-ipv6-00.txt Pages : 17 Date : 08/23/1995 Steve Deering, for the IPNG Working Group ------------------------------------------------------------------------------ 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 Oct 3 16:44:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11615; Tue, 3 Oct 95 16:44:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11609; Tue, 3 Oct 95 16:44:07 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24234; Tue, 3 Oct 1995 16:31:55 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id QAA14681; Tue, 3 Oct 1995 16:31:54 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id QAA08454; Tue, 3 Oct 1995 16:31:34 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Oct 1995 16:34:53 -0700 To: ipng@sunroof.Eng.Sun.COM, addrconf@cisco.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 713) Updated Interim Meeting Attendee List Cc: sbehnke@dyncorp-is.com, hinden@Ipsilon.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Updated attendee list: Steve Silverman BTNA Jim Bound Digital Richard Colella NIST Ran Atkinson NRL (maybe) Bao Phan NRL Dan McDonald NRL Thomas Narten IBM Wenken Ling Baynetworks Erik Nordmark Sun Steve Deering Xerox PARC Allison Mankin ISI Bob Hinden Ipsilon Peter Grehan Ipsilon Bob Gilligan Sun Matt Thomas Digital Dan Harrington Digital Sue Thompson Bellcore Tim Hartrick Mentat Scott Behnke Dyncorp Terry Gibbons ISI ------------------------------------------------------------------------------ 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 Oct 3 20:39:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11757; Tue, 3 Oct 95 20:39:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11751; Tue, 3 Oct 95 20:39:00 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15931; Tue, 3 Oct 1995 20:26:48 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id UAA23821; Tue, 3 Oct 1995 20:26:41 -0700 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA28552; Tue, 3 Oct 1995 23:26:32 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA01753; Tue, 3 Oct 1995 23:26:29 -0400 Message-Id: <9510040326.AA01753@wasted.zk3.dec.com> To: Steve Deering Cc: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM, addrconf@cisco.com Subject: (IPng 714) Re: IPng and AddrConf Interm Meeting Location and Travel Info In-Reply-To: Your message of "Tue, 03 Oct 95 14:12:12 PDT." <95Oct3.141223pdt.75270@digit.parc.xerox.com> Date: Tue, 03 Oct 95 23:26:29 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >> Is ND the only item on the agenda? Not fair to have addr conf now I >> think cause we should have been able to have some mail discussion for >> those that are not coming. >So, let's discuss whatever outstanding issues there are with addrconf over the >next week, before the interim meeting. If we resolve them, great; if not, >we'll take them up at the meeting. (Myself, I owe a message on the loopback >issue, which I'll try to get to later today or tomorrow.) I can't this week read lots of mail. We can discuss this point at the meeting, and I feel it will get cleared up quickly per the attendees coming. So should we all bring Sue's last draft to the meeting? Or just discuss the one point regarding loopback? One issue I have (and I cannot discuss it until the meeting) is Francis Duponts issues on preferences. I have re-read all the mail and reworked my own concerns. The bottom line is as follows: Nodes will have multiple interfaces (N1-NX). N1 MAY have multiple routers R1-RX available to N1. N1 should have preferences for the router to be used at a given time (e.g. R1-R2-R3....). If N1&R1 combination does not respond (with redirect or is just not listening) the Host should be able to use R2 given Z amount of time. The issue is that not all interfaces N1-N2-N3 will use the same set of R1-R2-R3, hence each NX needs its own "default router preference". What we need to understand is first is this clear if not I will explain it again at the meeting as input. Then whats Z (time if router does not respond), how are the preference values ordered (cardinal value/its position to be used), how are preferences specified in the first place, how are they changed, and other issues that I am sure the group can come up with too. The technical reason for these preferences is it gives us all we had in IPv4 (RFC 1256) and new features via ND that can be made capable with the above paradigm. >> How about start/stop times too? >I propose that we start at 9 am on Wednesday, and finish around 3:30 or 4:00 >on Thursday (to let left-coasters catch 6 pm flights out of Dulles). If a >later start on Wednesday would enable right-coasters to catch early Wednesday >morning flights to DC and save one hotel night, please let me know. I assume >we can extend the meeting into Tuesday evening, if that turns out to be >necessary to cover everything. (I should check with the local hosts about >the room availability in the evening: Allison?) Well the folks from Digital are all coming in Wed 8 a.m. and our flight is at 8 p.m. Thurs eve out. >As far as I know, the two main topics will be ND and addrconf. We will *not* >be discussing mobility, since we decided in Stockholm that that work will >take place in the mobileip WG. If there are other topics that folks would >like to include on the agenda, please post them on the ipng list. What about PMTU Discovery or do we wait for you and Jack McCann to get out an IPv6 PMTU draft update to RFC 1191, for the group and review at Dallas? >> Can we get a list of the potential attendees to us too? >Bob H.: could you please post the list of people who said they are attending? Yes I just saw Bobs 2cnd list. Looks like a good group of individuals to discuss ND including existing implementors as to what it really does, as opposed to the abstract theory. Should be a good meeting. 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 Wed Oct 4 12:37:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12137; Wed, 4 Oct 95 12:37:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12131; Wed, 4 Oct 95 12:37:24 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25903; Wed, 4 Oct 1995 12:25:13 -0700 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id MAA14008; Wed, 4 Oct 1995 12:25:12 -0700 Subject: (IPng 715) Two quick multicast questions To: IPng Mailing list Date: Wed, 4 Oct 1995 15:25:31 -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: <9510042025.aa21612@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk 1. Do I have to send group report messages when joining a group with intra-link scope? (E.g. solicited nodes, all-nodes, etc.) 2. Does a user program have to be so concerned about setting appropriate multicast hop limits, when there are scoping bits already in the multicast address? The BSD API draft mentions explicitly setting multicast hop limits, but is it needed given the presence of scoping bits? See you at the meeting next week! Dan McD. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 4 14:45:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12192; Wed, 4 Oct 95 14:45:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12186; Wed, 4 Oct 95 14:45:21 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14004; Wed, 4 Oct 1995 14:32:23 -0700 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id OAA17445; Wed, 4 Oct 1995 14:32:14 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14138; 4 Oct 95 12:32 EDT To: IETF-Announce:;@mercury Cc: ipng@sunroof.Eng.Sun.COM From: IESG Secretary Subject: (IPng 716) Last Call: OSI NSAPs and IPv6 to Experimental Reply-To: iesg@IETF.CNRI.Reston.VA.US Date: Wed, 04 Oct 95 12:32:15 -0400 Message-Id: <9510041232.aa14138@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The IESG has received a request from the IPNG Working Group to consider "OSI NSAPs and IPv6" for the status of Experimental. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by October 18, 1995. ------------------------------------------------------------------------------ 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 Oct 5 03:22:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12608; Thu, 5 Oct 95 03:22:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12602; Thu, 5 Oct 95 03:22:48 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10985; Thu, 5 Oct 1995 03:10:36 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id DAA08895; Thu, 5 Oct 1995 03:10:30 -0700 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 LAA27409; Thu, 5 Oct 1995 11:10:17 +0100 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 LAA25465; Thu, 5 Oct 1995 11:10:16 +0100 Message-Id: <199510051010.LAA25465@givry.inria.fr> From: Francis Dupont To: Dan McDonald Cc: IPng Mailing list Subject: (IPng 717) Re: Two quick multicast questions In-Reply-To: Your message of Wed, 04 Oct 1995 15:25:31 EST. <9510042025.aa21612@cs.nrl.navy.mil> Date: Thu, 05 Oct 1995 11:10:13 +0100 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: 1. Do I have to send group report messages when joining a group with intra-link scope? (E.g. solicited nodes, all-nodes, etc.) => I believe report messages for node and link local groups should not been sent because they are used only (today) by multicast routers. 2. Does a user program have to be so concerned about setting appropriate multicast hop limits, when there are scoping bits already in the multicast address? The BSD API draft mentions explicitly setting multicast hop limits, but is it needed given the presence of scoping bits? => The hop-limit default value is 1 and it is a good practice to set it in all cases. Scope and hop-limit are not twice the same thing but double security. See you at the meeting next week! => I can't attend... Regards Francis.Dupont@inria.fr PS: if you need it I have very simple multicast applications (just useful for testing) named in2multi[6] and multi2out[6]. ------------------------------------------------------------------------------ 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 Oct 9 06:31:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13989; Mon, 9 Oct 95 06:31:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13983; Mon, 9 Oct 95 06:31:11 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09112; Mon, 9 Oct 1995 06:18:54 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id GAA06520; Mon, 9 Oct 1995 06:18:48 -0700 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA13152; Mon, 9 Oct 1995 09:17:22 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14317; Mon, 9 Oct 1995 09:17:13 -0400 Message-Id: <9510091317.AA14317@wasted.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: (IPng 718) ND Spec for Interim Meeting. Date: Mon, 09 Oct 95 09:17:12 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk This review will take some time I have the spec completely marked up with questions and suggestions. Critical Inputs: 1. Variable link MTU is a bad idea I will present why at the meeting. 2. Treating the link as routers will know of all nodes and they may not want to be aware of all nodes. This is an important discussion. 3. The spec is plagued with the implementation notes that are quite frankly not the best way to "implement" ND. Move them all to a rationale appendix or something. 4. The conceptual model is fine but it then becomes mandatory later in the spec. THis is bogus and an implementation issue. We are building a standard not an academic white paper. 5. The states for NUD are incomplete and its unclear in the spec if one has to implement NUD at all. 6. Negative acks are better than positive acks. It could be that a negative ack is being viewed as positive ack but we need to clear this up. 7. Take addr conf out of ND and let it be part of addr conf spec. The two specs either need to be distinct and discrete or combine all of this into ND (which Bill Simpson had done). I think two separate specs is the way to go. 8. Have to solve the default router preference discussion. 9. Do we need a separate options spec for ND? 10. Prefixs for links needs an architecture section to define it better its not clear at all in the spec. 11. The spec is now as confusing at the latest one Bill had done for Danvers meeting. So this tells me it was not the author but the subject. Its also too many pages. 12. The spec should say "Broadcast Technology" I think we need a different spec for say ATM. 13. We say we will not discuss the Multihome issue but then the spec discusses it in detail. Lets make up our mind. But we should remove all academic discussions of Multihome nodes unless we are going to solve the problem. Lots to talk about at the meeting. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 9 06:54:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14010; Mon, 9 Oct 95 06:54:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14004; Mon, 9 Oct 95 06:53:59 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10447; Mon, 9 Oct 1995 06:41:41 -0700 Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM) id GAA09815; Mon, 9 Oct 1995 06:41:41 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id JAA02098; Mon, 9 Oct 1995 09:38:09 -0400 (EDT) Date: Mon, 9 Oct 1995 09:38:09 -0400 (EDT) From: Scott Bradner Message-Id: <199510091338.JAA02098@newdev.harvard.edu> To: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng 719) Re: ND Spec for Interim Meeting. Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > 3. The spec is plagued with the implementation notes that are quite frankly not the best way to "implement" ND. Move them all to a rationale appendix or something. Jim, I'm not going to comment on the specific notes in teh ND draft but I do want to make it very clear that I think implementation notes are a *very* good idea, it is the lack of this sort of thing which has caused many proplems for people trying to implement IETF standards in the past. We should be sure to include such notes whereever we can to make as clear as we can *a* (not the) right way to implement the protocol. We had to spend a lot of effort to do this for IPv4 in teh host requirements docs because there was not enought of it in teh original docs. I would like for there not to have to be a IPv6 host (& router) requirements effort in a few years because the basic docs are not clear enough. Scott ------------------------------------------------------------------------------ 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 Oct 9 09:25:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14140; Mon, 9 Oct 95 09:25:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14134; Mon, 9 Oct 95 09:25:22 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24752; Mon, 9 Oct 1995 09:13:03 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id JAA09620; Mon, 9 Oct 1995 09:12:59 -0700 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA03153; Mon, 9 Oct 1995 12:12:54 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA09440; Mon, 9 Oct 1995 12:12:53 -0400 Message-Id: <9510091612.AA09440@wasted.zk3.dec.com> To: Scott Bradner Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 720) Re: ND Spec for Interim Meeting. In-Reply-To: Your message of "Mon, 09 Oct 95 09:38:09 EDT." <199510091338.JAA02098@newdev.harvard.edu> Date: Mon, 09 Oct 95 12:12:53 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Scott, I agree with the spirit of what you say. But a bad implementation note is worse than none. For example I prefer an engineer to not comment their code at all than have wrong comments in the code. The other issue is that we don't want future procurement policy for IETF standards to require an implementation model in a spec that may not be the best way to implement that spec. We have a two edged sword here and I think a compromise is a rationale appendix which I think is a good idea. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 9 09:35:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14161; Mon, 9 Oct 95 09:35:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14155; Mon, 9 Oct 95 09:35:40 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26078; Mon, 9 Oct 1995 09:23:18 -0700 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id JAA12227; Mon, 9 Oct 1995 09:23:15 -0700 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HW8GHRJ91S00370A@FNAL.FNAL.GOV>; Mon, 09 Oct 1995 11:22:38 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA22393; Mon, 9 Oct 95 11:21:22 CDT Date: Mon, 09 Oct 1995 11:21:21 -0500 From: Matt Crawford Subject: (IPng 721) draft-ietf-ipngwg-ethernet-ntwrks-01.txt To: ipng@sunroof.Eng.Sun.COM Message-Id: <9510091621.AA22393@munin.fnal.gov> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=mysteryboxofun Content-Description: IPv6-over-Ethernet revision Content-Transfer-Encoding: 7BIT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk --mysteryboxofun Content-Type: text/plain Content-Description: Summary of changes I have revised the IPv6-over-ethernet document to reflect changes suggested by Matt Thomas and myself. The changes include: * Mentioning that MTU may be reduced by manual configuration * More verbosity in describing the link-layer header * Specifying the byte order as well as the bit order in the address token If there are no further comments by the end of the month, I will request a working group last call. Matt Crawford --mysteryboxofun Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-ipngwg-ethernet-ntwrks-01.txt" Content-Description: draft-ietf-ipngwg-ethernet-ntwrks-01.txt Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force Matt Crawford INTERNET-DRAFT Fermilab October 9, 1995 A Method for the Transmission of IPv6 Packets over Ethernet Networks Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. Introduction This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used the the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in [DISC], when those messages are transmitted on an Ethernet. Maximum Transmission Unit The default MTU size for IPv6 packets on an Ethernet is 1500 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option which specifies a smaller MTU, or by manual configuration of each node. If a Router Advertisement is received with an MTU option specifying an MTU larger than 1500, or larger than a manually configured value less than 1500, that MTU option must be ignored. Crawford Expires April 1996 [Page 1] =0C INTERNET-DRAFT Transmission of IPv6 Packets Over Ethernet 9 October 1995 Frame Format IPv6 packets are transmitted in standard Ethernet frames. The ethernet header contains the Destination and Source ethernet addresses and the ethernet type code, which must contain the value 86DD hexadecimal. The data field contains the IPv6 header followed immediately by the payload, and possibly padding octets to meet the minimum frame size for Ethernet. +-------+-------+-------+-------+-------+-------+ ^ | Destination Ethernet address | | +-------+-------+-------+-------+-------+-------+ ethernet | Source Ethernet address | header +-------+-------+-------+-------+-------+-------+ | | 86 DD | v +-------+-------+-------+-------+-------+------+------+ | IPv6 header and payload ... / +-------+-------+-------+-------+-------+------+------+ Stateless Autoconfiguration and Link-Local Addresses The address token [CONF] for an Ethernet interface is the interface's built-in 48-bit IEEE 802 address, in canonical bit order and with the octets in the same order in which they would appear in the header of an ethernet frame. (The individual/group bit is in the first octet and the OUI is in the first three octets.) A different MAC address set manually or by software should not be used as the address token. An IPv6 address prefix used for stateless autoconfiguration of an ethernet interface must be 80 bits in length. The IPv6 Link-local address [AARCH] for an Ethernet interface is formed by appending the interface's IEEE 802 address to the 80-bit prefix FE80::. +-------+-------+-------+-------+-------+-------+------+------+ | FE 80 00 00 00 00 00 00 | +-------+-------+-------+-------+-------+-------+------+------+ | 00 00 | Ethernet Address | +-------+-------+-------+-------+-------+-------+------+------+ Address Mapping -- Unicast The procedure for mapping IPv6 addresses into Ethernet link-layer addresses is described in [DISC]. The Source/Target Link-layer Address option has the following form when the link layer is Ethernet. Crawford Expires April 1996 [Page 2] =0C INTERNET-DRAFT Transmission of IPv6 Packets Over Ethernet 9 October 1995 +-------+-------+-------+-------+-------+-------+-------+-------+ | Type |Length | Ethernet Address | +-------+-------+-------+-------+-------+-------+-------+-------+ Option fields: Type 1 for Source Link-layer address. 2 for Target Link-layer address. Length 1 (in units of 8 octets). Ethernet Address The 48 bit Ethernet IEEE 802 address, in canonical bit order. Address Mapping -- Multicast An IPv6 packet with a multicast destination address DST is transmit- ted to the Ethernet multicast address whose first two octets are the value 3333 hexadecimal and whose last four octets are the last four octets of DST, ordered from more to least significant. +-------+-------+-------+-------+-------+-------+ | 33 | 33 | DST13 | DST14 | DST15 | DST16 | +-------+-------+-------+-------+-------+-------+ Security Considerations Security considerations are not addressed in this memo. References [AARCH] R. Hinden, S. Deering, IP Version 6 Addressing Architecture. Currently draft-ietf-ipngwg-addr-arch-03.txt. [CONF] S. Thomson, IPv6 Stateless Address Autoconfiguration. Currently draft-ietf-addrconf-ipv6-auto-04.txt. [DISC] T. Narten, E. Nordmark, W. A. Simpson, Neighbor Discovery for IP Version 6 (IPv6). Currently draft-ietf-ipngwg-discovery-02.txt. Crawford Expires April 1996 [Page 3] =0C INTERNET-DRAFT Transmission of IPv6 Packets Over Ethernet 9 October 1995 [IPV6] S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) Specification. Currently draft-ietf-ipngwg-ipv6-spec-02.txt. Author's Address Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA Phone: +1 708 840-3461 EMail: crawdad@fnal.gov Crawford Expires April 1996 [Page 4] --mysteryboxofun Content-Type: text/plain _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A --mysteryboxofun-- ------------------------------------------------------------------------------ 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 Oct 9 10:24:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14196; Mon, 9 Oct 95 10:24:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14190; Mon, 9 Oct 95 10:23:56 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02373; Mon, 9 Oct 1995 10:11:36 -0700 Received: from thumper.bellcore.com by mercury.Sun.COM (Sun.COM) id KAA25000; Mon, 9 Oct 1995 10:11:31 -0700 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id NAA02758; Mon, 9 Oct 1995 13:08:34 -0400 Message-Id: <199510091708.NAA02758@thumper.bellcore.com> To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, gja@thumper.bellcore.com Subject: (IPng 722) Re: ND Spec for Interim Meeting. In-Reply-To: Your message of Mon, 09 Oct 1995 09:17:12 -0400. <9510091317.AA14317@wasted.zk3.dec.com> Date: Mon, 09 Oct 1995 13:08:30 -0400 From: Grenville Armitage Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk [..] >>12. The spec should say "Broadcast Technology" I think we need a >> different spec for say ATM. Just FYI - this would probably not be a bad idea. IPv6 over ATM has been shifted (or is in the process of being shifted) into the IP-ATM working group's charter. There is already a first hack at mapping the existing ND model onto ATM: draft-ietf-ipatm-ipv6nd-00.txt It currently makes no ATM-specific modifications to the model. Howvever, there have been private comments suggesting that ND over switched networks that do not natively support multicast is going to be interesting. cheers, gja ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 9 10:57:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14241; Mon, 9 Oct 95 10:57:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14178; Mon, 9 Oct 95 10:19:48 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01313; Mon, 9 Oct 1995 10:05:05 -0700 Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM) id KAA23191; Mon, 9 Oct 1995 10:05:03 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id NAA02575; Mon, 9 Oct 1995 13:01:34 -0400 (EDT) Date: Mon, 9 Oct 1995 13:01:34 -0400 (EDT) From: Scott Bradner Message-Id: <199510091701.NAA02575@newdev.harvard.edu> To: bound@zk3.dec.com, sob@newdev.harvard.edu Subject: (IPng 723) Re: ND Spec for Interim Meeting. Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Jim, I would rather implementation notes which specifically say they are describing a way and specifically say it is not the only way to implement something but I would prefer themin the body of the standard. Implementation notes are not just useful to implementers, they be of great help to someone just trying to understand the protocol. Clearly, any that are wrong, in the sense that the implementation will not function the way the standard wants it to must be fixed, I do not agree that one should only have "the bext way" described, In my experience there is no "best way" it depends greatly on rather many factors, the "best way" in a OSF1 based machine may not be the "best way" for a windows implementation. Scott ------------------------------------------------------------------------------ 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 Oct 9 13:13:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14487; Mon, 9 Oct 95 13:13:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14442; Mon, 9 Oct 95 12:48:52 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26783; Mon, 9 Oct 1995 12:36:34 -0700 Received: from timbuk.cray.com by mercury.Sun.COM (Sun.COM) id MAA11053; Mon, 9 Oct 1995 12:36:32 -0700 Received: from frenzy.cray.com (frenzy.cray.com [128.162.84.21]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.5) with SMTP id OAA08791 for ; Mon, 9 Oct 1995 14:36:31 -0500 Received: by frenzy.cray.com id AA01858; 4.1/CRI-5.6; Mon, 9 Oct 95 14:36:53 CDT Date: Mon, 9 Oct 95 14:36:53 CDT From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9510091936.AA01858@frenzy.cray.com> To: bound@zk3.dec.com, sob@newdev.harvard.edu Subject: (IPng 724) Re: ND Spec for Interim Meeting. Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > From: Scott Bradner > I would rather implementation notes which specifically say they are > describing a way and specifically say it is not the only way to implement > something but I would prefer themin the body of the standard. Implementation > notes are not just useful to implementers, they be of great help to > someone just trying to understand the protocol. The Host Requirements RFCs (1122/1123) have both DISCUSSION and IMPLEMENTATION sections scattered throughout them. They are not part of the official requirements, but are intended as clarification of the requirements and this is stated up front in the beginning of the document. The same thing can be done for the ND Spec to imbed implementation notes throughout the spec without having them become part of the spec. -David Borman, dab@cray.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 9 13:35:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14519; Mon, 9 Oct 95 13:35:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14513; Mon, 9 Oct 95 13:35:01 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03913; Mon, 9 Oct 1995 13:22:43 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id NAA22408; Mon, 9 Oct 1995 13:22:37 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9320; Mon, 09 Oct 95 16:22:32 EDT Received: by RTP (XAGENTA 4.0) id 7272; Mon, 9 Oct 1995 16:22:00 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA16920; Mon, 9 Oct 1995 16:22:01 -0400 Message-Id: <9510092022.AA16920@cichlid.raleigh.ibm.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 725) "don't forward" hop-by-hop option? Date: Mon, 09 Oct 1995 16:21:54 -0300 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I'm planning on bringing up the following for discussion at the interim meeting. I'm posting to the list now to solicit feedback from folks not able to attend and to give attendees something to think about while accumulating frequent flier miles. ND is still battling with the desire (for robustness) that nodes receiving an ND packet be able to assert from the packet's contents that the packet originated from a neighbor. That way, a host can toss any ND packets that have been forwarded through a router, reducing the probability that ND can be used for denial of service attacks. We have been concentrating on the following techniques: a) requiring the source address be link-local (e.g., redirects) b) the destination address be link-local (e.g., NA, NS, RA, RS) The problem with a) is that routers could in practice not bother checking the source address of packets it forwards. Router vendors need to put in the code, and then turn it on at runtime at the possible expense of performance. The problem with b) is that it leads to some "unnatural" contortions when the intended destination is actually a non-link-local scope address (the common case). At present, we have had to add some undesirably complex rules to handle NA messages whose target address is global, but whose IPv6 destination must be link-local to satisfy requirement b). One "contortion" results from rules needed to insure that ND packets sent to the link-local address are not treated as normal upper layer traffic that triggers NUD into probing the link-local address for reachability. What is needed is a way to insure that a router can't/won't forward ND packets. How about defining a new hop-by-hop option saying "do not forward"? I first tried using the Routing Header, but it doesn't quite do what we want. The first hop (loose vs. strict) route is not defined within the header (it's defined as an API flag I'd guess), so the recipient doesn't get the desired verification from the received packet's contents. Plus, it's not really clear you can use the routing header if there is only a source and destination with no intermediary node. The hop-by-hop header, on the other hand, is required to be examined by every router. Thus, there is no way a router would forward such a datagram unless it were severly broken (e.g., someone would have to add code that recognizes the option and then forwards it even though it shouldn't). In contrast, routers might forward packets with a link-local source address through inaction -- failing to do the check. Also, since the whole purpose of this option is to force routers to drop such packets, routers would in practice (one hopes!) rarely see them, and the performance cost in routers is nothing. The processing cost at a receiving host would be pretty minimal. It simply needs to verify that the packet is being delivered locally, a check it would need to make in anycase. I think this would result in a somewhat cleaner overall design for ND with regards to NS and NA messages. We could eliminate the "Sender Address" field, allowing the IPv6 source to contain the same information. Likewise, the NA could be sent directly to a global-scope IPv6 address instead of the link-local address. Doing so would cleanup up some of the messiness of NA messages triggering additional NUD probes. Moreover, the clean separation of "keep packet on-link" from the ND protocol itself seems appealing. Such an option might also be useful in other contexts. For example, routing protocols might want to ignore any off-link packets. Comments? Thomas ------------------------------------------------------------------------------ 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 Oct 9 14:17:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14568; Mon, 9 Oct 95 14:17:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14562; Mon, 9 Oct 95 14:17:19 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10481; Mon, 9 Oct 1995 14:05:00 -0700 Received: from catarina.usc.edu by mercury.Sun.COM (Sun.COM) id OAA03459; Mon, 9 Oct 1995 14:04:58 -0700 Received: from tampico.usc.edu (tampico.usc.edu [128.125.52.5]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id OAA20166; Mon, 9 Oct 1995 14:04:55 -0700 Message-Id: <199510092104.OAA20166@catarina.usc.edu> X-Authentication-Warning: catarina.usc.edu: Host tampico.usc.edu didn't use HELO protocol X-Mailer: exmh version 1.6 4/21/95 To: "Thomas Narten" Cc: ipng@sunroof.Eng.Sun.COM, micke@catarina.usc.edu Subject: (IPng 726) Re: "don't forward" hop-by-hop option? In-Reply-To: Your message of "Mon, 09 Oct 1995 16:21:54 -0300." <9510092022.AA16920@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Oct 1995 14:04:54 -0700 From: Mikael Degermark Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Thomas Narten suggests a "don't forward" hop-by-hop option to avoid hazzle with the link-local addresses and to simplify the necessary tests to avoid forwarding ND packets. Based on our current work regarding header compression, where things has to be negotiated over the local link, I think it's a good idea. The option would be very useful when control messages are valid only on the local link and would waste resources and/or cause confusion if forwarded off-link. Mikael Degermark ------------------------------------------------------------------------------ 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 Oct 9 14:48:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14594; Mon, 9 Oct 95 14:48:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14586; Mon, 9 Oct 95 14:47:55 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15207; Mon, 9 Oct 1995 14:35:34 -0700 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id OAA10705; Mon, 9 Oct 1995 14:35:34 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA16889; Mon, 9 Oct 95 17:34:23 EDT Received: from andover.engeast by BayNetworks.com (4.1/SMI-4.1) id AA13013; Mon, 9 Oct 95 17:35:29 EDT Date: Mon, 9 Oct 95 17:35:28 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9510092135.AA13013@BayNetworks.com> To: narten@VNET.IBM.COM Subject: (IPng 727) Re: "don't forward" hop-by-hop option? Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Thomas, I think I can propose a simpler solution for the presented problem as followed: 1) Nodes that generate ND packets must set the Hop Limit field of such packets to zero. 2) Nodes receiving ND packets should accept only ND packets with Hop Limit value of zero. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 9 15:12:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14633; Mon, 9 Oct 95 15:12:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14627; Mon, 9 Oct 95 15:12:00 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19070; Mon, 9 Oct 1995 14:59:41 -0700 Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM) id OAA17000; Mon, 9 Oct 1995 14:59:38 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id RAA03258; Mon, 9 Oct 1995 17:58:41 -0400 (EDT) Date: Mon, 9 Oct 1995 17:58:41 -0400 (EDT) From: Scott Bradner Message-Id: <199510092158.RAA03258@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM, narten@VNET.IBM.COM Subject: (IPng 728) Re: "don't forward" hop-by-hop option? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > requiring the source address be link-local I thought that we had decided that many (if not all ) of the ND packets should use link-local so that renumbering does not confuse issues. I don't quite understand why to go back on that (to me quite important) point. > The problem with a) is that routers could in practice not bother > checking the source address of packets it forwards. Router vendors > need to put in the code, and then turn it on at runtime at the > possible expense of performance. routers *must not* forward packets with link-local addresses, the world sorta ends if they do > The problem with b) is that it leads > to some "unnatural" contortions when the intended destination is > actually a non-link-local scope address (the common case). At present, > we have had to add some undesirably complex rules to handle NA > messages whose target address is global, but whose IPv6 destination > must be link-local to satisfy requirement b). One "contortion" results > from rules needed to insure that ND packets sent to the link-local > address are not treated as normal upper layer traffic that triggers > NUD into probing the link-local address for reachability. I guess I'm getting quite confused, I thought that ND was only to find neighbors and I thought neighbors had to be link-local > What is needed is a way to insure that a router can't/won't forward ND > packets. How about defining a new hop-by-hop option saying "do not > forward"? how about just setting time to live to 1 (which I thought was already there) Scott ------------------------------------------------------------------------------ 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 Oct 9 17:27:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14762; Mon, 9 Oct 95 17:27:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14756; Mon, 9 Oct 95 17:27:06 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08673; Mon, 9 Oct 1995 17:14:47 -0700 Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM) id RAA18231; Mon, 9 Oct 1995 17:14:47 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id UAA03462; Mon, 9 Oct 1995 20:11:20 -0400 (EDT) Date: Mon, 9 Oct 1995 20:11:20 -0400 (EDT) From: Scott Bradner Message-Id: <199510100011.UAA03462@newdev.harvard.edu> To: bound@zk3.dec.com, sob@newdev.harvard.edu Subject: (IPng 729) Re: ND Spec for Interim Meeting. Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Such explanations also make the spec more complex to implement. well, we are in specific disagreement. Its time for others to add their opinions Scott ------------------------------------------------------------------------------ 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 Oct 9 18:17:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14932; Mon, 9 Oct 95 18:17:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14922; Mon, 9 Oct 95 18:17:06 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14725; Mon, 9 Oct 1995 18:04:46 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id QAA03814; Mon, 9 Oct 1995 16:09:18 -0700 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA23765; Mon, 9 Oct 1995 19:09:15 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA18343; Mon, 9 Oct 1995 19:09:13 -0400 Message-Id: <9510092309.AA18343@wasted.zk3.dec.com> To: Scott Bradner Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 730) Re: ND Spec for Interim Meeting. In-Reply-To: Your message of "Mon, 09 Oct 95 13:01:34 EDT." <199510091701.NAA02575@newdev.harvard.edu> Date: Mon, 09 Oct 95 19:09:13 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Scott, Such explanations also make the spec more complex to implement. For example when implementing the ND options one has to flip through multiple pages to sit there and write the code and parse through the excessive wordage on the conceptual model to get the point. I think protocols should specify packets, timers, algorithms for interoperability, et al. Standards are for implementors to build and for users to mandate. Readers are secondary. If excess implementation data exists in the spec it makes it messy to read. Especially if your not implementing it that way. Second where implementation notes exist I want to see ..for example, or some such wording clearly depicting the words to be commentary as opposed to part of the standard. Also stating whether this idea is from Digital UNIX (OSF1 IS NOT WHAT ITS CALLED ANYMORE FYI), Solaris, or WIN95 thats fine as a reference. But vague generalizations that are not technically feasible for say performance reasons is just not good and I would think authors would want that input so the implementors don't make jest at them tomorrow. If the IETF would get off their ego and at least look at other standards organizations such as the IEEE we would see that is why the IEEE specs use a rationale appendix instead of cluttering the acutal standard with none requirements. A good compromise is our IPv6 base spec or the to-be Experimental OSI NSAPs for IPv6. Rationale is provided but not to the point where it clutters up the details of the protocol. This is the case at present in ND. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 9 19:30:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14971; Mon, 9 Oct 95 19:30:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14965; Mon, 9 Oct 95 19:30:26 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20610; Mon, 9 Oct 1995 19:18:07 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id TAA07559; Mon, 9 Oct 1995 19:18:08 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3870; Mon, 09 Oct 95 22:18:05 EDT Received: by RTP (XAGENTA 4.0) id 7304; Mon, 9 Oct 1995 22:17:48 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA19164; Mon, 9 Oct 1995 22:17:53 -0400 Message-Id: <9510100217.AA19164@cichlid.raleigh.ibm.com> To: dhaskin@BayNetworks.com (Dimitry Haskin) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 731) Re: "don't forward" hop-by-hop option? In-Reply-To: Your message of "Mon, 09 Oct 1995 17:35:28 EDT." <9510092135.AA13013@BayNetworks.com> Date: Mon, 09 Oct 1995 22:17:52 -0300 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >I think I can propose a simpler solution for the presented problem >as followed: If only it were so simple! > 1) Nodes that generate ND packets must set the Hop Limit field > of such packets to zero. The problem is malicious senders, which we have no control over... > 2) Nodes receiving ND packets should accept only ND packets with > Hop Limit value of zero. This would help a bit, but a bad guy could use traceroute to figure out the exact number of hops to a destination and then send out an ND packet with the TTL set so that it is zero when it reaches the destination. THomas ------------------------------------------------------------------------------ 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 Oct 9 22:48:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15019; Mon, 9 Oct 95 22:48:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15013; Mon, 9 Oct 95 22:47:55 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA01154; Mon, 9 Oct 1995 22:35:35 -0700 From: bound@zk3.dec.com Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id WAA27047; Mon, 9 Oct 1995 22:35:32 -0700 Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA16424; Tue, 10 Oct 1995 01:35:29 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA01023; Tue, 10 Oct 1995 01:35:27 -0400 Message-Id: <9510100535.AA01023@wasted.zk3.dec.com> To: Scott Bradner Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 732) Re: ND Spec for Interim Meeting. In-Reply-To: Your message of "Mon, 09 Oct 95 09:38:09 EDT." <199510091338.JAA02098@newdev.harvard.edu> Date: Tue, 10 Oct 95 01:35:27 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Folks, I want to point out that I am biased on this issue of the type and amount of implementation material that needs to be in the spec and have an affinity to Scotts issues too, so I am flexible. Please comment as Scott asked. 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 Tue Oct 10 00:42:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15141; Tue, 10 Oct 95 00:42:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15135; Tue, 10 Oct 95 00:42:30 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05849; Tue, 10 Oct 1995 00:30:11 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id XAA00715; Mon, 9 Oct 1995 23:05:33 -0700 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA17686; Tue, 10 Oct 1995 02:05:30 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA02486; Tue, 10 Oct 1995 02:05:29 -0400 Message-Id: <9510100605.AA02486@wasted.zk3.dec.com> To: "Thomas Narten" Cc: dhaskin@baynetworks.com (Dimitry Haskin), ipng@sunroof.Eng.Sun.COM Subject: (IPng 733) Re: "don't forward" hop-by-hop option? In-Reply-To: Your message of "Mon, 09 Oct 95 22:17:52 -0300." <9510100217.AA19164@cichlid.raleigh.ibm.com> Date: Tue, 10 Oct 95 02:05:29 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Thomas, I agree with Scott. We have this figured out and quite frankly we are trying to get to proposed standard. As far as routers or host performance we are all dealing with this and many of us have it "working". I think you or someone should have thought of this before the 12th hour. The link-local address as is will work now. Your only issue is performance on a router? Well how do you know? WHo has implemented it on a router? I know engineers working on it now in the router code base in my company and no one is yelling yet. I suggest we keep in the same direction we are headed. We have much more important issues for ND than this issue you raise and I for one want it put at the bottom of the list for this meeting if brought up at all. I really think you need to hold on to this one for Dallas too. We need everyone for such a major change. This kind of change can cause all code base to get thrown away in many cases. That is really unacceptable without good reason. Your reasons are not good enough for me. Also Dimitrys idea will work your traceroute argument is not valid except in the extreme case. In addition we have AH and ESP to verify some level of security at the network layer which means the intruder has already gotten past that wall. Hence it may be an inside intruder. If we cannot assume after all the work on AH and ESP (and also is now implemented) some comfort level from discussions like this then we will loose momentum for more than ND and all of IPv6. Lets not go overboard here. I feel like ND is just going to far with fine tuning. This is seen by engineering managers when programers say I will have it fine tuned with one more fix or change. The manager just has to say stop and deliver so we can ship a product. Its time for ND to ship to proposed standard. This meeting you will find at least from implementors we will be poking questions at several parts of ND and that is from actually developing it and testing it on nodes. Lastly I consider this issue a red herring, as far as the other issues facing us for ND we have learned. I for one do want to spend my precious funding for IETF work to address this issue when real issues of implementation knowledge need to be discussed. Thats why I am coming to share the issues learned, not to head down a 1/2 day academic discussion to prevent Batman from using a link-local address to violate me on a subnet which is not going to be connected to the Internet in 90% of the networks that will implement ND as part of IPv6 in their environment. thats my input, /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 Tue Oct 10 05:34:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15328; Tue, 10 Oct 95 05:34:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15322; Tue, 10 Oct 95 05:34:30 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16329; Tue, 10 Oct 1995 05:22:11 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id FAA01265; Tue, 10 Oct 1995 05:22:10 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 6932; Tue, 10 Oct 95 08:22:06 EDT Received: by RTP (XAGENTA 4.0) id 7334; Tue, 10 Oct 1995 08:21:49 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA16510; Tue, 10 Oct 1995 08:21:53 -0400 Message-Id: <9510101221.AA16510@cichlid.raleigh.ibm.com> To: Scott Bradner Cc: dhaskin@BayNetworks.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng 734) Re: "don't forward" hop-by-hop option? In-Reply-To: Your message of "Mon, 09 Oct 1995 22:36:37 EDT." <199510100236.WAA03801@newdev.harvard.edu> Date: Tue, 10 Oct 1995 08:21:53 -0300 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >I don't see how this could happen, no router will transmit a packet >with a 0 ttl I stand corrected. I think this will do what we want. One minor point: a router can (and will need to) originate ND packets with a ttl of 0. What it shouldn't do (and the IPv6 spec makes this clear) is forward a packet whose ttl gets decremented to zero. The IPv4 router requirements spec (RFC 1812) says a router MUST NOT originate a packet with a zero ttl. As long as IPv6 nodes are allowed to originate packets with 0 ttls, we should be OK. Are there any potential problems with dual bridge/routers that mostly look like bridges to hosts, but do some IP processing anyway (like decrement the ttl)? Going back one message: >I thought that we had decided that many (if not all ) of the ND packets >should use link-local so that renumbering does not confuse issues. I >don't quite understand why to go back on that (to me quite important) >point. >From the perspective of ND, the use of link-local addresses was not really related to renumbering. The original motivation (which still holds) is to have routers use a single "designated address" when talking to hosts, so that hosts don't get confused and think they are talking to three different routers as opposed to the same router using three different addresses. The link-local address is a logical choice since it isn't expected to change, even when renumbering. The use of link-local addresses for hosts was to keep ND packets on-link. >routers *must not* forward packets with link-local addresses, the world >sorta ends if they do I'm not sure I'd go so far as to say the world ends. It certainly makes little sense to send packets with a link-local source to off-link destinations, but if such packets get forwarded, it's highly likely that only the two endpoints of communication are affected. There might be a problem if link-local addresses aren't globally unique, but if addresses all contain MAC addresses for the host portion, they should be globally unique for all pratical purposes. Are you thinking of something more than this? Even though we mandate that routers MUST NOT forward packets containing link-local source addresses, I wouldn't be surprised to see some routers skip the check for the simple reason that the world doesn't (obviously) end if they skip it. E.g., skipping the check doesn't lead to immediate and obvious consequences that has customers screaming. >> The problem with b) is that it leads >> to some "unnatural" contortions when the intended destination is >> actually a non-link-local scope address (the common case). At present, >> we have had to add some undesirably complex rules to handle NA >> messages whose target address is global, but whose IPv6 destination >> must be link-local to satisfy requirement b). One "contortion" results >> from rules needed to insure that ND packets sent to the link-local >> address are not treated as normal upper layer traffic that triggers >> NUD into probing the link-local address for reachability. >I guess I'm getting quite confused, I thought that ND was only to >find neighbors and I thought neighbors had to be link-local Yes and no. Neigbors will have link-local addresses, but the upper layers will likely be using global-scope addresses anyway. Assume machines X & Y want to communicate using global-scope addresses. X & Y are neighbors, and they also have link-local addresses XL and YL respectively. Before communicating, they must resolve each other's addresses. Ideally, X would send an NS containing: IPv6 source: X IPv6 dest: solicited multicast Target address: Y And would get back a NA containing: IPv6 source: Y (or YL) IPv6 dest: X Target address: Y Target-link-layer address: Y's link-layer address But the current ND rules require that the exchange look like: IPv6 source: XL IPv6 dest: solicited multicast Target address: Y Sender Address: X The returning NA contains: IPv6 source: YL IPv6 dest: XL Target address: Y Target-link-layer address: Y's link-layer address Doing away with the link-local source address requirements allows us to do away with the Sender Address field. >how about just setting time to live to 1 (which I thought was already >there) The current spec does say set the outgoing ttl to one. But as Dmitry points out, it really should be set to zero. We must also be sure that the IP layer doesn't drop the packet without sending it. We'll also need to add an additional validation check that discards received ND packets with a non-zero ttl. Thomas ------------------------------------------------------------------------------ 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 Oct 10 06:01:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15341; Tue, 10 Oct 95 06:01:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15335; Tue, 10 Oct 95 06:01:40 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17540; Tue, 10 Oct 1995 05:49:22 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id FAA04510; Tue, 10 Oct 1995 05:49:21 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7476; Tue, 10 Oct 95 08:49:16 EDT Received: by RTP (XAGENTA 4.0) id 7354; Tue, 10 Oct 1995 08:48:56 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17872; Tue, 10 Oct 1995 08:49:06 -0400 Message-Id: <9510101249.AA17872@cichlid.raleigh.ibm.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 735) Re: ND Spec for Interim Meeting. In-Reply-To: Your message of "Mon, 09 Oct 1995 09:38:09 EDT." <199510091338.JAA02098@newdev.harvard.edu> Date: Tue, 10 Oct 1995 08:49:04 -0300 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Jim Bound writes: >> 3. The spec is plagued with the implementation notes that are quite > frankly not the best way to "implement" ND. Move them all to > a rationale appendix or something. As one of the authors, I'll put in my (obviously biased) $0.02 worth: 1) One of the things that I've found very difficult to do is describe host behavior without sounding a little bit like an implementation at times. Let's face it. There are times when the simplest way to describe desired behavior is to say a variable gets set from a packet field and the actions to be performed depend on current settings of relevant variables. We've attempted to restrict "implementation notes" to this context. Moving such text to an appendix will not be easy and I'm skeptical that the resultant document would be easier to understand. We also clearly understand that the draft's "conceptual host model" is not the ideal way to implement things. There is an explicit disclaimer in the document that says this. On the other hand, having the conceptual model does allow us to describe host behavior in a lot of detail, which is good. 2) I agree with Scott's sentiments concerning providing more rather than less detail to the implementor. One of the reasons for the current size of the ND draft is the inclusion of so much explanatory text. It is our hope that by saying *why* a host needs to do something in a certain way the implementor will understand that deviating from the required behavior has specific consequences. That sort of text needs to appear at the point a specific implementation requirement is made, rather than in a separate appendix that gets read later (if at all). Thomas ------------------------------------------------------------------------------ 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 Oct 10 06:49:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15379; Tue, 10 Oct 95 06:49:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15373; Tue, 10 Oct 95 06:49:10 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20364; Tue, 10 Oct 1995 06:36:51 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id GAA11321; Tue, 10 Oct 1995 06:36:49 -0700 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA05644; Tue, 10 Oct 1995 09:36:40 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA19831; Tue, 10 Oct 1995 09:36:38 -0400 Message-Id: <9510101336.AA19831@wasted.zk3.dec.com> To: "Thomas Narten" Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 736) Re: ND Spec for Interim Meeting. In-Reply-To: Your message of "Tue, 10 Oct 95 08:49:04 -0300." <9510101249.AA17872@cichlid.raleigh.ibm.com> Date: Tue, 10 Oct 95 09:36:38 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Thomas, That was a good response. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 10 07:30:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15407; Tue, 10 Oct 95 07:30:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15401; Tue, 10 Oct 95 07:30:43 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23713; Tue, 10 Oct 1995 07:18:20 -0700 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id HAA19079; Tue, 10 Oct 1995 07:18:19 -0700 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HW9QFXAQSG003Q04@FNAL.FNAL.GOV>; Tue, 10 Oct 1995 09:18:16 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA28265; Tue, 10 Oct 95 09:17:02 CDT Date: Tue, 10 Oct 1995 09:17:02 -0500 From: Matt Crawford Subject: (IPng 737) Re: "don't forward" hop-by-hop option? In-Reply-To: Your message of Mon, 09 Oct 95 22:17:52 -0400. <9510100217.AA19164@cichlid.raleigh.ibm.com> To: Thomas Narten Cc: dhaskin@BayNetworks.com (Dimitry Haskin), ipng@sunroof.Eng.Sun.COM Message-Id: <9510101417.AA28265@munin.fnal.gov> Content-Transfer-Encoding: 7BIT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > 1) Nodes that generate ND packets must set the Hop Limit field > > of such packets to zero. > The problem is malicious senders, which we have no control over... Maybe we do. > > 2) Nodes receiving ND packets should accept only ND packets with > > Hop Limit value of zero. > > This would help a bit, but a bad guy could use traceroute to figure > out the exact number of hops to a destination and then send out an ND > packet with the TTL set so that it is zero when it reaches the destination. The relevant section of draft-ietf-ipngwg-ipv6-spec-02.txt reads: Hop Limit 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero. If we take "discarded" to mean "discarded without forwarding" then no node will ever send a forwarded packet with TTL=0. Excuse me, I meant Hop Limit=0. If we add two words to the base spec to make that explicit, then reception of an ND packet with HL=0 (*) will be a reliable indication that the packet was sent from on-link. Umm, add one more thing -- that when decapsulating IPv6-in-IPv[46], if the inner packet has HL=0, it is not forwarded. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A * Since we don't have a Header Length any more, "HL" is freed for this use. How nice. ------------------------------------------------------------------------------ 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 Oct 10 07:50:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15481; Tue, 10 Oct 95 07:50:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15475; Tue, 10 Oct 95 07:50:38 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25645; Tue, 10 Oct 1995 07:38:18 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id HAA22831; Tue, 10 Oct 1995 07:37:53 -0700 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA08605; Tue, 10 Oct 1995 10:37:40 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA27350; Tue, 10 Oct 1995 10:37:38 -0400 Message-Id: <9510101437.AA27350@wasted.zk3.dec.com> To: Matt Crawford Cc: Thomas Narten , dhaskin@baynetworks.com (Dimitry Haskin), ipng@sunroof.Eng.Sun.COM Subject: (IPng 738) Re: "don't forward" hop-by-hop option? In-Reply-To: Your message of "Tue, 10 Oct 95 09:17:02 CDT." <9510101417.AA28265@munin.fnal.gov> Date: Tue, 10 Oct 95 10:37:37 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Excellent Idea Mr. Matt. Can we just get this one done? Comments quickly and ratify at the meeting? Wake up out there IPv6ers....We need to nail down ND a.s.a.p. so it can go to proposed std. 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 Tue Oct 10 08:55:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15542; Tue, 10 Oct 95 08:55:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15536; Tue, 10 Oct 95 08:55:39 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03428; Tue, 10 Oct 1995 08:43:18 -0700 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id IAA08740; Tue, 10 Oct 1995 08:43:11 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA24881; Tue, 10 Oct 95 11:41:57 EDT Received: from karma.engeast by BayNetworks.com (4.1/SMI-4.1) id AA13916; Tue, 10 Oct 95 11:43:03 EDT Date: Tue, 10 Oct 95 11:43:03 EDT Message-Id: <9510101543.AA13916@BayNetworks.com> Received: by karma.engeast (4.1/SMI-4.1) id AA21077; Tue, 10 Oct 95 11:42:44 EDT From: Mike Davis To: bound@zk3.dec.com Cc: sob@newdev.harvard.edu, ipng@sunroof.Eng.Sun.COM In-Reply-To: <9510100535.AA01023@wasted.zk3.dec.com> (bound@zk3.dec.com) Subject: (IPng 739) Re: ND Spec for Interim Meeting. Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Folks, I want to point out that I am biased on this issue of the type and amount of implementation material that needs to be in the spec and have an affinity to Scotts issues too, so I am flexible. Please comment as Scott asked. I think having each section have a discussion paragraph is a good idea. Some hints about implementation, IMO, are less valuable, because I would probably do it someother way. But knowing WHY the authors/WG thought some feature was needed can help me to figure out some dense technical prose. Putting it in an appendix would be less useful, but better than nothing. What would really be great, and I'm not commenting on ND in particular or any other draft in general, is a well written overview section. I hope I don't hurt myself straddling the fence :^). thanks /jim --mad -- Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 10 09:21:26 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15562; Tue, 10 Oct 95 09:21:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15556; Tue, 10 Oct 95 09:21:17 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07520; Tue, 10 Oct 1995 09:08:57 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id JAA16547; Tue, 10 Oct 1995 09:08:52 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16077(3)>; Tue, 10 Oct 1995 08:55:01 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 10 Oct 1995 08:54:49 -0700 To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng 740) Re: "don't forward" hop-by-hop option? In-Reply-To: dhaskin's message of Mon, 09 Oct 95 14:35:28 -0800. <9510092135.AA13013@BayNetworks.com> Date: Tue, 10 Oct 1995 08:54:44 PDT From: Steve Deering Message-Id: <95Oct10.085449pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > From: dhaskin@baynetworks.com (Dimitry Haskin) > > I think I can propose a simpler solution for the presented problem > as followed: > > 1) Nodes that generate ND packets must set the Hop Limit field > of such packets to zero. For IP multicast, a packet originated with a TTL of 0 is delivered to any processes on the same node as the originating process that are listening to the destination multicast address, but it is *not* transmitted on any link. This is a natural and useful interpretation of what a hop limit of 0 should mean. Even though IPv6 has an explicit scope field in its multicast addresses, including the value "node-local", I would still like to retain the IPv4 semantics of a zero ttl/hop limit, for use in doing expanding-ring multicast searches within a group whose multicast address has a scope larger than node-local -- the set of processes on the originating node is the innermost ring. Therefore, I would argue in favor of keeping the current requirement that nodes never transmit a packet with a Hop Limit of 0. That would rule out your suggested solution to the ND spoofing problem. If we stick with the original plan of requiring link-local source addresses, note that a router need only trust those routers on its attached links (including itself) to properly desist from forwarding such packets -- it need not trust routers elsewhere in the Internet. So, network managers who install non-conformant routers, or who disable the source-address check on their conformant routers to improve performance, increase only their own vulnerability, not anyone else's. Might this (plus a check that arriving ND packets have a Hop Limit of 1) give sufficient comfort while we wait for the security folks to figure out how to do security association establishment for authenticated host-router IGMP? I'm not totally opposed to Thomas's proposed "don't forward" option. In fact, a recent proposal has been floated for a somewhat similar option in IPv4, to minimize the number of packet header checks required in the fast path of a router. The motivating problems for the IPv4 option are different (the header checks are for higher-level headers, e.g., RSVP or IGMP headers) and the semantics are different (the IPv4 option would mean "look into this packet even if it isn't addressed to you", which is not the same as "don't forward regardless of whom it is addresses to"), but the same issues are going to arise in IPv6, so maybe we should accept as reasonable the usage of hop-by-hop options to request extraordinary handling by next-hop nodes. I look forward to mulling this over at the meeting tomorrow or Thursday, even at the risk of triggering Jim's "anti-academic" reaction. :-) Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 10 09:32:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15593; Tue, 10 Oct 95 09:32:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14982; Mon, 9 Oct 95 19:49:52 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21761; Mon, 9 Oct 1995 19:37:32 -0700 Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM) id TAA09710; Mon, 9 Oct 1995 19:37:34 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id WAA03801; Mon, 9 Oct 1995 22:36:37 -0400 (EDT) Date: Mon, 9 Oct 1995 22:36:37 -0400 (EDT) From: Scott Bradner Message-Id: <199510100236.WAA03801@newdev.harvard.edu> To: dhaskin@BayNetworks.com, narten@VNET.IBM.COM Subject: (IPng 741) Re: "don't forward" hop-by-hop option? Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > This would help a bit, but a bad guy could use traceroute to figure out the exact number of hops to a destination and then send out an ND packet with the TTL set so that it is zero when it reaches the destination I don't see how this could happen, no router will transmit a packet with a 0 ttl Scott ------------------------------------------------------------------------------ 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 Oct 10 11:02:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15717; Tue, 10 Oct 95 11:02:25 PDT Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15711; Tue, 10 Oct 95 11:02:16 PDT Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id KAA23372; Tue, 10 Oct 1995 10:49:50 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id KAA12510; Tue, 10 Oct 1995 10:49:24 -0700 Date: Tue, 10 Oct 1995 10:49:24 -0700 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199510101749.KAA12510@bobo.Eng.Sun.COM> To: sob@newdev.harvard.edu Subject: (IPng 742) Re: "don't forward" hop-by-hop option? Cc: ipng@sunroof.Eng.Sun.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >routers *must not* forward packets with link-local addresses, the world >sorta ends if they do The above statement is somewhat unspecific. If routers forward packets with link-local *destination* addresses real bad things will happen. This is pretty obvious and any router that does this will be fixed real quickly. If routers forward packets with link-local *source* addresses the current scheme for not accepting Redirect packets from off-link sources (but with a "spoofed" link-local source) will break. Even though the spec says that routers MUST NOT do this I'm very concerned that some router implementation(s) will do this since it isn't obvious that such a router is broken. Thus there will be a security hole. Let's take s step back on this issue. In IPv4 arp packets do not get forwarded so off-link sources can not spoof the arp caches. However, both redirect and the ICMP router discovery messages can be received from off-link sources that spoof the IP source address. In ND we want to improve on the situation to prevent redirects and router solicitation/advertisements to be spoffable by off-link sources. However, for the redirect case the current (-02) spec still relies on the routers not forwarding packets with link-local source address. If we can agree that the Hopcount=0 method works it would be an ideal (and very simple) solution. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 10 11:09:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15729; Tue, 10 Oct 95 11:09:02 PDT Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15723; Tue, 10 Oct 95 11:08:53 PDT Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id KAA23738; Tue, 10 Oct 1995 10:56:35 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id KAA12512; Tue, 10 Oct 1995 10:56:08 -0700 Date: Tue, 10 Oct 1995 10:56:08 -0700 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199510101756.KAA12512@bobo.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 743) Re: ND Spec for Interim Meeting. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >> 3. The spec is plagued with the implementation notes that are quite > frankly not the best way to "implement" ND. Move them all to > a rationale appendix or something. I agree with Thomas. However, I'd like to clarify one thing. The spec uses a conceptual model to describe the operation of the protocol. It states up front that this is just an aid in describing the protocol and does not constrain the implementation. This is very much like the TCP spec talking about If SND.UNA < SEG.ACK =< SND.NXT This does not mandate that you have variables named snd.una etc. There are also some explicit notes along the line "This can be implemented ..." that folks have requested be added as a helpful hint to an implementor. If some of those are incorrect or misleading we should fix them. But we still need to have a spec that is readable and understandable by an implementor. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 10 12:21:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15874; Tue, 10 Oct 95 12:21:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15868; Tue, 10 Oct 95 12:21:05 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07945; Tue, 10 Oct 1995 12:08:46 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id MAA18532; Tue, 10 Oct 1995 12:08:20 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11965; Wed, 11 Oct 1995 05:03:15 +1000 (from kre@munnari.OZ.AU) To: Steve Deering Cc: dhaskin@baynetworks.com (Dimitry Haskin), ipng@sunroof.Eng.Sun.COM Subject: (IPng 744) Re: "don't forward" hop-by-hop option? In-Reply-To: Your message of "Tue, 10 Oct 1995 08:54:44 PDT." <95Oct10.085449pdt.75270@digit.parc.xerox.com> Date: Wed, 11 Oct 1995 05:02:32 +1000 Message-Id: <24231.813351752@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Tue, 10 Oct 1995 08:54:44 PDT From: Steve Deering Message-ID: <95Oct10.085449pdt.75270@digit.parc.xerox.com> For IP multicast, a packet originated with a TTL of 0 is delivered to any processes on the same node ... Hmm, Steve, I think you may be confusing things a little, such a packet almost certainly never really exists (complete with its TTL of 0) does it? What you really mean is that an application indicating that the TTL should be set to 0 is requesting that no off-node packet be sent, which is really a different thing entirely. With that interpretation, I don't see a conflict bewteen the "send with ttl == 0" as a "this packet will not be forwarded, and when received is known not to have been forwarded" use, and the use that you want to keep, and I think with good reason. What is slightly in conflict here is the API issue of just how the application indicates to the IP layer that packets should be transmitted with hop limit 0, rather than packets should not be transmitted at all, just delivered locally. I doubt this is something that would be too difficult to solve, even if the "really send hop limit 0" option is indicated in some totally different way than by using the standard set the ttl option, allowing that one to be kept for the expanding ring type search, which is likely to be more common (very few applications will ever really want to send packets with ttl 0 - only a very few well known cases I suspect, perhaps some routing protocols). I quite liked the "don't forward" option when I first saw it, it seemed to be a nice general solution with general applicability. I liked it even more when I saw the "hop limit == 0" technique suggested to implement the option (rather than a hop by hop opt. I think we should go that way, and further, that there shold probably be a sentence added to the base IPv6 spec clearly indicating that it is legal, and just what the effect is. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 10 13:36:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15932; Tue, 10 Oct 95 13:36:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15926; Tue, 10 Oct 95 13:36:31 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20594; Tue, 10 Oct 1995 13:24:12 -0700 Received: from itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id NAA06956; Tue, 10 Oct 1995 13:24:09 -0700 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA21138; Tue, 10 Oct 95 16:23:55 EDT Date: Tue, 10 Oct 95 16:23:55 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9510102023.AA21138@itd.nrl.navy.mil> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 745) ND Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I liked Steve Deering's note a lot. I think I'm way confused here, so be gentle in correcting/educating me. :-) Why not say something in ND like: "ND packets MUST be sent with a Hop Limit of 1." and say clarify the base spec's definition of Hop Limit to say: "...first decrement Hop Limit, then test the Hop Limit. If Hop Limit is zero when tested, then drop the packet." I don't think it is possible to protect against brain-damaged non-conforming routers, though we can ensure that the spec is clearly written enough that a well-intentioned implementer will get it right. Also, I'm not nervous about ND security ever since we locally tested AH (using manual key distribution) with ND among systems having an administrator-configured system security level of "all incoming and outgoing packets must be authenticated" and saw that work fine. We did have to preload the keys (for now because we don't have a Photuris daemon yet), but otherwise it worked just fine. Most sites don't need this level of security all the time, but those that do need it can have it if they wish to. Ran rja@cs.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 10 13:39:54 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15944; Tue, 10 Oct 95 13:39:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15938; Tue, 10 Oct 95 13:39:41 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21080; Tue, 10 Oct 1995 13:27:22 -0700 Received: from itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id NAA07759; Tue, 10 Oct 1995 13:27:20 -0700 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA21330; Tue, 10 Oct 95 16:27:18 EDT Date: Tue, 10 Oct 95 16:27:18 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9510102027.AA21330@itd.nrl.navy.mil> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 746) rationale in the ND document Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I like having rationale in the ND document as part of the main body of text, so I'm with Scott Bradner on this. IETF documents with embedded rationale have a better interoperability track record. I don't want us to need a Host Requirements document for IPv6 the way we did for IPv4 if we can avoid it. Although I've worked for years with POSIX in the IEEE, I have never liked and always found it confusing that they separated rationale out into a separate appendix (making it harder for me to read their real intent). Further, I find that the published IEEE standards often get so watered down in the name of "not restricting the implementer" that the goal of application portability was sometimes lost. There is some middle ground here and I hope we can find it. Ran rja@cs.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 10 13:51:01 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15957; Tue, 10 Oct 95 13:51:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15951; Tue, 10 Oct 95 13:50:48 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22941; Tue, 10 Oct 1995 13:38:28 -0700 Received: from itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id NAA10825; Tue, 10 Oct 1995 13:38:17 -0700 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA21881; Tue, 10 Oct 95 16:38:14 EDT Date: Tue, 10 Oct 95 16:38:14 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9510102038.AA21881@itd.nrl.navy.mil> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 747) ND and router preferences Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I am concerned that Francis Dupont won't be at the ND meeting this week to explain and discuss his idea for router preferences (which I happen to like and I think I mostly understand it; though I'm often confused so add salt to taste). I don't think the set of folks at the meeting this week should spend too much time on the Router Preferences matter. Instead, we ought to try to resolve that on the list or in Dallas. While I agree with the goal of getting ND to RFC, I am not comfortable with moving to RFC until we resolve the Router Preferences issue within the working group. Ran rja@cs.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 10 14:10:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15985; Tue, 10 Oct 95 14:10:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15979; Tue, 10 Oct 95 14:10:02 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26143; Tue, 10 Oct 1995 13:57:41 -0700 Received: from wizard.gsfc.nasa.gov by mercury.Sun.COM (Sun.COM) id NAA15998; Tue, 10 Oct 1995 13:57:31 -0700 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA12448; Tue, 10 Oct 95 16:53:05 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9510102053.AA12448@wizard.gsfc.nasa.gov> Subject: (IPng 748) Re: ND Spec for Interim Meeting. To: sob@newdev.harvard.edu (Scott Bradner) Date: Tue, 10 Oct 1995 16:53:04 -0400 (EDT) Cc: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM In-Reply-To: <199510100011.UAA03462@newdev.harvard.edu> from "Scott Bradner" at Oct 9, 95 08:11:20 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 > > Such explanations also make the spec more complex to implement. > > well, we are in specific disagreement. > > Its time for others to add their opinions > > Scott Well, I'm not an implementor, but just someone who has to read the specs and hopefully understand them, when trying to diagnose network problems to accurately determine what system or systems are not behaving properly. In that regard, I like the idea of protocol and implementation issues being discussed in the main body of the text. As long as the implementation discussions are clearly delineated as such (so they can be easily skipped over if desired), and not protocol spec, I don't think there should be a problem. I don't see how a discussion of implementation matters or general protocol issues would make the underlying base protocol spec any more complex to implement. I would hope that it would significantly increase the likelihood of correct and interoperable implementations. -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 Tue Oct 10 14:55:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16098; Tue, 10 Oct 95 14:55:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16092; Tue, 10 Oct 95 14:55:27 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03267; Tue, 10 Oct 1995 14:43:08 -0700 Received: from catarina.usc.edu by mercury.Sun.COM (Sun.COM) id OAA28481; Tue, 10 Oct 1995 14:43:01 -0700 Received: from tampico.usc.edu (tampico.usc.edu [128.125.52.5]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id OAA27168 for ; Tue, 10 Oct 1995 14:42:59 -0700 Message-Id: <199510102142.OAA27168@catarina.usc.edu> X-Authentication-Warning: catarina.usc.edu: Host tampico.usc.edu didn't use HELO protocol X-Mailer: exmh version 1.6 4/21/95 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 749) Interim meeting Mboned? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Oct 1995 14:42:58 -0700 From: Mikael Degermark Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Will the interim meeting be mboned? I'd like to be able to listen in... Mikael Degermark ------------------------------------------------------------------------------ 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 Oct 10 15:00:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16126; Tue, 10 Oct 95 15:00:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16120; Tue, 10 Oct 95 15:00:13 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04006; Tue, 10 Oct 1995 14:47:54 -0700 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id OAA29757; Tue, 10 Oct 1995 14:47:52 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA02431; Tue, 10 Oct 95 17:46:43 EDT Received: from cabernet.engeast by BayNetworks.com (4.1/SMI-4.1) id AA01602; Tue, 10 Oct 95 17:47:48 EDT Date: Tue, 10 Oct 95 17:47:48 EDT From: rcallon@BayNetworks.com (Ross Callon) Message-Id: <9510102147.AA01602@BayNetworks.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 750) Resignation as co-chair (long live the co-chair) Cc: rcallon@BayNetworks.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I am sorry to announce that I am resigning as co-chair of the IPng working group, effective the Interim meeting next week. The demands of other work has prevented me from putting as much time into IPng as I would have liked. Also, with the birth of my daughter a couple of weeks ago (IMHO the cutest little girl in the world) I would prefer to cut back a bit on travel and extra activities. I continue to be a enthusiastic supporter of IPv6 and related efforts. I am convinced that there is a need for a ubiquitous "into every home and small business" worldwide Internet, and that for many reasons IPv6 is the best candidate for offering end to end service in the global ubiquitous Internet. Bay Networks will continue to actively participate in the IPng effort, and will continue our current implementation effort. Steve Deering will be continuing as co-chair of the IPng working group. Bob Hinden will be joining him as co-chair as well as continuing as document editor. I wish them the best of continued success. I would also like to thank Steve, Bob, Scott Bradner, Allison Mankin, and the members of the IPng working group and the IPng directorate. Obviously the task of designing and agreeing on the details of IPv6 was a difficult technical and political process. I think that this process has been very successful and will continue to be very successful. I am pleased to have had the opportunity to participate in this effort. thanks, Ross ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 10 15:13:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16145; Tue, 10 Oct 95 15:13:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16139; Tue, 10 Oct 95 15:13:50 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05877; Tue, 10 Oct 1995 15:01:30 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id PAA02701; Tue, 10 Oct 1995 15:01:26 -0700 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA29880; Tue, 10 Oct 1995 18:01:21 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16323; Tue, 10 Oct 1995 18:01:19 -0400 Message-Id: <9510102201.AA16323@wasted.zk3.dec.com> To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 751) Re: ND and router preferences In-Reply-To: Your message of "Tue, 10 Oct 95 16:38:14 EDT." <9510102038.AA21881@itd.nrl.navy.mil> Date: Tue, 10 Oct 95 18:01:18 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I have sent mail per Francis's mode per Steve asking me to. I think we need to discuss it. I want to implement that way now and need some direction. I am prepared to explain it at the meeting. What we will find also is that we cannot ignore the Multihome issue anymore. But I will say more at the meeting. /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 Tue Oct 10 15:28:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16163; Tue, 10 Oct 95 15:28:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16157; Tue, 10 Oct 95 15:28:33 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07924; Tue, 10 Oct 1995 15:16:13 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id PAA02794; Tue, 10 Oct 1995 15:16:10 -0700 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA00692; Tue, 10 Oct 1995 18:16:02 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16410; Tue, 10 Oct 1995 18:15:57 -0400 Message-Id: <9510102215.AA16410@wasted.zk3.dec.com> To: Steve Deering Cc: dhaskin@baynetworks.com (Dimitry Haskin), ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com Subject: (IPng 752) Re: "don't forward" hop-by-hop option? In-Reply-To: Your message of "Tue, 10 Oct 95 08:54:44 PDT." <95Oct10.085449pdt.75270@digit.parc.xerox.com> Date: Tue, 10 Oct 95 18:15:57 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >extraordinary handling by next-hop nodes. I look forward to mulling this >over at the meeting tomorrow or Thursday, even at the risk of triggering >Jim's "anti-academic" reaction. :-) Hmmm. I don't mind discussion to solve a technical problem that has merit. I do mind if I don't think its relative. Security spoofing is one issue I think we will rat hole on. If we want to discuss next hop nodes and determine if that is in error or can be made better thats a good discussion. I am not clear your need of the inner-ring with old technology use is a good idea. You need to be more specific for me to buy into your mail. I look forward to that explanation. And I have as much of an issue with preferences as Francis its broken and we cannot ignore multihome or we all guess at it now I have a multihome node in my office and will want to run my IPv6 code on it. Do you want me to just guess or go have an academic discussion with someone and make my own decision, but I probably won't interoperate with anyone either. /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 Tue Oct 10 20:34:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16467; Tue, 10 Oct 95 20:34:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16461; Tue, 10 Oct 95 20:34:15 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11917; Tue, 10 Oct 1995 20:21:54 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id UAA22715; Tue, 10 Oct 1995 20:21:54 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16917(2)>; Tue, 10 Oct 1995 20:19:48 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 10 Oct 1995 20:19:42 -0700 To: Mikael Degermark Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng 753) Re: Interim meeting Mboned? In-Reply-To: micke's message of Tue, 10 Oct 95 14:42:58 -0800. <199510102142.OAA27168@catarina.usc.edu> Date: Tue, 10 Oct 1995 20:19:29 PDT From: Steve Deering Message-Id: <95Oct10.201942pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Mikael, > Will the interim meeting be mboned? Unfortunately, no. Our hosts were not able to get MBone-ready in time. I believe they are going to try to videotape the meeting, so we may be able do a delayed multicast from a different site. If so, it will be announced on this list ad the rem-conf list. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 10 20:45:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16479; Tue, 10 Oct 95 20:45:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16473; Tue, 10 Oct 95 20:45:03 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12407; Tue, 10 Oct 1995 20:32:41 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id UAA23840; Tue, 10 Oct 1995 20:32:41 -0700 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA13940; Tue, 10 Oct 1995 23:32:33 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA32020; Tue, 10 Oct 1995 23:32:31 -0400 Message-Id: <9510110332.AA32020@wasted.zk3.dec.com> To: bill@wizard.gsfc.nasa.gov (Bill Fink) Cc: sob@newdev.harvard.edu (Scott Bradner), bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng 754) Re: ND Spec for Interim Meeting. In-Reply-To: Your message of "Tue, 10 Oct 95 16:53:04 EDT." <9510102053.AA12448@wizard.gsfc.nasa.gov> Date: Tue, 10 Oct 95 23:32:30 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >As long as the implementation discussions are clearly delineated as >such (so they can be easily skipped over if desired), and not protocol >spec, I don't think there should be a problem. I don't see how a >discussion of implementation matters or general protocol issues would >make the underlying base protocol spec any more complex to implement. >I would hope that it would significantly increase the likelihood of >correct and interoperable implementations. My main concern is that they are clearly delineated and they are not in all cases in the ND spec. I will point this out in the meeting this week. When I write code to a spec I first get the jist of the spec (Overview). Then I extract the rule-sets for the data I must write the code for in my mind. Then I write the code adhereing to those rule-sets (e.g. protocols, APIs, Graphics primitives). During that process I absorb the algorithms within the modules of the code as "required". If I need to build a data structure to make my implementation more efficient (e.g. cache, queue, hash, search tree) then I go design that in the most efficient way depending on what my goal is whether public domain across many platforms or for a dedicated platform to one task (lots of decisions for this). This is one reason I am called an engineer. The reason POSIX specs don't specify implementation details (and say its implementation defined) is because a standard can become a legal binding contract once implemented at a users. With implementation words in a spec future implementors will have to educate users why they did not implement the spec the way per the examples potentially or give readers of the spec false expectations. I am not sure I agree with all of that its my understanding at a 2000ft level. But once I understand the spec and the jist and start impelementing I want a section in the standard that just has the basics I referenced above and only them on the paper I am using to write the code from in the standard and for testing later too. The POSIX rationales are not implementation reference they are the rational why decisions were made in a standard during the course of that standard being developed for future reference. Its much more robust than the typical FAQ used in ad hoc environments (a FAQ could be that detailed but I don't usually find them to be). Its more formal and rigourous. I like that better than other strategies thats the real disagreement. I will also add that POSIX also develops test assertions at times for standards and I find that very useful to really test a standard. This is the real psuedo implementation test and very rigourous. So there are three aspects to standardization I am familiar with from working on them for many years (.1, .3, .4, .8, and .12). 1. Develop the Standard (rule-sets, data structures, processing, terminology, and algorithms). 2. State MUST, SHOULD, MAY and IMPLEMENTATION DEFINED. Add variations of the negative NOT. 3. During the course of developing the standard record the rationale for why decisions and consensus was achieved. 4. Perform test assertions against the standard as realated to ASN language or in a programming language that has a standard. This helps flush out impelementation bugs in the standard too. I do not know of any POSIX standard that has caused interoperability problems and I do not believe this in the general case. Of course there are bugs. We have the above in the IETF too, but what we lack is often the rationale for why decisions were made. 1122 and 1123. Well I am one of the implementors of this and all I will say is that should never happen again. Where ever we check that the standard can be implemented in words is important. I never said we should not do it but put it in a rationale or implementation appendix that is not part of the standard. At a minimum it should be clearly distinguishable from the words that are the standard. On that I hear consensus. I just felt that not having it mixed up with the standards wordage we run less risk of that happening. But it seems others want the risk for reasons I feel are valid, but I am not sure folks see the risk and that makes me quite nervous. But I have been nervous before in the effort to do IPv6. Thats fine. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 11 02:33:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16615; Wed, 11 Oct 95 02:33:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16609; Wed, 11 Oct 95 02:33:09 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14532; Wed, 11 Oct 1995 02:20:49 -0700 Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM) id CAA01559; Wed, 11 Oct 1995 02:20:47 -0700 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: (IPng 755) Re: ND Spec for Interim Meeting. To: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) Date: Wed, 11 Oct 1995 10:21:48 +0100 (BST) Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <199510101756.KAA12512@bobo.Eng.Sun.COM> from "Erik Nordmark" at Oct 10, 95 10:56:08 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > There are also some explicit notes along the line "This can be implemented > ..." that folks have requested be added as a helpful hint to > an implementor. If some of those are incorrect or misleading > we should fix them. But we still need to have a spec that is > readable and understandable by an implementor. So long as the spec says 'The implementation notes are a guideline. To fullfill the specification only requires the system exhibit the defined external behaviour' its not an issue. And yes while that is an assumption of RFC's its an often unwritten one. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 11 04:46:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16672; Wed, 11 Oct 95 04:46:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16666; Wed, 11 Oct 95 04:46:38 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19312; Wed, 11 Oct 1995 04:34:18 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id EAA14358; Wed, 11 Oct 1995 04:34:18 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14455(4)>; Wed, 11 Oct 1995 04:34:12 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 11 Oct 1995 04:34:07 -0700 To: rcallon@baynetworks.com (Ross Callon) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 756) Re: Resignation as co-chair (long live the co-chair) In-Reply-To: rcallon's message of Tue, 10 Oct 95 14:47:48 -0800. <9510102147.AA01602@BayNetworks.com> Date: Wed, 11 Oct 1995 04:33:53 PDT From: Steve Deering Message-Id: <95Oct11.043407pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > I am sorry to announce that I am resigning as co-chair of the IPng > working group, effective the Interim meeting next week. Speaking for the working group, we are sorry to lose you, Ross. Thank-you for your many contributions to the IPng process and content; we hope there will be more in the future, when your other commitments allow. Steve p.s. A minor correction: the Interim ipngwg meeting is this week (today, in fact), not next week. ------------------------------------------------------------------------------ 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 Oct 11 08:17:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16764; Wed, 11 Oct 95 08:17:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16758; Wed, 11 Oct 95 08:17:28 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02399; Wed, 11 Oct 1995 08:05:07 -0700 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id IAA19854; Wed, 11 Oct 1995 08:05:06 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10978; 11 Oct 95 9:26 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 757) I-D ACTION:draft-ietf-ipngwg-ethernet-ntwrks-01.txt Date: Wed, 11 Oct 95 09:26:42 -0400 Message-Id: <9510110926.aa10978@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : A Method for the Transmission of IPv6 Packets over Ethernet Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-ethernet-ntwrks-01.txt Pages : 4 Date : 10/10/1995 This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. It also specifies the content of the Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used the the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in [DISC], when those messages are transmitted on an Ethernet. 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-ethernet-ntwrks-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ethernet-ntwrks-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ethernet-ntwrks-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: <19951010134432.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ethernet-ntwrks-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ethernet-ntwrks-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951010134432.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 13 08:31:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18141; Fri, 13 Oct 95 08:31:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18135; Fri, 13 Oct 95 08:31:35 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04095; Fri, 13 Oct 1995 08:19:09 -0700 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id IAA04924; Fri, 13 Oct 1995 08:19:09 -0700 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HWDZENUQPC005HSJ@FNAL.FNAL.GOV>; Fri, 13 Oct 1995 10:18:31 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA12054; Fri, 13 Oct 95 10:17:14 CDT Date: Fri, 13 Oct 1995 10:17:13 -0500 From: Matt Crawford Subject: (IPng 758) Re: Interim meeting Mboned? In-Reply-To: Your message of Tue, 10 Oct 95 20:19:29 PDT. <95Oct10.201942pdt.75270@digit.parc.xerox.com> To: Steve Deering Cc: ipng@sunroof.Eng.Sun.COM Message-Id: <9510131517.AA12054@munin.fnal.gov> Content-Transfer-Encoding: 7BIT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > Will the interim meeting be mboned? > > Unfortunately, no. ... I hope minutes will be posted promptly. Minutes of the February interim meeting were never sent -- only something called "the draft version of the minutes," which was met with several objections. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------------------------------------------------------------------------------ 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 Oct 16 17:51:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19640; Mon, 16 Oct 95 17:51:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19634; Mon, 16 Oct 95 17:51:26 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03475; Mon, 16 Oct 1995 17:38:56 -0700 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id RAA21410; Mon, 16 Oct 1995 17:38:55 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa18715; 16 Oct 95 19:06 EDT To: IETF-Announce:;@mercury Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.Eng.Sun.COM From: IESG Secretary Subject: (IPng 759) Document Action: SIPP/SIP documents to Historic Date: Mon, 16 Oct 95 19:06:42 -0400 Message-Id: <9510161906.aa18715@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The IESG recommends that the following nine Internet-Drafts be published by the RFC Editor as Historic documents: 1. IPv6 Security Architecture 2. Simple Internet Protocol Plus (SIPP) Specification (128-bit address version) 3. DNS Extensions to support Simple Internet Protocol Plus (SIPP) 4. The SIPP Interoperability and Transition Mechanism 5 ICMP and IGMP for the Simple Internet Protocol Plus (SIPP) 6. Simple Internet Protocol Plus (SIPP): DHCP Options and BOOTP Vendor Extensions 7. Simple Internet Protocol Plus (SIPP): Addressing Architecture 8. Simple Internet Protocol Plus (SIPP): Unicast Hierarchical Address Assignment 9. OSPF for SIPP These documents are currently under the auspices of the IPNGWG Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. Technical Summary These documents are being published as a part of the historical record of the IETF IPng effort. Working Group Summary These documents represent the SIPP proposal that was reviewed by the IPng directorate and Area Directors during their deliberations. NOTE TO RFC EDITOR: When published as RFCs, the following text should be included: This document is only being published for historical reasons and should not be considered as representing the current state of the IETF protocol development efforts, or as describing any part of IPv6. ------------------------------------------------------------------------------ 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 Oct 17 09:40:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20127; Tue, 17 Oct 95 09:40:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20121; Tue, 17 Oct 95 09:40:25 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29003; Tue, 17 Oct 1995 09:27:54 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id JAA20887; Tue, 17 Oct 1995 09:27:51 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14910(1)>; Tue, 17 Oct 1995 09:25:36 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 17 Oct 1995 09:25:16 -0700 To: iesg@cnri.reston.va.us Cc: rfc-editor@isi.edu, iab@isi.edu, ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng 760) Re: Document Action: SIPP/SIP documents to Historic In-Reply-To: iesg-secretary's message of Mon, 16 Oct 95 16:06:42 -0800. <9510161906.aa18715@IETF.CNRI.Reston.VA.US> Date: Tue, 17 Oct 1995 09:25:04 PDT From: Steve Deering Message-Id: <95Oct17.092516pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Dear IESG, > The IESG recommends that the following nine Internet-Drafts be > published by the RFC Editor as Historic documents: > > ... > > 2. Simple Internet Protocol Plus (SIPP) Specification (128-bit > address version) > It is historical revisionism to publish that version as the Historical SIPP specification. SIPP was a 64-bit-address protocol. The "128-bit version of SIPP" existed for only about a week before being dubbed IPv6. (It is more properly considered the 00 draft of IPv6, rather than a SIPP spec.) All the rest of the documents in the SIPP set refer to 64-bit addresses, so it's rather incongruous to associate them with a base spec that specifies 128-bit addresses. I have a version of the spec that is identical to draft-ietf-sipp-spec-01 excluding the change of address size, if you would like that for publication instead of, or in addition to, the above listed document. Also, it would have been nice if you had discussed your intentions to publish the SIPP documents as RFCs with the ipng working group, or at least the authors, before announcing your decision. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 17 12:12:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20220; Tue, 17 Oct 95 12:12:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20214; Tue, 17 Oct 95 12:12:01 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23912; Tue, 17 Oct 1995 11:59:32 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id LAA11902; Tue, 17 Oct 1995 11:58:59 -0700 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA01548; Tue, 17 Oct 1995 14:58:36 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23541; Tue, 17 Oct 1995 14:58:31 -0400 Message-Id: <9510171858.AA23541@wasted.zk3.dec.com> To: Steve Deering Cc: iesg@cnri.reston.va.us, rfc-editor@isi.edu, iab@isi.edu, ipng@sunroof.Eng.Sun.COM Subject: (IPng 761) Re: Document Action: SIPP/SIP documents to Historic In-Reply-To: Your message of "Tue, 17 Oct 95 09:25:04 PDT." <95Oct17.092516pdt.75270@digit.parc.xerox.com> Date: Tue, 17 Oct 95 14:58:31 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Steve, As an IPng WG member and past IPng Directorate member I agree with you completely per your mail to the IESG. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 18 11:03:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20851; Wed, 18 Oct 95 11:03:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20355; Tue, 17 Oct 95 15:26:25 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21492; Tue, 17 Oct 1995 15:13:55 -0700 Received: from dylan.mindspring.com by mercury.Sun.COM (Sun.COM) id PAA28936; Tue, 17 Oct 1995 15:13:54 -0700 Received: from sthomas.mindspring.com [168.121.37.118] by dylan.mindspring.com with SMTP id SAA15555 for ; Tue, 17 Oct 1995 18:13:47 -0400 Message-Id: <199510172213.SAA15555@dylan.mindspring.com> X-Sender: sthomas@mindspring.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Oct 1995 18:09:25 -0400 To: ipng@sunroof.Eng.Sun.COM From: Stephen Thomas (by way of Stephen Thomas ) Subject: (IPng 762) IPv6 Multicast / Priority Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Kind Readers: Please consider this a solicitation for advice and comments. (In other words, help! ;^) Many of you are probably aware of the problems facing any type of multicast services that want to run over Token Ring. Because of the design of most (all?) token ring chipsets, link layer multicast addresses are exceedingly scarce. For all practical purposes, IPv6 has only a single multicast address at its disposal. The current IPv6-over-Token-Ring draft specifies that *all* IPv6 multicasts must use this single link address. No doubt you see the problem. Even a low cost device (e.g. one of those little boxes you stick on your printer to do network printing without a real print server) has to listen to at least some multicast traffic. (Neighbor discovery and whatnot.) With the current scheme, however, that same little device will be asked to receive (and discard) all of the vast flows of multicast traffic from video conferences and other such applications. There is a ray of hope, however. Token Ring does have a broadcast address that is distinct from its multicast addresses. If it were feasible to do so, systems could map all necessary control traffic (e.g. neighbor discovery) to the broadcast link address and all application traffic (video conferences) to the single multicast address. My feeling is that such an approach follows the 80-20 rule rather nicely. (It solves 80% of the problem with only 20% of the effort.) Of course, the major question that arises is how should a system distinguish control traffic from user applications. I can only think of two possibilities: A) Priority. Require all control traffic to specify a priority of 7, and use the priority to select the link level address. IMHO, requiring (*must* rather than should) priority 7 for control traffic so far defined is a very good thing, but selecting a link address based on that priority is not so good. Can we really guarantee that all future control traffic is appropriately prioritized as 7? B) The T-bit in the destination multicast address. All well-known destinations could map to the Token Ring broadcast while transient destinations use multicast. IMHO, using the T bit to select link addresses is quite reasonable. We might not achieve a perfect division of control and user traffic, but it again seems to solve a good bit of the problem. The presumption, of course, is that any traffic that all nodes would be required to accept would be destined to a well-known address rather than a transient. Does this seem reasonable? I do recall a superficially similar discussion on the list with regards to Ethernet controllers and the effectiveness of their multicast hash algorithms. There is a very big difference between this problem and that, however. With Ethernet, we can specify a multicast mapping that might not be optimal for current chipsets, but at least it works. Then, as Ethernet chipsets evolve, they can become more proficient at handling multicasts. In the Token Ring case, though, we either work with the installed base or we don't. (The second option seems like a non-starter to me.) If we work with the installed base, though, then we have no effective way to migrate to a new approach. (Well, we could always opt for manual configuration, but, I've thought about this one quite a bit and concluded that it isn't really workable. If you want more details, just ask.) I'm in the process of revising the Token Ring draft now. I'm leaning towards option B above, but would definitely like to get some feedback before proceeding. Thanks in advance. --Stephen ____________________________________________________________ Stephen Thomas AT&T Tridom Phone: (770) 514-3522 840 Franklin Court Fax: (770) 514-3491 Marietta, GA 30067 USA Email: stephen.thomas@tridom.com (Until 1Dec95, the previous area code of 404 also works.) ------------------------------------------------------------------------------ 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 Oct 18 13:22:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20983; Wed, 18 Oct 95 13:22:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20943; Wed, 18 Oct 95 12:24:55 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03557; Wed, 18 Oct 1995 12:12:21 -0700 Received: from walnut.ipsilon.com by mercury.Sun.COM (Sun.COM) id MAA14078; Wed, 18 Oct 1995 12:12:15 -0700 Received: (from hinden@localhost) by walnut.ipsilon.com (8.6.11/8.6.9) id MAA25808; Wed, 18 Oct 1995 12:12:12 -0700 Date: Wed, 18 Oct 1995 12:12:12 -0700 From: "Robert M. Hinden" Message-Id: <199510181912.MAA25808@walnut.ipsilon.com> To: ipng@sunroof.Eng.Sun.COM, addrconf@cisco.com Cc: hinden@ipsilon.com, minutes@cnri.reston.va.us Subject: (IPng 763) IPng/AddrConf Interm Meeting Notes Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk IPng/AddrConf Working Groups Interim Meeting October 11 & 12 1995 Dyncorp, Arlington, VA Minutes produced by Robert Hinden / Ipsilon Networks -------------------------------------- Attendees: Steve Deering / Xerox PARC Robert Hinden / Ipsilon Thomas Narten / IBM Erik Nordmark / Sun Alex Conta / Digital Dan McDonald / NRL Tim Hartnick / Mentat Gaetan Feige / ISI Bob Gilligan / Sun Scott Behnke / Dyncorp Richard Colella / NIST Steve Silverman / BTNA Rob Glenn / NIST Peter Grehan / Ipsilon Sue Thompson / Bellcore Jim Bound / Digital Dan Harrington / Digital Allison Mankin / ISI Matt Thomas / Digital -------------------------------------- Agenda o Administrivia Introductions Note Taker Chairship videotaping Document Status o IPv6 Payload Header o AddrConf Discussion of Latest Specifications o Neighbor Discovery o IP over Foo Documents o "IGMP" for link local multicasts -------------------------------------------------------------------- Wednesday, October 11, 1995 -------------------------------------------------------------------- The meeting was hosted by Scott Behnke / Dyncorp and Allison Mankin / ISI. Robert Hinden agreed to take notes for the meeting. Steve Deering announced that Ross Callon was stepping down and Robert Hinden will be the new co-chair (and continue to be document editor). Steve Deering reviewed standards status. Base specification, address architecture, ICMP, and DNS specifications were approved by IESG to be Proposed Standards. Provider assignment architecture was approved for informational. All are being submitted to RFC editor to become RFC's. IETF last call being done for NSAP doc. Working group last call completed for Provider Formats and Test Allocations addressing drafts. No comments on Test Alloc. Only discussion on Provider Based was if it should be Informational, BCP, or PS. This Issue was discussed. Group agreed that Provider doc should be advanced as a Proposed Standard. Chairs will send note to IESG requesting these docs be advanced w/ cc to working group. ---------------------------------------------------------------------- IPv6 Payload Header ---------------------------------------------------------------------- Discussion on "The IPv6 Payload Header" draft. It would be used to identify how multiple headers (e.g., more than one TCP header) could be combined in one IPv6 packet. Issue raised that might be hard to implement if several non-related headers were included. It would have to be required to be implemented by everyone to be useful. Discussion of benefits and costs. There does not appear to be any commercial implementations of TMUX (somewhat similar for IPv4). There does not be enough support in w.g. to advance this to the IESG at this time. Members of working group should review this document and comment if there is interest. At this time there is not enough motivation to require this to be required for universal implementation. Suggestion also made for some implementation experience before considering this for advancement to become a standard. Most people have not read the draft, not much interest, author will have to make a better case. ---------------------------------------------------------------------- Addr Conf ---------------------------------------------------------------------- Sue Thomson / Thomas Narten (gave presentation) Open Issues: o Duplicate address detection o Loop back semantics o Changing "AutoConfig" flag on running systems o Terminology for MAC address o Node vs. Router o Configurability of "DuplAddrDetect" o Separate ICMP Message for AddrConf and ND ------- Strength of Duplicate address detection Discussion of sending out single packet or retransmission. Most people thought only single NS was enough. It would be nice to not delay booting waiting for an answer. Current implementations of duplicate detection in IPv4 (using ARP) do not wait. However, if duplicate addresses are present, immediate use causes problems for existing interfaces using the same address. Waiting for DAD to complete avoids this problem. Suggestion for different modes of operation depending on type of address (autoconfigured addresses, dynamically assigned, manually assigned). Suggestion for sending one NS packet, waiting a short period of time (one second) for duplicate. Pick generic default for Addrconf and allow specific IPoverFoo documents to set new default value for a particular media. Group agreed that default behavior should be to send single NS packet, and wait for 1 second to detect duplicates, and that these values be configurable. A specific IPoverFoo document could define a link specific value to change default values. The number of retransmissions is also link type specific. [See later discussion] Discussion of how much random delay before sending NS. The current value is 3 sec, which is larger than the random delay used before sending out a RS in ND. One of the differences is that all nodes will send an NS, whereas nodes will desist from sending an RS on hearing a RA. ------- Discussion of whether hosts can do duplicate detection and router discovery in parallel (or does it have to be sequential). Parallel is preferred, since it reduces time before normal operation can start, but requires that RAs are solicited using the unspecified address and that RAs are multicast. [See later discussion] -------- Configurability of Duplicate Address Detection Flag Currently per interface configuration flag. Change text to require duplicate detection of link local address. Other addresses derived using this, do not need to be checked for duplicates. (This avoids the problem in stateless autoconfiguration of having different interfaces choose different addresses to apply duplicate address detection to.) Duplicate detection required for all stateful and manually configured addresses. Instead of having this flag, there are now two per interface variables to do with duplicate address detection. First variable indicates how many times a solicitation is sent for duplicate detection. Second is timer value for interval between retransmissions. Default values are 1 transmission, and 1 second. Duplicate address detection is disabled by setting first value to zero. Hence, no need for separate "Duplicate address detection flag" -------- Semantics of Multicast loopback The current text looks OK. One further thing to consider though. Loopback is undesirable for general multicast applications. Thus, IPv4 multicast specification requires that driver suppress loopback. If not possible to disable hardware, driver software needs to filter out loopback multicast packets. If this filtering is done by comparing the source address of the packet with that of the interface, i.e. dropping packets whose link-layer source address is the same as that of the interface, then this breaks DAD in the case where duplicate addresses result from duplicate interface tokens (e.g., two interfaces both using the same link-layer address). Prefer interface to not loopback multicast packets. Approach should be to configure hardware to not loopback, or have driver (in software) detect duplicates with a mechanisms other than looking at the source address. If the two previous are not possible, then a trade-off needs to be made: allow loopback (allows duplicate address detection to work, but inefficient in terms of multicast interrupts) or suppress loopback by comparing source address of incoming packet and interface (reduces number of interrupts, but disables duplicate address detection). It is possible that an implementation might make loopback suppression configurable in this case, i.e. only turn it on when duplicate address detection done. Agreed that text will be added to document explaining the problem, but leave as an implementation issue how resolved. ---------- "AutoConfig" Flag What happens if flag turned off and on in running system? Should addresses from previous incarnations be kept until they time out, or should address list be reinitialized each time flag turned on? Discussion leading to conclusion that this should be an implementation issue. Discussion of what "AutoConfig" flags means. First, should the flag apply to formation of the link-local address? There was agreement that it should not. That is, the link-local address is always formed. The implication of this decision is that there needs to be a way for the token to be configurable, in the (rare) case, when the token is found not to be unique. Suggestion for advice in IPoverFoo specs for what to do if duplicate is detected. Second, what part of Router Advertisements should the "AutoConfig" flag apply to, just stateless auto-generation of global or site-local addresses or all autoconfiguration information in router advertisements? What does flag say about using stateful mechanism in absence of RAs? One suggestion was that the "AutoConfig" Flag should only refer to the automatic creation of addresses and bit flags telling hosts to use DHCP (e.g., ignore this information in router advertisements). Other functions not affected (e.g., duplicate detection, link local, router discovery, routing prefixes, etc.) Another suggestion was for two independent flags, one for disabling stateless and one for disabling stateful autoconfiguration. On working through these options, it became clear that there were several ways of defining the semantics, and that the spec need not mandate any one way. Thus, the conclusion was to not specify specific variables, but just for the spec to say that it should be locally possible to disable all autoconfiguration functions, and that the functions must be enabled by default. ----------- Node vs. Router What part of the functions in the document should apply to routers? The conclusion was that routers are outside the scope of the document, with the exception of formation of the link-local address and duplicate address detection, which apply to all IPv6 nodes. Discussion about whether the addr conf doc should describe how addresses are created, or whether it should be in the IPoverFoo documents. The latter might require IPv6 code to know about different mechanisms to create address for each IPoverFoo type. After discussion, group agreed that IPoverFoo specs need to specify the rules for handling the bits in the address token and the AddrConf spec should describe putting the prefix and token together. Steve Deering suggested: Define interface tokens as bit strings. AddrConf spec defines how to append bit strings with prefix to form an address. IPoverFoo specs specify how to create a bit string and may give an example of what a link local address looks like for this media (to avoid confusion about bit orderings). Prefix + address token must equal 128 bits. Router is required to advertise prefixes which when combined with the token for that particular interface type add up to 128 bits. Zero padding not allowed, since padding rules may be link-specific. --------- Terminology for MAC/Hardware address Should be "Link-Layer Address" ----------- Terminology Current spec uses the following terminology: Preferred Address Deprecated Address Preferred Lifetime Time-till-deprecation Valid Lifetime Time-till-invalidation Group agreed these terms were OK. -------- Discussion about whether document applies to point-to-point links, tunnels and NBMA networks. Specification will be updated to clarify that this specs requires the use of multicast on networks. This does not mean to say, however, that parts of the spec, e.g. formation of link-local address, may not apply to non-multicast capable networks. -------- Separate ICMP Messages for Addrconf and ND Jim Bound requested that different ICMP messages be used for addr conf and ND. He wants different machines to be able to send each type of message. Doesn't like the "extra" complexity of receiving combined information. However, it was not clear how the information should be divided up, e.g. separation of prefix advertisements from other information advertised by routers, or separation of address-related information (and possibly other configuration parameters) from router advertisements, etc. Group conclusion was to not divide this information into separate ICMP messages. ------ [Non- addrconf related item] The ICMP redirect will be given a code out of the informational instead of the error cases. Code will be 137. ------ Group agreed that with the changes/clarifications made in this meeting, addr conf (once revised) can go forward to Proposed Standard. ---------------------------------------------------------------------- Neighbor Discovery ---------------------------------------------------------------------- Erik Nordmark (presenting) & Thomas Narten Outstanding Issues: o Messages from off link sources o Extra NUD probes for unsolicited information o IPv6 Priority field in ND packets o Randomizing Reachable Time o RS with unspecified source o Retransmission Timer = 10 sec. o Preferences for Default Routers o Prefix Redirects (instead of just host redirect) o Reachable Confirmation / Negative vs. positive & Implementation Issues o Implementation Language o MTU Advertisements (per receiver MTU's) ----- Messages from off link sources Don't want to have to deal with messages which might have leaked in from outside of the local link. Issue is malicious attach from off link. Long discussion. Suggestion to always do NUD using link-local address. All advertisements would include both global and link-local address. Suggested alternatives (to solve the off net problem) are hoplimit=0 and/or "don't forward" IPv6 option. "router process" with proper semantics would help other (somewhat related) problems. This plus a flag could tell routers to drop these packets. [See later discussion about hoplimits] Much more additional discussion. Possible solutions to multiple NUD probes are: 1) carry link-local in all packets 2) zero element source route. Discussion about not using link-local address as source of this packet because it also causes an 8 packet NUD exchange. General consensus that we should use a "do not forward" hop-by-hop option and use global source address instead of link-local address. Recipient checks if "do-not-forward" option present. This seems to deal with off net attacks (either router drops or destination drops) and stops 8 packet NUD exchange (back to four packets with special rules or other mechanisms). Possible choices are: o Carry Link local in all ND messages o Do nothing to special to defend against off net attacks o Don't forward option o Keep current spec operation of saying to not do NUD for ND packets. Queried everyone in room to gauge consensus. Result was: Four said they liked "don't forward" option Eight said they liked keep current spec One for "Alert" option to require router to do full processing More discussion. Will revisit on second day of meeting after Erik Nordmark and Thomas Narten present summary of changes required to ND for making "don't forward" change. ------------ IPv6 Priority in ND Packets Suggestion is to make ND packets high priority (over video and audio). Proposal is to set it to 15 (highest value). --------------- Randomizing Reachable Time Time to send next probe. Each time need to send Range 0.5 - 1.5 (x 30 seconds) Use this unless get new value from router advertisements. Concern is for nets without routers, will always use same value. Could recompute when going into PROBE state. Issue is how often should we recompute the random number. Current specification says recompute when new RA is received. However, if no RAs are present, computing the value once at boot time and then never again results in some machines having a short (15 second) ReachableTime, while other machines use long (45 second) time. Recomputing each time the timer is set (e.g., whenever going into a REACHABLE state) seems excessive. Proposal to change computed random value once a day or if hear new router advertisement. Group thought this was a good idea and adopted it. Randomize: New value in Router Advertisement occasionally receive RA / once an hour ---------------- RS with unspecified source Needed to make initial ND startup parallel with AddrConf. Relates to Nordmark/Narten homework assignment. [See additional discussion] ------- Extra NUD Probes for Unsolicited Information Propose to introduce STALE state. First packet in STALE => PROBE. PROBE delays for N seconds until sending NS. Group decided to adopt this proposal. --------- Retransmission Timer = 10 sec. This is the timer used for retransmitting neighbor solicitations when node doesn't have a address or for reachability when no routers are present. Suggestion that the default for each link type should be specified in the IPoverFoo specs. Group decided to Change default timer value to one (1) second. IPoverFoo spec can define link type specific default. Value in router advertisement will override. We can now use this timer for duplicate address detection. ------ Prefix Redirect Proposal for Prefix Redirects. This would allow less redirects for traffic to same destination (and destinations in same prefix). Problem what to do when NUD detects neighbor router is down. Does it invalidate all routes in that prefix? No clear answer to do this. Group will continue discussion on second day of meeting. It was also noted that prefix redirects could be added in a backwards compatible manner (using part of the reserved field in the redirect message to specify the prefix length) should the need be stronger in the future. -------------------------------------------------------------------- Thursday, October 12, 1995 -------------------------------------------------------------------- (continuation of Prefix Redirects discussion) Prefix redirect would result in the addition to the redirect message a length of the prefix which the redirect covers (current redirect is host style redirect). The prefix redirect could be disabled by setting the prefix length to 128. Hosts could either do full longest match routing or still deal with this on a per connection basis (e.g., host route). Discussion if people thought that routers would really implement this. Discussion about how host and routers would deal with receiving variable length prefix redirects. Continued discussion about merits, usage, etc. Not clear if benefits out weigh the complexity of specifying how a host needs to deal with longest match routing. After polling the group there was a consensus to not adding Prefix Redirects to ND. ---------- MTU Advertisements Proposal for hosts to be able to advertise individual MTU values. Would allow a host to have a specific MTU for it. After discussion which pointed out the per-host MTU (or MRU) do not work with multicast the group decided not to do per-host MTU advertisements. ------------- Benefits of "Don't Forward" Option (homework from previous day) o Remove ICMP Sender address field from NS. Results in simplified processing. o Remove "no NUD for ND Packets" o NS and NA use global source and destination addresses. o Allow link-layer address option on all packets (except unspecified source) o Remove validation checks on source and destination o Remove "no source router header" validation check Note: Host<-->Router control messages (RA, redirects, etc.) will still use link local addresses. This still permits hosts to maintain their router associations in the event of renumbering. document authors recommend that this change be made. Bob Gilligan made proposal that instead of Hoplimit=0 or "don't forward option", could use HopLimit=255 (max value). Host would only accept packet if HopLimit=255 when received (e.g., it had not been forwarded). No special processing required in routers. This would be used for all ND messages. No "don't forward option" and no HopLimit=0. Group agreed to adopt these changes. ------------ Discussion about how negative advice from TCP could be use to trigger ND. This would only be useful for on link destinations. Additional discussion about how to use positive information from TCP. When receiving an ACK which advances TCP window, this can be used to provide positive notification that there is positive confirmation of reachability. This can be used to update ND's state and keep NUD messages from being sent. No change to the ND specification, but this is good advice to Implementors. --------- Implementations language discussion will be taken off line with document authors. -------- Preferences There are currently no preferences in IPv6 router advertisements. There are preferences in IPv4. There has been a request on the mailing list that IPv6 also have preferences. Desire for a subset of routers on a link to be given "default" status and others to not become default routers. Discussion of pseudorouters (e.g., routers with less than full functionality) and that these type of routers might work better if there were router preferences. Not clear if the IPng specifications should have to specify what minimum functionality that a node needs to implement. There are too many different cases of nodes which do not do the full functionality to try to define what all of the interactions and combinations are. Do the IPv4 semantics satisfy the request or do they need to be more sophisticated? --- Thomas Narten presentation on this topic. Current ND draft assume routers are "smart" and send redirects o In IPv4 reality doesn't match this ideal fix in IPV6? o Routers send redirects based on their own view of the topology rather than originating hosts view. +--+ +---+ +---+ | |---R2--| | | | H2--| | | |--R1--| |----H1 | |---R2--| | | | +--+ +---+ +---+ R3 is "good" router R2 is "bad" router Ideally o R2 forwarding table needs to keep more information; routing operation must be keyed on (arriving interface, destination) rather than just destination. o Router must build separate routing tables for each arriving interface / more computation Does R2 have sufficient knowledge to put itself in "H2's shoes"? o Manually entered routers require additional arguments / flags. o If RIP is in use: - if neighbor router adjust metrics so R2 + R3 are equivalent from H2's perspective. - if R2 adds 1 to each interface metric, R3 becomes better from H2's perspective. ----- Router advertisements w/ preferences does not eliminate requirement for "interface-specific redirect sending" R1-----XXXXXXXX-----H1 / | / | H2 -- XXXXXX R3 \ | \ | R2----XXXXXXXXX------H3 o R1 + R2 have equivalent preferences o H2 using R2 as current default o H2 sends data to H1 o From R2's perspective H1 is one hop away via either R1 or R3 so it chooses R3 o From H2's perspective, R1 is clearly better o R2 should send different redirect to H2 + H2 (e.g., arriving interface specific) -------- What is the big deal about preferences o Inherent conflict between preferences for "default router" vs. router to individual destination. o Which router is best for destination x or default changes dynamically o Routers have this information first, issue is how to best to communicate that information to hosts o Possibilities: + Host wait for routers to tell them everything - Redirect architecture achieves this - Least complex host implementation, - NUD handles black holes + Hosts using defaults routes can easily switch to new default. - Implementation can only use a single router & and does not load balance among equal preference routers o Still need mechanism to probe highest preference router, if it fails. Note: Latter case requires redirects to be timed out. This results in more redirects when nothing is changing. ---- Steve Deering showed a slide showing that preferences do not always result in fewer packets. Sometimes preference result in more redirect packets, sometimes not. H2 H3 | | #####N2#### ###N3####### | \ / | | \ / | | \ / | | R1 | R2 | R3 | | | | | | ########N1######################## | H1 For traffic from H1 to H3 where R1 is best router for destinations on N2 and N3 With no router preferences: If R1 goes down, 50% of the time H1 will pick R3 as default resulting in no redirect when it initiates a connection to H3. The other 50% of the time a redirect will result. With router preferences of R1 being the highest, R2 next highest, and R3 the lowest: If R1 goes down, H1 will always pick R2 as default. This will result in a redirect being sent every time H1 initiates a connection to H3. It is not possible to set up the router preferences in manner which results in less redirect traffic. ---- Narten: Routers learned via redirects become stale o Easiest is simply timeout redirects every N seconds o # of redirects increase o Does not eliminate the need for routers to do route calculations based on source. o Preference potentially reduces the need for above but does not eliminate the need completely. Long discussion about merits and issues regarding adding router preferences. ------ Chair polled room on desire for router preferences: Y= want them, N= do not think should be added N N N N N N N N N N N (there were four non-votes) Deering proposes we do not add preferences, do working group last call, if intensity of debate high is enough from the last call, we will not forward to IESG and continue discussion at the Dallas IETF meeting in December. The group accepted Deering's proposal. ---- Discussion about the need for preferences in anycast address NA's. Anycast addresses were intended to denote "a router" rather than "the best router". In particular, the routing subsystem delivers a packet to "to a router" rather than "the best router". Thus associating preferences with anycast addresses was not really appropriate. After discussing the issues, group decided to not add any preferences for anycast addresses in NA. ------ Erik Nordmark presented analysis on Boot Timing with current ND default timer values. Host: DAD: Random [0-1] second delay Send 1 NS, wait for 1 second RS: Random [0-1] second delay Send up to 3 RS separated by 3 seconds Router: Receive RS Start random timer [0-6] seconds Timer: if received more than one RS while waiting Send RA multicast, else unicast RA. It should be possible to send DAD and RS at the same time, to eliminate the second random [0-1] delay. After much discussion group decided to change so Router will respond with multicast RA (wait random [0-.5 second) and not send another RA for 3 seconds (independent of number of RS received in interval). Routers will always multicast the RA in response to an RS. This should result in faster response to RS and fewer RA on link. Router procedure becomes: Receive RS If have not sent RA within 3 seconds Start Random timer [0-.5] seconds Send RA multicast else wait until (3 seconds + Random [0 - .5)) timer expires Send RA multicast endif ---------- Document Organization Desire to restructure document to move packet formats to beginning of document (after overview), use standard internet bit order, make implementation details generic if appropriate, and other similar formatting changes. Add statement that the protocol is the packet formats and external behavior on the wire and the implementation guidelines are a conceptual model. The protocol is what is being standardized. Implementations are not required to implement guidelines exactly as described. ------ Group agreed that once these changes are made we can do a working group last call. Authors will have a new draft within 3 weeks. ---------------------------------------------------------------------- Minimum Reassemble Size ---------------------------------------------------------------------- RFC of IPv6 will say that minimum reassembly size is 1500 bytes. ---------------------------------------------------------------------- "IGMP" for Link-Local Multicast Groups ---------------------------------------------------------------------- Do membership reports need to be done for link-local multicast groups? It is not clear if required link-local multicast addresses need to be added to IGMP group requests. Could only use for groups which are created by the hosts and not for the required multicast group addresses. Having them in the group would make it easier to prune traffic to groups which do not have any members. Group decided to not include pre-defined link-local multicast addresses in IGMP group messages but will send IGMP reports for other link-local multicast addresses. ---------------------------------------------------------------------- Thanks to Scott Behnke / Dyncorp and Allison Mankin / ISI for hosting the meeting. Meeting adjoined! ---------------------------------------------------------------------- ------------------------------------------------------------------------------ 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 Oct 18 15:59:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21108; Wed, 18 Oct 95 15:59:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21102; Wed, 18 Oct 95 15:59:15 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04163; Wed, 18 Oct 1995 15:46:38 -0700 Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id PAA05025; Wed, 18 Oct 1995 15:46:28 -0700 Received: from muggsy.lkg.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA19998; Wed, 18 Oct 1995 15:35:14 -0700 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA19545; Wed, 18 Oct 1995 18:35:12 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id SAA12692; Wed, 18 Oct 1995 18:36:30 GMT Message-Id: <199510181836.SAA12692@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: Stephen Thomas Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 764) Re: IPv6 Multicast / Priority In-Reply-To: Your message of "Tue, 17 Oct 1995 18:09:25 -0400." <199510172213.SAA15555@dylan.mindspring.com> X-Mailer: exmh version 1.5omega 10/6/94 Date: Wed, 18 Oct 1995 18:36:29 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In <199510172213.SAA15555@dylan.mindspring.com>, Stephen Thomas wrote: > Many of you are probably aware of the problems facing any type > of multicast services that want to run over Token Ring. Because > of the design of most (all?) token ring chipsets, link layer > multicast addresses are exceedingly scarce. For all practical > purposes, IPv6 has only a single multicast address at its disposal. > The current IPv6-over-Token-Ring draft specifies that *all* > IPv6 multicasts must use this single link address. As defined, IPv6 only has one functional address assigned to it. That doesn't mean it couldn't be defined to use more. I think that splitting the IPv6 multicast traffic over more than one functional address is definitely desirable. > [...deleted...] > A) Priority. No. DHCP traffic comes immediately to mind. >B) The T-bit in the destination multicast address. That would be acceptable to me. Another method come to mind: assign all link-local multicasts to one functional address and all other multicasts to a different functional address. But I have no strong feelings compared to your B proposal. As for the functional addresses to be used, the use of any broadcast (even on Token Ring) should be avoided. We could use the functional addresses (03-00-00-00-02-00 and 03-00-00-00-01-00) assigned for ESIS. :-) Or just choose another of the unassigned functional address (say 03-00-04-00-00-00) for the second functional address. Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ 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 Oct 20 10:32:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22237; Fri, 20 Oct 95 10:32:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22231; Fri, 20 Oct 95 10:32:25 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18591; Fri, 20 Oct 1995 10:19:06 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id KAA09407; Fri, 20 Oct 1995 10:17:57 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id KAA24498; Fri, 20 Oct 1995 10:17:02 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Oct 1995 10:20:38 -0700 To: sob@harvard.edu, mankin@isi.edu From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 765) Request for Advancement of IPng Addressing Documents Cc: hinden@Ipsilon.COM, deering@parc.xerox.com, ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Dear Allison and Scott, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a RFC with Proposed Standard status: An IPv6 Provider-Based Unicast Address Format Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, and J. Postel draft-ietf-ipngwg-unicast-addr-fmt-02.txt The only comments received on the working group last call (which ended on September 29, 1995) pertained to whether the document should go forward as a PS, informational, or BCP RFC. At the IPng working group meeting held on October 11 & 12, 1995, the working group decided to move this forward as a Proposed Standard. We also request that the following document be published as a RFC, with experimental status: IPv6 Testing Address Allocation R. Hinden and J. Postel draft-ietf-ipngwg-test-addr-alloc-00.txt No comments on this document were received during the Working Group Last Call which ended on September 29, 1995. Bob Hinden Steve Deering ------------------------------------------------------------------------------ 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 Oct 20 18:59:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22531; Fri, 20 Oct 95 18:59:19 PDT Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22525; Fri, 20 Oct 95 18:59:10 PDT Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id SAA01368; Fri, 20 Oct 1995 18:46:37 -0700 Received: by kandinsky.Eng.Sun.COM (5.x/SMI-SVR4) id AA18221; Fri, 20 Oct 1995 18:50:49 -0700 Date: Fri, 20 Oct 1995 18:50:49 -0700 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9510210150.AA18221@kandinsky.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng 766) Solaris 2 IPv6 prototype now available Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk We are pleased to announce the availability for experimentation of our IPv6 prototype for Solaris 2.5 on sparc machines. The code is in the form of a tar file which you can extract and install on your Solaris 2.5 machine. You can pick up the code via IPv6 anonymous FTP from the IPv6 host: ::192.9.5.6 The code is in the file: pub/solaris2-ipv6/ipng_rel2.tar Those of you still using that old protocol, IPv4, can pick the tar file up from the same location on "playground.sun.com". - Bob, and the Solaris 2 IPv6 team ------------------------------------------------------------------------------ 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 Oct 21 04:32:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22739; Sat, 21 Oct 95 04:32:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22733; Sat, 21 Oct 95 04:32:32 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19802; Sat, 21 Oct 1995 04:18:51 -0700 Received: from singapura.singnet.com.sg by mercury.Sun.COM (Sun.COM) id EAA20281; Sat, 21 Oct 1995 04:18:44 -0700 Received: (from mathias@localhost) by singapura.singnet.com.sg (8.6.12/8.6.9) id TAA03068; Sat, 21 Oct 1995 19:18:42 +0800 Date: Sat, 21 Oct 1995 19:18:42 +0800 (SST) From: Mathias Koerber To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 767) Record ROute in IPv6? Message-Id: Organization: SingNet X-Disclaimer: I don't speak for noone except myself Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi, I have just joined this mailing list. # After a look thru the draft proposals/proposed standards, I was unable to find any specific pertaining to IPv6 handling of record routes. The reason IPv4 required a special traceroute program to discover routes used was that although a record route option exists, the remote side is not mandated to (and in fact almost never does) turn on the same option on the reply packet, thus requiring something to listen and report the recorded routes back via another connection (A scheme which I believe was never implemented), or a nice hack like traceroute to use the TTL error reporting to find the routes used. The problem with this approach is that is unnecessarily loads the network when a single packet could do the trick. I would like to know whether something was decided on in IPv6 to make route discovery easier. If not: I could foresee several approaches: a) mandate that ICMP echo request packets received with the record route option turned on be answered with ICMP echo responses with the same option on. b) define a special mandatory protocol to record routes. an ICMP packet could collect the data using the record route option turned on, and the receiving system would return the data to a daemon via either UDP or TCP.. It might even be beneficial to have a host automatically turn a record route option on on every xth (for large x, random value deduced at reboot) packet sent out (regardless of destination or protocol). The protocol stack on the receiving system would hand that data to a dedicated daemon (optionally) enabled on the receiving host, thus collecting a (moderately good though not complete) picture of routing info on the fly.... If the daemon is not running the info would be dropped. Generating routing info (by turning on the option bit) every x packets and honoring the option by inserting the local address would be mandatory, accepting and analysing the data optional... Potential problems I can think of: a) traceroute has the added advantage of reporting partial routes to hosts which are "down". A specific protocol might not be able to overcome this. Nonetheless, I think a traceroute-like approach should be a fallback.. Even a "half" traceroute like approach would be better: One packet travels all the way to the target, and triggers a response packet at every node it passes. b) Not enough space to record all routes in the packet. A separate protocol speaks for this, as it could make use of additional packets. c) different types of service can result in different routes, requiring the protocol and analyzing software to be aware of thus. d) Security problems.. All these are obviously open to spoofing attacks, sigh....A dedicated problem might be able to overcome this at the expense of transparency, ease of use and bandwidth use :-( Could someone point me to the revious discussion in this area and tell me whether a solution has been found? Or are we going to stick with traceroute in IPv6? regards Mathias Koerber mathias@singnet.com.sg SingNet NOC Mathias_Koerber@POBOX.ORG.SG Singapore Telecoms * Eifersucht ist eine Leidenschaft, die mit Eifer sucht was Leiden schafft * ------------------------------------------------------------------------------ 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 Oct 23 05:10:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23167; Mon, 23 Oct 95 05:10:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23161; Mon, 23 Oct 95 05:10:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03358; Mon, 23 Oct 1995 04:57:29 -0700 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id EAA15089; Mon, 23 Oct 1995 04:57:31 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08230; 23 Oct 95 7:55 EDT To: IETF-Announce:;@mercury Cc: ipng@sunroof.Eng.Sun.COM From: IESG Secretary Subject: (IPng 768) Last Call: IPv6 Testing Address Allocation to Experimental Reply-To: iesg@IETF.CNRI.Reston.VA.US Date: Mon, 23 Oct 95 07:55:28 -0400 Message-Id: <9510230755.aa08230@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The IESG has received a request from the IPNG Working Group to consider "IPv6 Testing Address Allocation" for the status of Experimental. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by November 6, 1995. ------------------------------------------------------------------------------ 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 Oct 23 05:30:01 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23191; Mon, 23 Oct 95 05:30:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23183; Mon, 23 Oct 95 05:29:46 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03998; Mon, 23 Oct 1995 05:17:07 -0700 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id FAA16797; Mon, 23 Oct 1995 05:17:10 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08596; 23 Oct 95 8:13 EDT To: IETF-Announce:;@mercury Cc: ipng@sunroof.Eng.Sun.COM From: IESG Secretary Subject: (IPng 769) Last Call: An IPv6 Provider-Based Unicast Address Format to Proposed Standard Reply-To: iesg@IETF.CNRI.Reston.VA.US Date: Mon, 23 Oct 95 08:13:12 -0400 Message-Id: <9510230813.aa08596@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The IESG has received a request from the IPNG Working Group to consider "An IPv6 Provider-Based Unicast Address Format" for the status of Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by November 6, 1995. ------------------------------------------------------------------------------ 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 Oct 23 09:50:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23367; Mon, 23 Oct 95 09:50:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22891; Sat, 21 Oct 95 14:45:19 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05542; Sat, 21 Oct 1995 14:32:45 -0700 Received: from sophia.inria.fr by mercury.Sun.COM (Sun.COM) id OAA24080; Sat, 21 Oct 1995 14:32:44 -0700 Received: from [138.96.36.34] by sophia.inria.fr (8.6.12/8.6.12) with SMTP id WAA04295 for ; Sat, 21 Oct 1995 22:32:32 +0100 Date: Sat, 21 Oct 1995 22:32:32 +0100 X-Authentication-Warning: sophia.inria.fr: Host huitema.inria.fr claimed to be [138.96.36.34] Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.Eng.Sun.COM From: huitema@pax.inria.fr (Christian Huitema) Subject: (IPng 770) E8::0 or FE80::0 ? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk There is an inconsistency between the address architecture document (), which reserve for local addresses the 10 bit prefix 1111 1110 10 (FE80::/10) and the address autoconfiguration draft (addrconf-ipv6-auto-04.txt) which states at the end of page 10 that "A link-local address is formed by prepending the well-known link-local prefix E8::0 [ADDR-ARCH] (of appropriate length) to the interface token." Which document should we trust ? Am I correct in assuming that the version 05 of addrconf will correct its text to "the well-known link-local prefix FE80::0" ? Besides, the minutes of the addrconf are slightly ambiguous. They say both that "the authors recommend these changes" (which by context refers to adoption of the don't forward option + several details in message formats) and then that Bob Gilligan's clever hack of TTL=255 is adopted. I understand the 255 hack, but did you also changes the ICMP formats, or did you leave them alone ? Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 23 10:25:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23450; Mon, 23 Oct 95 10:25:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23444; Mon, 23 Oct 95 10:25:16 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02632; Mon, 23 Oct 1995 10:12:36 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id KAA15835; Mon, 23 Oct 1995 10:12:32 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5550; Mon, 23 Oct 95 13:12:31 EDT Received: by RTP (XAGENTA 4.0) id 1205; Mon, 23 Oct 1995 13:11:00 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA18000; Mon, 23 Oct 1995 13:09:49 -0400 Message-Id: <9510231709.AA18000@cichlid.raleigh.ibm.com> To: huitema@pax.inria.fr (Christian Huitema) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 771) Re: E8::0 or FE80::0 ? In-Reply-To: Your message of "Sat, 21 Oct 1995 22:32:32 BST." Date: Mon, 23 Oct 1995 13:09:46 -0300 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >There is an inconsistency between the address architecture document (), >which reserve for local addresses the 10 bit prefix 1111 1110 10 >(FE80::/10) and the address autoconfiguration draft >(addrconf-ipv6-auto-04.txt) which states at the end of page 10 that "A >link-local address is formed by prepending the well-known link-local prefix >E8::0 [ADDR-ARCH] (of appropriate length) to the interface token." Addrconf got it wrong. It will be fixed in the next draft. >Besides, the minutes of the addrconf are slightly ambiguous. They say both >that "the authors recommend these changes" (which by context refers to >adoption of the don't forward option + several details in message formats) >and then that Bob Gilligan's clever hack of TTL=255 is adopted. I >understand the 255 hack, but did you also changes the ICMP formats, or did >you leave them alone ? The formats also got changed. The reason Erik & I wanted the equivalent of a "don't forward" option was to more cleanly separate processing rules needed to make ND work from rules whose sole purpose was to insure that ND packets from off-link destinations were ignored (and the secondary effects of adding those rules). The TTL=255 trick allows us to do away with all requirements that NS/NA packets use link-local source/destination addresses, allowing us to get rid of the Sender Address field (the IPv6 Source Address field serves this purpose). A number of other validation tests and special rules will no longer be needed with the change. Thomas ------------------------------------------------------------------------------ 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 Oct 23 11:37:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23617; Mon, 23 Oct 95 11:37:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23611; Mon, 23 Oct 95 11:37:43 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14585; Mon, 23 Oct 1995 11:25:04 -0700 Received: from catarina.usc.edu by mercury.Sun.COM (Sun.COM) id LAA14031; Mon, 23 Oct 1995 11:25:04 -0700 Received: from tampico.usc.edu (tampico.usc.edu [128.125.52.5]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id LAA04966; Mon, 23 Oct 1995 11:25:00 -0700 Message-Id: <199510231825.LAA04966@catarina.usc.edu> X-Authentication-Warning: catarina.usc.edu: Host tampico.usc.edu didn't use HELO protocol X-Mailer: exmh version 1.6 4/21/95 To: "Robert M. Hinden" Cc: ipng@sunroof.Eng.Sun.COM, addrconf@cisco.com, hinden@ipsilon.com, minutes@cnri.reston.va.us, micke@catarina.usc.edu Subject: (IPng 772) Re: "IGMP" for Link-Local Multicast Groups In-Reply-To: Your message of "Wed, 18 Oct 1995 12:12:12 PDT." <199510181912.MAA25808@walnut.ipsilon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Oct 1995 11:24:55 -0700 From: Mikael Degermark Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Is IGMP really of any use for Link-Local multicast groups? My understanding of "IGMP" is that it is used by routers to learn if there are multicast receivers on the local link. The router can then avoid forwarding packets onto the link if there are no receivers. In the notes from the IPng/AddrConf Interim Meeting: >Do membership reports need to be done for link-local multicast groups? > >It is not clear if required link-local multicast addresses need to be >added to IGMP group requests. Could only use for groups which are >created by the hosts and not for the required multicast group >addresses. Having them in the group would make it easier to prune >traffic to groups which do not have any members. > >Group decided to not include pre-defined link-local multicast >addresses in IGMP group messages but will send IGMP reports for other >link-local multicast addresses. This suggests that "IGMP" can be used by a sending local host to learn if there are members in a link-local multicast group. This would presumably allow that host to prune its traffic. I'd be happy to learn that this was the case but my current understanding of "IGMP" tells me this is not true. With "IGMP" only routers and group members will learn whether there are members on the link, so a host that sends to a local multicast group but is not a member will not learn that there no members. If the sender joins the group, it won't learn either as in that case there is at least one member. In neither case can the traffic be pruned. Could someone who understands this issue please explain? Mikael Degermark ------------------------------------------------------------------------------ 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 Oct 23 15:57:54 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24120; Mon, 23 Oct 95 15:57:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24114; Mon, 23 Oct 95 15:57:45 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24843; Mon, 23 Oct 1995 15:45:05 -0700 Received: from iol.unh.edu by mercury.Sun.COM (Sun.COM) id PAA21385; Mon, 23 Oct 1995 15:45:06 -0700 Received: by iol.unh.edu (4.1/SMI-4.1) id AA20780; Mon, 23 Oct 95 18:42:21 EDT From: qv@iol.unh.edu (Quaizar Vohra) Message-Id: <9510232242.AA20780@iol.unh.edu> Subject: (IPng 773) Re: Second revision of Solaris 2 IPv6 code now available To: sun-ipv6-users@sunroof.Eng.Sun.COM Date: Mon, 23 Oct 1995 18:42:20 -0400 (EDT) Cc: ipng@sunroof.Eng.Sun.COM (ipng) In-Reply-To: <9510230301.AA19142@kandinsky.Eng.Sun.COM> from "Bob Gilligan" at Oct 22, 95 08:01:52 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi, I was trying to interoperate between Sun's IPv6 prototype and HP. I was trying to ping (v6) HP from Sun. The HP never replies. The problem seems to be with the checksum computation of Sun's prototype. I even tried it with DEC's test node sipper and there was no reply from sipper. So I checked the octal dump of the IPv6-ICMPv6 packet ( over IP tunnel ). The checksum computes has a value 1 more than what it should be in all the cases. Also the checksum verification has the same problem and discards all the packets from other IPv6 prototypes ( even though they are correct ). for example, on pinging sipper ( ::204.123.39.2 from ::132.177.120.95) Snoop detects the following packet : IPv6 header : 6000 0000 0040 3aff 0000 0000 0000 0000 0000 0000 84b1 785f ( ::132.177.120.95 ) 0000 0000 0000 0000 0000 0000 cc7b 2702 ( ::204.123.39.2 ) Pseudo-header ( for chexksum computation ) ; 0000 0000 0000 0000 0000 0000 84b1 785f ( ::132.177.120.95 ) 0000 0000 0000 0000 0000 0000 cc7b 2702 ( ::204.123.39.2 ) 003a 0040 ( next-header = 3a (58 for ICMPv6), payload = 64 bytes ) ICMPv6 echo-request packet : 8000 5880 02c6 0000 308c 12c0 0009 0809 ( checksum 5880 ) 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 The checksum shoould be 587f instead of 5880 Also, I have a few questions about the prototype : 1. Do you implement listening to Neighbor Sol. and replying with Neighbor Ads. 2. Have you implemented Neighbor Unreachabiltiy detection. 3. Do you join the solicited multicast addresses ( based on the IPv6 address of the interface ) on the IPv6 configured interfaces. ------------------------------------------------------ Quaizar Vohra Inter-Operatibility Lab. (IOL), Univ. of New Hampshire E-mail : qv@sun4.iol.unh.edu Phone : (603)-862-4488 ------------------------------------------------------------------------------ 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 Oct 27 08:22:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26346; Fri, 27 Oct 95 08:22:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26340; Fri, 27 Oct 95 08:22:13 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06513; Fri, 27 Oct 1995 08:09:30 -0700 Received: from fennel.acc.com by mercury.Sun.COM (Sun.COM) id IAA14867; Fri, 27 Oct 1995 08:09:29 -0700 Received: from ambrosia.acc.com by fennel.acc.com (4.1/SMI-4.1) id AA18242; Fri, 27 Oct 95 08:09:39 PDT Received: by ambrosia.acc.com (4.1/SMI-4.1) id AA03947; Fri, 27 Oct 95 08:08:54 PDT Date: Fri, 27 Oct 1995 08:08:50 -0700 (PDT) From: Mehul Mehta To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 774) Timeframe for IPng implementation Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hello, I was curious to know what was the expected timeline on which the IPng implementation and the transition process is going to evolve. I need this information as part of my research for preparing for a presentation on IPng Deployment plans. Thanks Mehul <<<------------------------ Mehul Mehta Tel No: 805-968-7805 (R) 805-961-0226 (O) email: mehta@acc.com ------------------------>>> ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 27 14:48:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00192; Fri, 27 Oct 95 14:48:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00186; Fri, 27 Oct 95 14:48:23 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12548; Fri, 27 Oct 1995 13:02:02 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id NAA01833; Fri, 27 Oct 1995 13:01:55 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4005; Fri, 27 Oct 95 16:01:51 EDT Received: by RTP (XAGENTA 4.0) id 2143; Fri, 27 Oct 1995 16:02:42 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA16749; Fri, 27 Oct 1995 16:01:40 -0400 Message-Id: <9510272001.AA16749@cichlid.raleigh.ibm.com> To: Matt Crawford Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 775) Re: DAD and loopback of multicast packets In-Reply-To: Your message of "Thu, 26 Oct 1995 13:44:40 CDT." <9510261844.AA18162@munin.fnal.gov> Date: Fri, 27 Oct 1995 16:01:39 -0300 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Matt, >Two nodes are booting at the same time, and each sends a query for >purposes of Duplicate Address Detection. The two packets are >identical in content. If either node cannot tell the difference >between its own packet and the packet from the other node, DAD won't >work. You're right that this is a logical third case. But things are even more subtle (I'm working on revising the text). If only one (rather than both) of the two nodes discards received packets with the same link-layer source as the receiving interface, we're OK. The node with the "correct" implementation will see the other node's NS, and DAD works for it. The other node won't detect this situation, but the end result will be that only one node ends up using the address, so it is unique. This is technically OK I think. It depends on the precise definition of what DAD means when two nodes run DAD simultaneously. Is the goal to prevent more than one node from using an address? Or is it to prevent all nodes from using an address, if multiple nodes assert a desire to use it simultaneously? The current draft goes with the first definition. There is another similar case. Namely, if two nodes run DAD at the same time, but each randomly delays by a different amount before sending an NS, one node will receive an NS for the tentative address before having sent one itself. It immediately concludes that the tentative address is not unique, without ever sending out any DAD-related packets. The other node subsequently concludes that the address is unique and uses it. Thomas ------------------------------------------------------------------------------ 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 Oct 30 10:13:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00996; Mon, 30 Oct 95 10:13:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00989; Mon, 30 Oct 95 10:13:13 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27978; Mon, 30 Oct 1995 10:00:24 -0800 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id KAA26135; Mon, 30 Oct 1995 10:00:23 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09905; 30 Oct 95 9:21 EST To: IETF-Announce:;@mercury Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.Eng.Sun.COM From: The IESG Subject: (IPng 776) Document Action: OSI NSAPs and IPv6 to Experimental Date: Mon, 30 Oct 95 09:21:25 -0500 Message-Id: <9510300921.aa09905@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The IESG has reviewed the Internet-Draft "OSI NSAPs and IPv6" and recommends that it be published by the RFC Editor as an Experimental RFC. This document is the product of the IPNG Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. ------------------------------------------------------------------------------ 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 Oct 30 11:44:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01132; Mon, 30 Oct 95 11:44:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01124; Mon, 30 Oct 95 11:44:39 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14521; Mon, 30 Oct 1995 11:31:49 -0800 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id LAA29722; Mon, 30 Oct 1995 11:31:51 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HX1X3S8S0W000JVB@FNAL.FNAL.GOV>; Mon, 30 Oct 1995 13:31:29 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA04924; Mon, 30 Oct 95 13:30:04 CST Date: Mon, 30 Oct 1995 13:30:03 -0600 From: Matt Crawford Subject: (IPng 777) Re: DAD and loopback of multicast packets To: Thomas Narten Cc: ipng@sunroof.Eng.Sun.COM Message-Id: <9510301930.AA04924@munin.fnal.gov> Content-Transfer-Encoding: 7BIT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Matt C: > >Two nodes are booting at the same time, and each sends a query for > >purposes of Duplicate Address Detection. ... Thomas N: > If only one of the two nodes discards received packets with the same > link-layer source as the receiving interface, we're OK. Yes, but, if they're having an address collision on an 802-like medium, they are probably from the same vendor and will act the same. > The current draft goes with the first definition. There is another > similar case. Namely, if two nodes run DAD at the same time, but each > randomly delays by a different amount before sending an NS, ... Will you suggest a method for choosing the random delay? A method, I hope, which doesn't depend on the built-in MAC address, ID PROM or time of day? And if DAD takes 1 second, the range of this random timer will have to be some significant multiple of a second. Is everyone comfortable with a 1 to 10 delay in booting? Matt ------------------------------------------------------------------------------ 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 Oct 30 13:39:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01313; Mon, 30 Oct 95 13:39:30 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01307; Mon, 30 Oct 95 13:39:21 PST Received: from janice.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id NAA02472; Mon, 30 Oct 1995 13:26:32 -0800 Received: by janice.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id NAA00402; Mon, 30 Oct 1995 13:24:57 -0800 Date: Mon, 30 Oct 1995 13:24:57 -0800 From: therbert@jurassic (Tom Herbert) Message-Id: <199510302124.NAA00402@janice.Eng.Sun.COM> To: crawdad@FNAL.FNAL.GOV Subject: (IPng 778) Re: DAD and loopback of multicast packets Cc: ipng@sunroof.Eng.Sun.COM X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > Matt C: > > >Two nodes are booting at the same time, and each sends a query for > > >purposes of Duplicate Address Detection. ... > Thomas N: > > If only one of the two nodes discards received packets with the same > > link-layer source as the receiving interface, we're OK. > > Yes, but, if they're having an address collision on an 802-like > medium, they are probably from the same vendor and will act the same. > > > The current draft goes with the first definition. There is another > > similar case. Namely, if two nodes run DAD at the same time, but each > > randomly delays by a different amount before sending an NS, ... > > Will you suggest a method for choosing the random delay? A method, I > hope, which doesn't depend on the built-in MAC address, ID PROM or > time of day? > > And if DAD takes 1 second, the range of this random timer will have > to be some significant multiple of a second. Is everyone comfortable > with a 1 to 10 delay in booting? > Up to a ten second delay added to do DAD? I think that is far too expensive for an operation which checks for the rare case when two nodes performing DAD at the exact same time for identical addresses. I think the "signature token" on the NS is less costly. Not only could it be used to detect looped back NS's, but could also be used as a tiebreaker in the case of two nodes simultaneously perfoming DAD for the same address-- whichever node is sending NS's with the smaller token "wins" the address. Tom ------------------------------------------------------------------------------ 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 Oct 31 12:17:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01958; Tue, 31 Oct 95 12:17:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01952; Tue, 31 Oct 95 12:17:30 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06231; Tue, 31 Oct 1995 12:04:40 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id MAA19856; Tue, 31 Oct 1995 12:04:35 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4228; Tue, 31 Oct 95 15:04:27 EST Received: by RTP (XAGENTA 4.0) id 2880; Tue, 31 Oct 1995 15:04:21 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA19032; Tue, 31 Oct 1995 15:04:15 -0500 Message-Id: <9510312004.AA19032@cichlid.raleigh.ibm.com> To: Matt Crawford Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 779) random delay seed In-Reply-To: Your message of "Mon, 30 Oct 1995 13:30:03 CST." <9510301930.AA04924@munin.fnal.gov> Date: Tue, 31 Oct 1995 15:04:14 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Matt Crawford writes: >Will you suggest a method for choosing the random delay? A method, I >hope, which doesn't depend on the built-in MAC address, ID PROM or >time of day? Here is proposed text as it appears in ND (I just added the random delay seed text). I note that it doesn't mention random values taken from external sources like clocks. Suggestions welcome. > random delay - when sending out messages, it is sometimes necessary > to delay a transmission for a random amount of time in order to > prevent multiple nodes from transmitting at exactly the same time, > or to prevent periodic transmissions from synchronizing with each > other [SYNC]. When a random component is required, a node > calculates the actual delay in such a way that the computed delay > forms a uniformly-distributed random value that falls between the > specified minimum and maximum delay times. The implementor must also > take care to insure that the granualarity of the calculated random > component and the resolution of the timer used are both high enough > to insure that the probability of multiple nodes delaying the same > amount of time is small. > > random delay seed - If a psuedo-random number generator is used in > calculating a random delay component, the generator should be > initialized with a unique seed prior to being used. Note that it is > not sufficient to use the interface token alone as the seed, since > interface tokens will not always be unique. To reduce the > probability that duplicate interface tokens cause the same seed to > be used, the seed should be calculated from a variety of input > sources (e.g,. machine components) that are likely to be different > even on identical "boxes". At a minimum, for example, the seed > should be formed by combining the CPU's serial number with an > interface token. Thomas ------------------------------------------------------------------------------ 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