From owner-ipng@sunroof.eng.sun.com Fri May 1 08:24:06 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id IAA01532 for ipng-dist; Fri, 1 May 1998 08:18:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id IAA01525 for ; Fri, 1 May 1998 08:18:38 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA29395 for ; Fri, 1 May 1998 08:18:35 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id IAA13517 for ; Fri, 1 May 1998 08:18:32 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id KAA00660; Fri, 1 May 1998 10:15:21 -0500 Message-Id: <199805011515.KAA00660@gungnir.fnal.gov> To: "Theodore Y. Ts'o" Cc: Robert Elz , Thomas Narten , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5750) Re: [Karen Seo: Thomas Narten -- clarification, etc.] In-reply-to: Your message of Thu, 30 Apr 1998 21:54:57 EDT. <199805010154.VAA20482@dcl.MIT.EDU> Date: Fri, 01 May 1998 10:15:20 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There's something sour in the infosoup. I think SOME people are confusing (Extension Headers) with (Hop-by-hop Options and Destination options). IPv6 Extensions headers have a protocol number assigned from the same 8-bit space as IPv4 protocol numbers (although some values will only be seen in an IPv4 packet, and some only in an IPv6 packet). HBH options and destination options are carried in a HBH option extension header or a destination option extension header, respectively. Each option carried has its own 8-bit type code which uses 2 bits to encode the action to be taken when the option is not understood and one bit to declare whether it's to be covered by AH. A receiver "should" reject a packet if it is called upon to process any unknown extension header. An packet with an unknown (HBH or Destination) option, on the other hand, is handled in accordance with the two bit field referred to above. (See page 9 of ..ipv6-spec-v2-01.) Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 1 09:20:39 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id JAA01618 for ipng-dist; Fri, 1 May 1998 09:15:17 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with ESMTP id JAA01611 for ; Fri, 1 May 1998 09:15:11 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with ESMTP id JAA18039 for ; Fri, 1 May 1998 09:15:05 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA21081 for ipng@sunroof.eng.sun.com; Fri, 1 May 1998 09:14:48 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id RAA01048 for ; Thu, 30 Apr 1998 17:09:31 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA08461 for ; Thu, 30 Apr 1998 17:09:28 -0700 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id RAA06169 for ; Thu, 30 Apr 1998 17:09:24 -0700 (PDT) Received: from orsmsx26.INTEL.COM (orsmsx26.jf.intel.com [192.168.74.26]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id RAA21653; Thu, 30 Apr 1998 17:22:57 -0700 (PDT) Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.1960.3) id ; Thu, 30 Apr 1998 17:09:19 -0700 Message-ID: <3D33CF40366DD111AC4100A0C96B22AC015D53AC@FMSMSX34> From: "Patel, Baiju V" To: "'Steve Bellovin'" , "'Theodore Y. Ts'o'" Cc: "'Thomas Narten'" , "'jis@MIT.EDU'" , "'ipsec@tis.com'" , "'ipng@sunroof.eng.sun.com'" Subject: (IPng 5751) RE: [Karen Seo: Thomas Narten -- clarification, etc.] Date: Thu, 30 Apr 1998 17:09:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would agree with Steve's remark that none of these choices are particularly palatable. Here is a solution that exists within IPSEC standards that meets all the requirements and yet, not confusing: Use tunnel mode! Using AH or ESP with tunnel mode will protect IP header (including non-mutable and mutable but predictable headers). I believe that many people have suggested this option on this mailing list earlier and it will work and do the job. Baiju -----Original Message----- From: owner-ipsec@ex.tis.com [mailto:owner-ipsec@ex.tis.com]On Behalf Of Steve Bellovin Sent: Thursday, April 30, 1998 12:27 PM To: Theodore Y. Ts'o Cc: Thomas Narten; jis@MIT.EDU; ipsec@tis.com; ipng@sunroof.eng.sun.com Subject: Re: [Karen Seo: Thomas Narten -- clarification, etc.] None of these choices are particularly palatable. Just so I understand the IPV6 issues a little better --- how likely is it that we will want to invent new extension headers? And how likely is it that the ordering will matter and that the new extension header will have to be before the AH header, and could not be placed after the AH header? Well, Vern Paxson and I are talking about a new header right now -- and it would have to be mutable. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 1 11:36:07 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id LAA01791 for ipng-dist; Fri, 1 May 1998 11:30:11 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id LAA01783 for ; Fri, 1 May 1998 11:29:53 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA12515 for ; Fri, 1 May 1998 11:29:27 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id LAA18740 for ; Fri, 1 May 1998 11:29:10 -0700 (PDT) Received: from death.mentat.com ([192.88.122.121]) by mentat.com (4.1/SMI-4.1) id AA28238; Fri, 1 May 98 11:25:23 PDT Received: by death.mentat.com (SMI-8.6/SMI-SVR4) id LAA02677; Fri, 1 May 1998 11:31:38 -0700 Date: Fri, 1 May 1998 11:31:38 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199805011831.LAA02677@death.mentat.com> To: crawdad@fnal.gov Subject: (IPng 5752) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, > > There's something sour in the infosoup. > > I think SOME people are confusing (Extension Headers) with > (Hop-by-hop Options and Destination options). > > IPv6 Extensions headers have a protocol number assigned from the same > 8-bit space as IPv4 protocol numbers (although some values will only > be seen in an IPv4 packet, and some only in an IPv6 packet). > > HBH options and destination options are carried in a HBH option > extension header or a destination option extension header, > respectively. Each option carried has its own 8-bit type code which > uses 2 bits to encode the action to be taken when the option is not > understood and one bit to declare whether it's to be covered by AH. > > A receiver "should" reject a packet if it is called upon to process > any unknown extension header. > Exactly. The other issue with respect to the definition of new extension headers is that it is the responsibility of the people who define the new extension header to define where the new header should reside in the datagram relative to the AUTH header. If they choose to make it legal for the new extension header to be placed before the AUTH header and the header can be mutated in transit then they must define how that mutability is to be handled by the sender and the receiver during AH processing. > An packet with an unknown (HBH or Destination) option, on the other > hand, is handled in accordance with the two bit field referred to > above. (See page 9 of ..ipv6-spec-v2-01.) > I believe the only outstanding point of confusion here is whether when set, the third highest order bit in the option type value means "mutable in transit" or whether it means "mutable in transit and unpredictable by the sender". In practice I believe that we must settle for the former. It doesn't seem practical to force every implementation of AH, including security gateways, to know about every hop-by-hop or destination option. Indeed, the whole point in having the highest order two bits of the option type value defined as they are defined is specifically because we don't want to force every fielded implementation to be upgraded every time a new option is defined. Once again this is only an issue for hop-by-hop options extension headers or destination options extension headers which are placed before AH. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 1 11:56:08 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id LAA01838 for ipng-dist; Fri, 1 May 1998 11:47:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id LAA01831 for ; Fri, 1 May 1998 11:47:37 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA19863 for ; Fri, 1 May 1998 11:47:34 -0700 Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA27491 for ; Fri, 1 May 1998 07:36:47 -0700 (PDT) Received: from maia.east.isi.edu by east.isi.edu (8.8.5/5.61+local-24) id ; Fri, 1 May 1998 10:34:57 -0400 (EDT) Message-Id: <199805011434.KAA16213@east.isi.edu> To: hinden@iprg.nokia.com, deering@cisco.com, jack@iclweb.com Subject: (IPng 5753) NLPID for IPv6 Cc: ipng@sunroof.eng.sun.com Reply-To: mankin@EAST.ISI.EDU Date: Fri, 01 May 1998 10:38:04 EDT From: Allison Mankin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, There has been an NLPID assignment for IPv6 - 8E. Thank you to Jack Houldsworth. Allison Liaison to SC6 --------- From: jack@iclweb.com (Jack Holdsworth) Subject: Re: Urgent! - Transport ECTP, RTP etc Date: Fri, 1 May 1998 15:13:17 -0700 Message-ID: <19980501141629.AAA3182@DEFAULT> I have just spoken to the SC6/WG7 chair (Alan Chambers) and can confirm that it is safe to go ahead and use Hexadecimal value 8E as the NLPID value for IPv6. This is agreed jointly by ISO/SC6 and ITU-T SG6. He is quite pleased that the IETF are interested in using it! If you need any more info, please let me know. Regards Jack Houldsworth -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 1 12:14:23 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id MAA01883 for ipng-dist; Fri, 1 May 1998 12:07:33 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id MAA01876 for ; Fri, 1 May 1998 12:07:24 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA25240 for ; Fri, 1 May 1998 12:07:20 -0700 Received: from cookson.iclweb.com (cookson.iclnet.co.uk [194.176.194.192]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA19566 for ; Fri, 1 May 1998 07:16:45 -0700 (PDT) Received: from DEFAULT ([194.176.196.227]) by cookson.iclweb.com (Netscape Mail Server v2.0) with ESMTP id AAB3182 for ; Fri, 1 May 1998 15:16:34 +0100 From: jack@iclweb.com (Jack Holdsworth) To: "ipngwg send" Subject: (IPng 5754) Fw: Urgent! - Transport ECTP, RTP etc Date: Fri, 1 May 1998 15:17:26 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <19980501141629.AAB3182@DEFAULT> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ---------- > From: jack > To: mankin@EAST.ISI.EDU > Subject: Re: Urgent! - Transport ECTP, RTP etc > Date: Friday, May 01, 1998 3:13 PM > > I have just spoken to the SC6/WG7 chair (Alan Chambers) and can confirm > that it is safe to go ahead and use Hexadecimal value 8E as the NLPID value > for IPv6. This is agreed jointly by ISO/SC6 and ITU-T SG6. He is quite > pleased that the IETF are interested in using it! > > If you need any more info, please let me know. > > Regards > > Jack Houldsworth > ---------- > > From: Allison Mankin > > To: Jack Holdsworth > > Subject: Re: Urgent! - Transport ECTP, RTP etc > > Date: Thursday, April 30, 1998 6:07 AM > > > > Jack, > > > > I understand much better now and I will compose a clear > > note about RTP profiles for your use, within the coming > > week. > > > > I'd appreciate getting the IPv6 NLPID as soon as possible, > > as it is being sought by the IPng WG chairs. > > > > Allison -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 1 17:23:39 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id RAA02331 for ipng-dist; Fri, 1 May 1998 17:17:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id RAA02324 for ; Fri, 1 May 1998 17:17:15 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA08663 for ; Fri, 1 May 1998 17:17:10 -0700 Received: from gateway.sequent.com (gateway.sequent.com [138.95.18.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id UAA15120 for ; Thu, 30 Apr 1998 20:00:09 -0700 (PDT) Received: from eng4.sequent.com (eng4.sequent.com [138.95.7.64]) by gateway.sequent.com (8.8.5/8.8.5) with ESMTP id TAA19133; Thu, 30 Apr 1998 19:41:07 -0700 (PDT) Received: (from viv@localhost) by eng4.sequent.com (8.8.5/8.8.5) id UAA02514; Thu, 30 Apr 1998 20:00:02 -0700 (PDT) From: Vivek Kashyap Message-Id: <199805010300.UAA02514@eng4.sequent.com> Subject: (IPng 5755) Re: problems with your path MTU discovery scheme To: kml@nas.nasa.gov (Kevin M. Lahey) Date: Thu, 30 Apr 1998 20:00:02 -3100 (PDT) Cc: viv@sequent.com, ipng@sunroof.eng.sun.com In-Reply-To: <199804291722.KAA26376@gecko.nas.nasa.gov> from "Kevin M. Lahey" at Apr 29, 98 10:22:20 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > In message <199804291555.IAA23945@eng4.sequent.com>Vivek Kashyap writes > >> What is a "net" and how can a host (like the one in my office) determine > >> what a the prefix forms a "net" when the "net" is 17 hops away? > > > >By net I mean a network that will be reached using a certain prefix > >length of an address. I'll use prefix length henceforth. The packet > >from the office goes through a 17 hops; any of routers (their outgoing > >links) in the path could determine the Path MTU. > > > > H --- R1 --- R2 --- R3 ...... R15 --- R16 --- H2 > > M1 > > > >Let M1 be the path MTU determining MTU. R2 has a routing entry that > >tells it to route the packets destined for H2 through R3. The address > >of H2 is a /128 address. R2 has an entry for /64 (say). If the length > >/64 is returned to H, it can build a route entry based on : > > > >A:B:C:D:E:F:G:H 'AND' A:B:C:D/64 gives me a route entry of the form > >A:B:C:D in host H. If the host was using the default route (or a more > >general route) then it now has a separate entry for destinations that > >would fall under the prefix A:B:C:D. This route entry will have the > >MTU stored as M1. Any connections using this route entry can now use > >M1 as the path MTU. > > But what if R1 has a route to A:B:C:D::H3 with MTU M2? Your net-wide > MTU table will instruct the host will always use the MTU M1 to get to H3. > What if M1 is the minimum MTU, 1280, and M2 is ~64K? Because > you'll always send packets of size M1, you'll never trigger MTU > discovery for H3! Not never! The situation is it may not trigger the path MTU if what I wrote in the previous mail is followed. I have addressed this situation in the draft with some possible solutions but have a better solution appended. The situation : This problem will occur only if : . At some router R there are two entries of the form (say) A:B:C:D/64 MTU M1 A:B:C:D:E/80 MTU M2 . M2 > M1 . M1 is the MTU that determines the path MTU along the path M0 M1 H --- R1 --- R2 --- R3 ...... R15 --- R16 --- H2 | | M2 --.......................................---H3 In such a situation if the host tries H3 first then it may get the route for H3 based on M2 (if it sent a packet > M2). Then it will certainly discover H2 later and both paths will use the correct path MTU. If H2 is discovered first then too if a probe goes to the path with M2 as the least MTU the path to H3 will be discovered. This can be solved by using any of the following solutions: 1. The router on returning a netmask as in the case above could set a bit that indicates to the host that there is a more specific route through the interface too. In such a case the host always use the first hop MTU when discovering the route for paths through the route. An administratively controlled option could also state whether in this situation host routes should be created or the net routes are fine. For eg. in this case let the host H have installed the route A:B:C:D/64 MTU M1 BIT_more_specific_route_exists Net route option: Any new connection will send packets with the MTU set at M0. This should discover the route to H3 with the correct MTU for example. NOTE: The route A:B:C:D:E/80 would not have the 'more specific route exists' bit set. Host route option: In this case, once the BIT_more_specific_route_exists flag is received the route will be installed as in the case above but also a host route to the destination would be created. Essentially behave (for this route) as the spec is now (RFC1981) ie. create host routes for every connection. This is not a difficult thing to do (at the host or the router). The router can easily at the time the route is installed set a bit in the existing route whenever a more specific route is added. With radix tree implementations the secondary entry is added only a pointer away ;-). 2. Another solution could be the caveat to administrators that the above situation might occur. So watch out. Combination of the two would be the best. I'll be updating the draft with the above solution. What do you think ? Vivek > > Kevin > kml@nas.nasa.gov > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Vivek Kashyap viv@sequent.com 503 578 3422 (o) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 1 17:37:49 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id RAA02363 for ipng-dist; Fri, 1 May 1998 17:29:22 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id RAA02356 for ; Fri, 1 May 1998 17:29:11 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA12004 for ; Fri, 1 May 1998 17:29:08 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.8.8/8.8.8) with SMTP id TAA29733 for ; Thu, 30 Apr 1998 19:18:02 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id CA17541; Fri, 1 May 1998 12:12:53 +1000 (from kre@munnari.OZ.AU) To: "Theodore Y. Ts'o" Cc: Thomas Narten , jis@mit.edu, ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: (IPng 5757) Re: [Karen Seo: Thomas Narten -- clarification, etc.] In-Reply-To: "Theodore Y. Ts'o"'s message of "Thu, 30 Apr 1998 21:54:57 -0400." References: <199805010154.VAA20482@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 May 1998 12:12:44 +1000 Message-Id: <20184.893988764@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 30 Apr 1998 21:54:57 -0400 From: "Theodore Y. Ts'o" Message-ID: <199805010154.VAA20482@dcl.MIT.EDU> | I'm curious --- was it ever the case that the extension header | processing worked the way I described them in the first paragraph? I don't think so, in fact the three fairly obvious cases where the current header is TCP, UDP, or IPv6 itself (tunnelling) all fail to fit, as does the fragment header if I remember correctly (it is of fixed size, so has no header length field). All of those have been around since the beginning. I have seen people assume that it is possible to skip unknown headers, but that has neevr been correct IPv6 behaviour. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 1 17:37:49 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id RAA02354 for ipng-dist; Fri, 1 May 1998 17:28:16 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id RAA02347 for ; Fri, 1 May 1998 17:28:06 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA11729 for ; Fri, 1 May 1998 17:28:04 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id TAA04365 for ; Thu, 30 Apr 1998 19:30:09 -0700 (PDT) Received: from death.mentat.com ([192.88.122.121]) by mentat.com (4.1/SMI-4.1) id AA23370; Thu, 30 Apr 98 19:26:45 PDT Received: by death.mentat.com (SMI-8.6/SMI-SVR4) id TAA02379; Thu, 30 Apr 1998 19:32:58 -0700 Date: Thu, 30 Apr 1998 19:32:58 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199805010232.TAA02379@death.mentat.com> To: tytso@MIT.EDU Subject: (IPng 5756) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Cc: ipsec@tis.com, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ted, > > Given that the ESP header itself does not conform to this rule regarding > extension header structure I don't see how one could require that every > other extension header obey this rule. > Obviously, this is not a real good counter. The ESP header is not really an extension header. It is a "terminal" header similar to TCP, UDP and ICMPv6. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 1 17:37:49 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id RAA02374 for ipng-dist; Fri, 1 May 1998 17:30:32 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id RAA02367 for ; Fri, 1 May 1998 17:30:20 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA12381 for ; Fri, 1 May 1998 17:30:17 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id TAA29003 for ; Thu, 30 Apr 1998 19:15:45 -0700 (PDT) Received: from death.mentat.com ([192.88.122.121]) by mentat.com (4.1/SMI-4.1) id AA23330; Thu, 30 Apr 98 19:12:17 PDT Received: by death.mentat.com (SMI-8.6/SMI-SVR4) id TAA02371; Thu, 30 Apr 1998 19:18:29 -0700 Date: Thu, 30 Apr 1998 19:18:29 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199805010218.TAA02371@death.mentat.com> To: tytso@MIT.EDU Subject: (IPng 5758) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Cc: ipsec@tis.com, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ted, > > If this is the case, this simplifies things significantly. This way, if > there is an unknown extension header before the AH header, the IPSEC > host (or security gateway) will have already rejected the packet and > have sent an ICMP packet back at the sender. So we don't need to have > any words about handling unknown extension headers; they will just be > rejected. Can someone in the IPNG working group confirm my reading of > IPV6 spec? > Your reading is correct. The UNH Interoperability Lab folks have had tests for this case for quite some time. > I'm curious --- was it ever the case that the extension header > processing worked the way I described them in the first paragraph? The > IPV6 expert whom I talked to was pretty definitive that this was the way > things worked; I was pretty surprised, since I thought it was incredibly > ugly and unclean, but I wasn't the IPv6 expert. > Given that the ESP header itself does not conform to this rule regarding extension header structure I don't see how one could require that every other extension header obey this rule. I don't recall it ever being stated or implied that there was a required structure that extension headers had to follow other than they had to have a next header field somewhere and they needed to be a multiple of eight bytes in length to preserve alignment. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 1 17:54:20 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id RAA02445 for ipng-dist; Fri, 1 May 1998 17:46:07 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id RAA02437 for ; Fri, 1 May 1998 17:45:50 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA16836 for ; Fri, 1 May 1998 17:45:48 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by earth.sun.com (8.8.8/8.8.8) with SMTP id SAA21159 for ; Thu, 30 Apr 1998 18:55:08 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA12640; Thu, 30 Apr 98 21:55:02 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id VAA20482; Thu, 30 Apr 1998 21:54:57 -0400 Date: Thu, 30 Apr 1998 21:54:57 -0400 Message-Id: <199805010154.VAA20482@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Robert Elz Cc: Thomas Narten , "Theodore Y. Ts'o" , jis@mit.edu, ipsec@tis.com, ipng@sunroof.eng.sun.com In-Reply-To: Robert Elz's message of Fri, 01 May 1998 07:46:34 +1000, <17976.893972794@munnari.OZ.AU> Subject: (IPng 5759) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 01 May 1998 07:46:34 +1000 From: Robert Elz | Let me back up a little and clarify the point that caught my | attention. draft-ietf-ipsec-auth-header-05.txt says: | | >>> If the IPsec implementation encounters an | >>> extension header that it does not recognize, it MUST zero the whole | >>> header except for the Next Header and Hdr Ext Len fields. To me, that reads like nonsense. If the implementation doesn't recognise the header, what would be the basis upon which it would locate the Next Header or Hdr Ext len fields? Is there some (incorrect) implicit assumption here that all headers for all time will have such fields, and that they'll always be in the same place? I had the exact same reaction, and when I rasied the question, someone who is much more versed in the ways IPv6 told me this was really how extension headers were supposed to work --- and in fact that IPv6 implementations were supposed to ("SHOULD") assume that the Next Header field was in a fixed location, and skip the unknown extension header. Given that extension headers are defined by new IP protocol numbers, this seemed rather (OK, *very*) unclean to me. (Presumably if we were to define a new IP protocol number that wasn't an extension header, the IPV6 protocol would try to process it as an extension header and get a parse error... eventually.) Fortunately, I hadn't eaten recently when this was explained to me, or I probably would have lost my lunch. However, I just checked draft-ietf-ipngwg-ipv6-spec-v2-01.txt, and this doesn't appear to be the case. The IPV6 specification now appears to say that if there is an unknown next-header field, an ICMP code 1 is supposed to be returned. (See the second full paragraph on page 6 of ipv6-spec-v2-01.) If this is the case, this simplifies things significantly. This way, if there is an unknown extension header before the AH header, the IPSEC host (or security gateway) will have already rejected the packet and have sent an ICMP packet back at the sender. So we don't need to have any words about handling unknown extension headers; they will just be rejected. Can someone in the IPNG working group confirm my reading of IPV6 spec? I'm curious --- was it ever the case that the extension header processing worked the way I described them in the first paragraph? The IPV6 expert whom I talked to was pretty definitive that this was the way things worked; I was pretty surprised, since I thought it was incredibly ugly and unclean, but I wasn't the IPv6 expert. - Ted -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 1 18:56:39 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id SAA02545 for ipng-dist; Fri, 1 May 1998 18:52:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id SAA02538 for ; Fri, 1 May 1998 18:52:42 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA29043 for ; Fri, 1 May 1998 18:52:42 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id SAA24284 for ; Fri, 1 May 1998 18:52:42 -0700 (PDT) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA26039; Fri, 1 May 1998 18:52:38 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199804301512.LAA20002@cichlid.raleigh.ibm.com> References: Your message of "Thu, 30 Apr 1998 01:17:32 EDT." <199804300517.BAA20034@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 May 1998 18:53:50 -0700 To: Thomas Narten From: Steve Deering Subject: (IPng 5760) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Cc: "Theodore Y. Ts'o" , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here's my take on IPv6 options and extension headers vs. AH computation. First, let's consider IPv6 options, i.e., those TLV things that are carried in either the Hop-by-Hop Options header or the Destination Options header. IPv6 options are designed to allow AH processing without understanding the semantics of the option. For example, a new option may be defined in the future, and an upper-layer protocol or application may request (via the IPv6 API) transmission of a packet containing that new option without requiring any change to the IPv6 (including AH) module in the source node. The Type code of the option indicates to the AH implementation whether or not the option data is mutable en-route. If it is mutable, the data is treated as zeros for AH purposes, else the data is treated verbatim. An option whose data is mutable en-route but whose final value is predictable must still be treated as zeros for AH purposes, because even though the final value may be predictable by the entity that requests transmission of the option (an upper-layer protocol or application in the source node), it would not be predictable to the (unmodified) AH implementation in the source node. To allow special handling of the "mutable but predictable" case would require a more elaborate IPv6 API in which both the original value and the predicted final value of an option could be supplied by an application or upper-layer protocol to the IPv6 (including AH) module. I don't think the added flexibility would be worth the extra complexity in the API and the extra documentation needed to explain this feature. Therefore, I am in favor of leaving the current definition of the IPv6 option Type encoding as is. Now let's consider IPv6 extension headers. In order for an AH implementation to compute an authenticating value to place in an AH header of a packet, the IPv6 module of which the AH implementation is a part must understand the semantics of all headers *preceding* the AH header. That is necessary in order to *find* the AH header in the first place (or to decide where to put it, in the case of a black-box AH-inserter). If, while parsing the headers preceding an AH header, an IPv6 module encounters a Next Header value that it does not understand: (a) It cannot tell whether the identified next header is an IPv6 extension header or something else. (E.g., it might be an unrecognized transport protocol header or anything else that can be identified by the IPv4/IPv6 Protocol/Next Header numbering space. (b) Even if it could tell that the next header were an IPv6 extension header, it could not necessarily tell how long that header is or what the type of the subsequent header is. (It is not required that all extension headers even have an explicit length field, let alone a length field in the same location and of the same granularity as in other extension headers, nor is it required that every extension header have its Next Header field at the same relative offset.) (c) Even if it could tell the length and subsequent header type of an unrecognized extension header, it could not necessarily continue parsing after the header. (E.g., imagine an IPv6 module that could recognize the length and next-header field of a Fragment header, but did not understand its semantics. For any packet carrying a non-initial fragment, the stuff that followed the Fragment header cannot be parsed as another header.) An AH implementation is not required to parse or recognize any headers *following* the AH header in a packet -- everything following the AH header must be treated as "payload" to be included in the AH computation as-is. This implies that everything following an AH header is considered immutable, which in turn implies that AH is incompatible with intermediate devices that modify, say, transport-layer headers (like NAT boxes and TCP "helpers"). That's a feature, not a bug. Since an IPv6 implementation processing an AH header must understand the semantics of all headers that precede the AH header, any new extension header designed to precede an AH header can include in its specification whatever AH handling is desired. For example, the specification could specify that certain parts of the header are: - immutable and included as-is in the AH computation, - mutable and treated as zero-valued for the AH computation, or - mutable but with a predictable final value that is to be included in the AH computation. Determining whether or not a destination understands a new extension header (whether it precedes or follows an AH header) is the originator's problem, just like determining whether or not a destination understands a new transport-layer header. A receiver that, in normal IPv6 processing, encounters an unrecognized header sends an ICMP Unrecognized Header Type message back to the source, which at least will explain to a source why it is failing. A device that inserts an AH header into a packet (as opposed to encapsulating the packet as payload following an AH header) without the knowledge and assistance of the source IPv6 module will presumably insert the AH header immediately following all headers that it recognizes as not being end-to-end (those being: a Hop-by-Hop Options header, any Routing headers, and any Destination Options headers that precede any Routing header). It would have no choice but to treat any unrecognized header as end-to-end -- it might well be an unrecognized transport-layer header, for example -- and would have to insert the AH header before the unrecognized header, and therefore treat the entire unrecognized header and everything following it as payload to be included in the AH computation. If such devices become common, it will make it difficult to introduce new extension headers that are not both end-to-end and immutable in transit. Though I think such devices are ill-advised (tunnel mode AH ought to be used instead), I don't think losing the ability to define new non-end-to-end or mutable extension headers would be all that horrible. All of the desired functionality ought to be achievable by the use of options rather than new extension headers, with the exception of getting AH coverage of a predictable final value of a mutable option. In any case, and to conclude after that long-winded explanation, the part of draft-ietf-ipsec-auth-header-05.txt that says: >>> If the IPsec implementation encounters an >>> extension header that it does not recognize, it MUST zero the whole >>> header except for the Next Header and Hdr Ext Len fields. does not make sense. At the source or destination of a packet, the presence of an unrecognized extension header before an AH header will prevent the AH processing from ever being invoked. In a black-box AH-inserter, any unrecognized header would necessarily follow the inserted AH header, and thus be treated as payload data and not zeroed. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 1 19:24:45 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id TAA02599 for ipng-dist; Fri, 1 May 1998 19:21:12 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id TAA02591 for ; Fri, 1 May 1998 19:21:03 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA02324 for ; Fri, 1 May 1998 19:21:02 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id TAA02267 for ; Fri, 1 May 1998 19:21:02 -0700 (PDT) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA27667; Fri, 1 May 1998 19:20:50 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199805010154.VAA20482@dcl.MIT.EDU> References: Robert Elz's message of Fri, 01 May 1998 07:46:34 +1000, <17976.893972794@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 May 1998 19:22:03 -0700 To: "Theodore Y. Ts'o" From: Steve Deering Subject: (IPng 5761) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Cc: Robert Elz , Thomas Narten , "Theodore Y. Ts'o" , jis@mit.edu, ipsec@tis.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 6:54 PM -0700 4/30/98, Theodore Y. Ts'o wrote: > If this is the case, this simplifies things significantly. This way, if > there is an unknown extension header before the AH header, the IPSEC > host (or security gateway) will have already rejected the packet and > have sent an ICMP packet back at the sender. So we don't need to have > any words about handling unknown extension headers; they will just be > rejected. Can someone in the IPNG working group confirm my reading of > IPV6 spec? Your reading of the IPv6 spec is correct, except that it doesn't say or imply anything about the bahavior of security gateways. Gateways that encapsulate entire IPv6 packets with an AH header will not examine any extension headers in the packet to be encapsulated, and therefore will not reject it on the basis of an unrecognized header. Gateways that insert an AH header into a passing IPv6 packet (architecturally impure device that I hope no one is seriously advocating) will probably have to treat an unrecognized header as a potential end-to-end header (e.g., an unrecognized transport protocol header), and therefore will insert the AH header before the unrecognized header and forward it onward, rather than rejecting it. > I'm curious --- was it ever the case that the extension header > processing worked the way I described them in the first paragraph? No. For the reasons you realized. > The IPV6 expert whom I talked to was pretty definitive that this was the > way things worked; I was pretty surprised, since I thought it was incredibly > ugly and unclean, but I wasn't the IPv6 expert. Your expert was mistaken (perhaps having once argued in favor of the behavior described to you, and forgetting that he or she didn't actually win the argument?). Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 4 06:41:34 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id GAA04251 for ipng-dist; Mon, 4 May 1998 06:38:02 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id GAA04244 for ; Mon, 4 May 1998 06:37:49 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA18757 for ; Mon, 4 May 1998 06:37:46 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA19857 for ; Mon, 4 May 1998 06:37:48 -0700 (PDT) Received: from [128.33.238.120] (TC120.BBN.COM [128.33.238.120]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id JAA01964; Mon, 4 May 1998 09:36:43 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: <199805010154.VAA20482@dcl.MIT.EDU> Robert Elz's message of Fri, 01 May 1998 07:46:34 +1000, <17976.893972794@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 May 1998 09:27:05 -0400 To: Steve Deering From: Stephen Kent Subject: (IPng 5762) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Cc: "Theodore Y. Ts'o" , Robert Elz , Thomas Narten , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve >Gateways that insert an AH header into a passing IPv6 packet (architecturally >impure device that I hope no one is seriously advocating) will probably have >to treat an unrecognized header as a potential end-to-end header (e.g., >an unrecognized transport protocol header), and therefore will insert the >AH header before the unrecognized header and forward it onward, rather than >rejecting it. IPsec requires any security gateway to use tunnel mode for transit traffic, avoiding the problem you cite. Thus such an implementation would not only be "architectually impure," it also would be non-compliant. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 4 09:03:06 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id IAA04396 for ipng-dist; Mon, 4 May 1998 08:58:55 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id IAA04389 for ; Mon, 4 May 1998 08:58:41 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA10984 for ; Mon, 4 May 1998 08:58:39 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA28232 for ; Mon, 4 May 1998 08:58:38 -0700 (PDT) Received: from [128.33.238.32] (TC032.BBN.COM [128.33.238.32]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id LAA29169; Mon, 4 May 1998 11:50:23 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199805041525.PAA19130@orchard.arlington.ma.us> References: Your message of "Mon, 4 May 1998 09:27:05 -0400 ." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 May 1998 11:41:27 -0400 To: Bill Sommerfeld From: Stephen Kent Subject: (IPng 5764) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Cc: Steve Deering , "Theodore Y. Ts'o" , Robert Elz , Thomas Narten , jis@mit.edu, ipsec@tis.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, I believe that the Arch Doc considers a BITW Ipsec device to be a host implementation in that context (at least for a single homed host). If the same device is used in front of a router, then it inherits the security gateway requirements. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 4 09:30:09 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id JAA04446 for ipng-dist; Mon, 4 May 1998 09:24:05 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id JAA04439 for ; Mon, 4 May 1998 09:23:51 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA17469 for ; Mon, 4 May 1998 09:23:49 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA12164 for ; Mon, 4 May 1998 09:23:43 -0700 (PDT) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id MAA17933; Mon, 4 May 1998 12:22:40 -0400 (EDT) Message-Id: <199805041622.MAA17933@brookfield.ans.net> To: Paul Traina cc: curtis@ans.net, huitema@bellcore.com (Christian Huitema), Quaizar Vohra , Dimitry Haskin , ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 5766) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Thu, 25 Sep 1997 17:10:44 PDT." <199709260010.RAA05909@base.juniper.net> Date: Mon, 04 May 1998 12:22:40 -0400 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199709260010.RAA05909@base.juniper.net>, Paul Traina writes: > > From: Curtis Villamizar > Subject: Re: (IPng 4522) Re: BGP and renumbering.. was /126 or /127 -- neit > he > >>r! > > > This could be done with IPv4 as long as there is a way to send a CEASE > that results in putting the routes on a withdrawl timer rather than > immmediately withdrawing them. You could even static configure the > BGP peering for this behavior and not change the protocol at all. > > A cease with a sanely limited short timer is a damn fine swiss-army knife > for solving a lot of problems. > > I feel an ID coming on. :-) John, This was in ftp://ftp.merit.edu/mail.archives/idr/idr.96.09.gz The rest of the conversation seems to be in this archive file. Curtis - - - - - - - - - - - - - - - - - From owner-idr@merit.edu Sat Sep 14 00:19:57 1996 Received: from merit.edu by nic.merit.edu (8.7.1/nic-1.0) id AAA06209; Sat, 14 Sep 1996 00:19:56 -0400 (EDT) Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id AAA12492 for idr-outgoing; Sat, 14 Sep 1996 00:21:21 -0400 (EDT) Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by merit.edu (8.7.5/merit-2.0) with SMTP id AAA12486 for ; Sat, 14 Sep 1996 00:21:17 -0400 (EDT) Received: by interlock.ans.net id AA00588 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Sat, 14 Sep 1996 00:21:04 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 14 Sep 1996 00:21:04 -0400 Message-Id: <199609140420.AAA21003@brookfield.ans.net> To: bgp@ans.net Cc: curtis@ans.net Reply-To: curtis@ans.net Subject: diffs to draft-ietf-idr-bgp4-03.txt Date: Sat, 14 Sep 1996 00:20:09 -0400 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk Yakov et al. Here are some suggested changes to the BGP4 draft. Briefly, there are a few separable issues: 1. Some wording changes (ie: hunk 1, 6, 7, 8, 14) 2. Proposing "BGP resynchronization". See below. 3. Replace descriptions of route selection with something more clear and accurate. 4. Replace some text about route overlap that is wrong and reflects earlier indecision on the part of the WG. The "BGP resynchronization" warents further mention. The idea was to make something 100% compatible with current BGP4 implementations that addresses the following: 1. Allows a better recovery if running a hosed implementation. No more clearing the BGP conection. 2. Allows a cheap policy reconfig (maybe less desirable than a true dynamic reconfig) that doesn't involve clearing the BGP conection. 3. Reduces the impact of occasional loss of BGP connections. Might even allow you to squeeze in a reload if it was real fast. 4. Reduces the exposure to TCP RST attacks. Given some of the talk on the NANOG list, #4 might not be a bad feature. Fixing BGP to use UDP is a bigger job and this and a good TCP PCB hashing and long listen queue for TCP SYN attack could prove very valuable changes. Curtis Just apply the diffs to draft-ietf-idr-bgp4-03.txt to get the new document. The diff hunks are: 1 an attempt to clear up wording regarding IBGP, EBGP, and IGP and the role of IBGP. 2 First mention of BGP resynchronization 3 I couldn't resist. Might want to leave this one out. 4 Add RESYNCHRONIZATION message type 5 Define RESYNCHRONIZATION message format 6 Clarifying sentence - path attributes are for the purpose of supporting a protocol extension mechanism. 7 Added the table with discresionary, required, or disallowed, etc. 8 Clarification of MULTI_EXIT_DISC usage. 9 Add BGP resynchronization to Error Handling section. 10 Allow marking routes for withdrawl on disconnect. 11 BGP Resynchronization section 12&13 Fixed overlap route jabber that was just plain wrong. 14 Clarified setting LOCAL_PREF. 16 Replaced description of route slection with one that is much more concise and clear and covers the route loop avoidance, including a brief description of the reasons loops can form. 17 Got rid of unclear tie breaker section. 18&19 Replaced the route overlap section with one that reflects reality now that we have plenty of experience with BGP4. 20&21 Eliminated a great deal of repitition and referred back to 9.1.2. btw- why can't 9.2.1 be as simple as 9.2.2 - or does 9.2.2 need to spell things out in detail like 9.2.1? *** draft-ietf-idr-bgp4-03.txt Sat Aug 17 08:34:53 1996 --- draft-ietf-idr-bgp4-03.txt.new Sat Sep 14 00:01:33 1996 *************** *** 205,230 **** router in another Autonomous System. The implications and applications of this architecture are for further study. If a particular AS has multiple BGP speakers and is providing transit service for other ASs, then care must be taken to ensure a consistent view of routing within the AS. A consistent view of the interior routes of the AS is provided by the interior routing protocol. A consistent view of the routes exterior to the AS can be provided by ! having all BGP speakers within the AS maintain direct BGP connections ! with each other. Using a common set of policies, the BGP speakers ! arrive at an agreement as to which border routers will serve as ! exit/entry points for particular destinations outside the AS. This ! information is communicated to the AS's internal routers, possibly ! via the interior routing protocol. Care must be taken to ensure that ! the interior routers have all been updated with transit information ! before the BGP speakers announce to other ASs that transit service is ! being provided. ! ! Connections between BGP speakers of different ASs are referred to as ! "external" links. BGP connections between BGP speakers within the ! same AS are referred to as "internal" links. Similarly, a peer in a ! different AS is referred to as an external peer, while a peer in the ! same AS may be described as an internal peer. --- 205,231 ---- router in another Autonomous System. The implications and applications of this architecture are for further study. + Connections between BGP speakers of different ASs are referred to as + "external" links. BGP connections between BGP speakers within the + same AS are referred to as "internal" links. Similarly, a peer in a + different AS is referred to as an external peer, while a peer in the + same AS may be described as an internal peer. Internal BGP and + external BGP are commonly abbreviated IBGP and EBGP. + If a particular AS has multiple BGP speakers and is providing transit service for other ASs, then care must be taken to ensure a consistent view of routing within the AS. A consistent view of the interior routes of the AS is provided by the interior routing protocol. A consistent view of the routes exterior to the AS can be provided by ! having all BGP speakers within the AS maintain direct IBGP connections ! with each other. Alternately the interior routing protocol can ! pass BGP information among routers within an AS, taking care not to ! lose BGP attributes that will be needed by EBGP speakers if transit ! connectivity is being providided. For the purpose of discussion, ! it is assumed that BGP information is passed within an AS using ! IBGP. Care must be taken to ensure that the interior routers have ! all been updated with transit information before the EBGP speakers ! announce to other ASs that transit service is being provided. *************** *** 282,291 **** Information can be advertised, or c) the BGP speaker - BGP speaker connection can be closed, which ! implicitly removes from service all routes which the pair of ! speakers had advertised to each other. ! ! --- 283,297 ---- Information can be advertised, or c) the BGP speaker - BGP speaker connection can be closed, which ! implicitly marks all routes hte pair of speakers had advertised ! to each other for removal from service if a connection is not ! reestablished and the routes readvertised before a resynchronization ! completed message or before a configured expiration timer elapses. ! ! d) the BGP speaker or listenner may request a resynchronization ! which explicitly marks all routes for removal from service if not ! readvertised before a resynchronization completed message or before ! a configured expiration timer elapses. *************** *** 333,339 **** implementation must maintain three separate copies of the routing information. The choice of implementation (for example, 3 copies of the information vs 1 copy with pointers) is not constrained by the ! protocol. 4. Message Formats --- 339,346 ---- implementation must maintain three separate copies of the routing information. The choice of implementation (for example, 3 copies of the information vs 1 copy with pointers) is not constrained by the ! protocol. And in fact you'd be pretty stupid to maintain separate ! copies though it has been tried. 4. Message Formats *************** *** 435,440 **** --- 442,448 ---- 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE + 5 - RESYNCHRONIZATION 4.2 OPEN Message Format *************** *** 1127,1135 **** --- 1135,1182 ---- + 4.5 RESYNCHRONIZATION Message Format + + + A RESYNCHRONIZATION message is sent when there is reason to believe + that routing information in either the speaker of the listenner is + not correct or routing policy has been changed and the speaker is + unable to process the routing policy change without readvertising + the full set of routes. A RESYNCHRONIZATION message should never + be required except where a policy change has occurred or unless + either the speaker of listenner implementation is in error. + + + In addition to the fixed-size BGP header, the RESYNCHRONIZATION + message contains the following fields: + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Request Type | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Request Type: + + This 1-octet unsigned integer indicates the type of + RESYNCHRONIZATION request. The following Request Codes have + been defined: + + Request Code Symbolic Name Reference + + 1 Sender Resynchronizing Request Section 6.9 + + 2 Receiver Resynchronize Request Section 6.9 + + 3 Resynchronizion Completed Section 6.9 + + The length of the RESYNCHRONIZATION message is 21 octets (including + message header). + + Expiration Date February 1996 [Page 19] *************** *** 1145,1151 **** This section discusses the path attributes of the UPDATE message. ! Path attributes fall into four separate categories: 1. Well-known mandatory. 2. Well-known discretionary. --- 1192,1199 ---- This section discusses the path attributes of the UPDATE message. ! Path attributes fall into four separate categories for the purpose ! of supporting a protocol extension mechanism: 1. Well-known mandatory. 2. Well-known discretionary. *************** *** 1208,1213 **** --- 1256,1275 ---- The same attribute cannot appear more than once within the Path Attributes field of a particular UPDATE message. + The manditory category refers to a field which must be present in + both IBGP and EBGP exchanges. Attributes classified as optional + for the purpose of the protocol extension mechanism may be purely + discresionary, or discresionary, required, or disallowed in certain + contexts. + + attribute EBGP IBGP + ORIGIN manditory manditory + AS_PATH manditory manditory + NEXT_HOP discresionary discresionary + MULTI_EXIT_DISC discresionary discresionary + LOCAL_PREF disallowed required + ATOMIC_AGGREGATE discresionary discresionary + AGGREGATOR discresionary discresionary 5.1 Path Attribute Usage *************** *** 1342,1348 **** preferred. If received over external links, the MULTI_EXIT_DISC attribute may be propagated over internal links to other BGP speakers within the same AS. The MULTI_EXIT_DISC attribute is never ! propagated to other BGP speakers in neighboring AS's. 5.1.5 LOCAL_PREF --- 1404,1410 ---- preferred. If received over external links, the MULTI_EXIT_DISC attribute may be propagated over internal links to other BGP speakers within the same AS. The MULTI_EXIT_DISC attribute is never ! propagated from IBGP to other BGP speakers in neighboring AS's. 5.1.5 LOCAL_PREF *************** *** 1411,1423 **** attribute which shall contain its own AS number and IP address. ! 6. BGP Error Handling. This section describes actions to be taken when errors are detected ! while processing BGP messages. ! When any of the conditions described here are detected, a NOTIFICATION message with the indicated Error Code, Error Subcode, and Data fields is sent, and the BGP connection is closed. If no Error Subcode is specified, then a zero must be used. --- 1473,1485 ---- attribute which shall contain its own AS number and IP address. ! 6. BGP Error and Resynchronization Handling. This section describes actions to be taken when errors are detected ! while processing BGP messages or during resynchronization. ! When any erro conditions described here are detected, a NOTIFICATION message with the indicated Error Code, Error Subcode, and Data fields is sent, and the BGP connection is closed. If no Error Subcode is specified, then a zero must be used. *************** *** 1425,1431 **** The phrase "the BGP connection is closed" means that the transport protocol connection has been closed and that all resources for that BGP connection have been deallocated. Routing table entries ! associated with the remote peer are marked as invalid. The fact that the routes have become invalid is passed to other BGP peers before the routes are deleted from the system. --- 1487,1494 ---- The phrase "the BGP connection is closed" means that the transport protocol connection has been closed and that all resources for that BGP connection have been deallocated. Routing table entries ! associated with the remote peer are either marked as invalid or ! optionally marked as if a resynchronization had occurred. The fact that the routes have become invalid is passed to other BGP peers before the routes are deleted from the system. *************** *** 1754,1759 **** --- 1817,1888 ---- message with the Error Code Cease. + 6.9 BGP Resynchronization + + + BGP implementation may optionally support a form of graceful + resynchronization rather than closing the BGP connection in certain + conditions and may optionally allow resynchronization rather than + immediate route withdrawl when a BGP connection is closed. BGP + implementation which support resynchronization must be prepared to + detect and interoperate with implementations which do not. + + A resynchronization request will generally be made in response to + operator intervention. A resynchronization request can also be + made when conditions indicate internal inconsistency, such as + failure of a coded assertion. Implementations which require + resynchronization should be considered in error, however the BGP + protocol accomodates the possibility that errant implementation may + exist (transiently) and provides resynchronization as a means to + restore operational integrity with minimal disruption. + + After sending a RESYNCHRONIZATION message with a Sender + Resynchronizing Request (Request Code 1) or receiving a + RESYNCHRONIZATION message with a Receiver Resynchronize Request + (Request Code 2), the sender must empty the associated Adj-RIBs-Out + and readvertise all route in its Loc-RIB to its peer as described + in section 9.1.3, as if no routes had ever been advertised to that + peer. + + After receiving a RESYNCHRONIZATION message with a Sender + Resynchronizing Request (Request Code 1) or sending a + RESYNCHRONIZATION message with a Receiver Resynchronize Request + (Request Code 2), the receiver must mark all entries in the Loc-RIB + for removal and empty the Adj-RIBs-In. As the Adj-RIBs-In is + repopulated the marks in the associated Loc-RIB entires are + removed. After a configured expiration timer has elapsed or a + RESYNCHRONIZATION message with a Resynchronizion Completed (Request + Code 3) is received, all entries in the Loc-RIB still marked are + removed as it they had been withdrawn. + + Optionally when a BGP connection is closed the Loc-RIB entries may + be treated in the same way they would be when receiving a + RESYNCHRONIZATION message with a Sender Resynchronizing Request. + It should be possible to configure a different expiration timer + value for this condition or disable it entirely. + + Optionally a BGP speaker may send a RESYNCHRONIZATION message with + a Resynchronizion Completed after a connection has been + established, in effect treating the entry to the established state + as an implied RESYNCHRONIZATION message with a Receiver Resynchronize + Request from the peer. + + An implementation which does not support BGP Resynchronization must + send a NOTIFICATION with a Message Header Error (Error Code 1) and a + Bad Message Type (Error subcode 3). + + An implementation which does support BGP Resynchronization must + have the ability to configure a peer as not supporting BGP + Resynchronization and not send any form of RESYNCHRONIZATION + message to such a peer. It must also be able to record the fact + that a peer has sent a NOTIFICATION in response to a + RESYNCHRONIZATION message and disable sending any further + RESYNCHRONIZATION messages to that peer, even after the BGP + connection if broken and reestablished, unless that peer later + sends a RESYNCHRONIZATION message (which would be interpretted as a + code update adding support for BGP Resynchronization). + + 7. BGP Version Negotiation. *************** *** 2085,2095 **** shall run its Decision Process since the older route is no longer available for use. - ii) If the new route is an overlapping route that is included (see - 9.1.4) in an earlier route contained in the Adj-RIB-In, the BGP - speaker shall run its Decision Process since the more specific route - - Expiration Date February 1996 [Page 35] --- 2214,2219 ---- *************** *** 2100,2121 **** INTERNET DRAFT August 1996 ! has implicitly made a portion of the less specific route unavailable ! for use. ! ! iii) If the new route has identical path attributes to an earlier ! route contained in the Adj-RIB-In, and is more specific (see 9.1.4) ! than the earlier route, no further actions are necessary. ! ! iv) If the new route has NLRI that is not present in any of the ! routes currently stored in the Adj-RIB-In, then the new route shall ! be placed in the Adj-RIB-In. The BGP speaker shall run its Decision ! Process. ! ! v) If the new route is an overlapping route that is less specific ! (see 9.1.4) than an earlier route contained in the Adj-RIB-In, the ! BGP speaker shall run its Decision Process on the set of destinations ! described only by the less specific route. 9.1 Decision Process --- 2224,2235 ---- INTERNET DRAFT August 1996 ! ii) If the new route has NLRI that is not present in any of the ! routes currently stored in the Adj-RIB-In, regardless of whether ! the new route overlaps an earlier route contained in the Adj-RIB-In ! that is either more specific or less specific (see 9.1.4), then the ! new route shall be placed in the Adj-RIB-In. The BGP speaker shall ! run its Decision Process. 9.1 Decision Process *************** *** 2199,2213 **** operating on all new or unfeasible routes contained within it. For each newly received or replacement feasible route, the local BGP ! speaker shall determine a degree of preference. If the route is ! learned from a BGP speaker in the local autonomous system, either the value of the LOCAL_PREF attribute shall be taken as the degree of ! preference, or the local system shall compute the degree of ! preference of the route based on preconfigured policy information. If ! the route is learned from a BGP speaker in a neighboring autonomous ! system, then the degree of preference shall be computed based on ! preconfigured policy information. The exact nature of this policy ! information and the computation involved is a local matter. The --- 2313,2327 ---- operating on all new or unfeasible routes contained within it. For each newly received or replacement feasible route, the local BGP ! speaker shall determine a degree of preference. If the route is ! learned from a BGP speaker in the local autonomous system, the value of the LOCAL_PREF attribute shall be taken as the degree of ! preference. If the route is learned from a BGP speaker in a ! neighboring autonomous system, then the degree of preference shall ! be computed based on preconfigured policy information and used as ! the LOCAL_PREF value in any IBGP readvertisement. The exact nature ! of this policy information and the computation involved is a local ! matter. The *************** *** 2243,2259 **** the local BGP speaker doesn't have a route in its Loc-RIB, the BGP route SHOULD be excluded from the Phase 2 decision function. ! For each set of destinations for which a feasible route exists in the ! Adj-RIBs-In, the local BGP speaker shall identify the route that has: ! ! a) the highest degree of preference of any route to the same set ! of destinations, or ! ! b) is the only route to that destination, or ! ! c) is selected as a result of the Phase 2 tie breaking rules ! specified in 9.1.2.1. ! The local speaker SHALL then install that route in the Loc-RIB, replacing any route to the same destination that is currently being --- 2357,2416 ---- the local BGP speaker doesn't have a route in its Loc-RIB, the BGP route SHOULD be excluded from the Phase 2 decision function. ! It is critical that routers within an AS do not make conflicting ! decisions regarding route selection that would cause forwarding ! loops to occur (routers pointing traffic as each other or in a ! cycle). BGP speakers will consider the following attributes in ! determining preference and will consider no others. ! ! 1. NEXT_HOP. The next hop must be reachable, or if NEXT_HOP is ! not provided, the advertising router must be reachable) ! ! 1. LOCAL_PREF. ! ! 2. MULTI_EXIT_DISC. This comparison is applicable only when ! comparing MULTI_EXIT_DISC received from the same ! neighboring AS, including those received from the same ! neighboring AS and passed via IBGP. ! ! 3. Internal routing protocol cost. Lower costs are preferred. ! Select the route that has the lowest cost (interior ! distance) to the entity depicted by the NEXT_HOP attribute ! of the route. ! ! 4. Advertising router BGP Identifier. If at least one of the ! candidate routes was advertised by the BGP speaker in a ! neighboring autonomous system, select the route that was ! advertised by the BGP speaker in a neighboring autonomous ! system whose BGP Identifier has the lowest value among all ! other BGP speakers in neighboring autonomous systems. ! Otherwise, select the route that was advertised by the BGP ! speaker whose BGP Identifier has the lowest value. ! ! The MULTI_EXIT_DISC may be dropped when passing a route via IBGP. ! To prevent routing loops a route with a MULTI_EXIT_DISC (if the ! routes and received from the same neighboring AS and therefore the ! comparison is applicable) is preferred over one without. ! ! The outcome of a comparison must be independent of the order in ! which routes are placed in the Adj-Rib-In and Local-Rib. Due to ! difference in the backlog of propogated routes among IBGP peers, the ! same set of routes may arrive in different orders on differnt ! routers. If routes are compared in arbitrary order, under certain ! conditions routing loops can occur. This is a consequence of the ! use of MULTI_EXIT_DISC in comparing routes received from the same ! neighboring AS but not considering MULTI_EXIT_DISC when comparing ! routes received from differing neighboring AS. ! ! The comparison algorithm must insure a deterministic decision ! outcome. To accomplish this, routes are compared in a constrained ! order. First all routes are checked for feasibility, insuring that ! the NEXT_HOP is reachable. All routes from the same neighboring AS ! are first compared using the criteria above, LOCAL_PREF, ! MULTI_EXIT_DISC, internal routing protocol cost, and Advertising ! router IP address. Then the best route selected from each ! neighboring AS are compared using the criteria, LOCAL_PREF, internal ! routing protocol cost, and Advertising router BGP Identifier. The local speaker SHALL then install that route in the Loc-RIB, replacing any route to the same destination that is currently being *************** *** 2280,2325 **** INTERNET DRAFT August 1996 ! RIBs-In. ! ! ! 9.1.2.1 Breaking Ties (Phase 2) ! ! ! In its Adj-RIBs-In a BGP speaker may have several routes to the same ! destination that have the same degree of preference. The local ! speaker can select only one of these routes for inclusion in the ! associated Loc-RIB. The local speaker considers all equally ! preferable routes, both those received from BGP speakers located in ! neighboring autonomous systems, and those received from other BGP ! speakers located in the local speaker's autonomous system. ! ! The following tie-breaking procedure assumes that for each candidate ! route all the BGP speakers within an autonomous system can ascertain ! the cost of a path (interior distance) to the address depicted by the ! NEXT_HOP attribute of the route. Ties shall be broken according to ! the following algorithm: ! ! a) If the local system is configured to take into account ! MULTI_EXIT_DISC, and the candidate routes differ in their ! MULTI_EXIT_DISC attribute, select the route that has the lowest ! value of the MULTI_EXIT_DISC attribute. A route with ! MULTI_EXIT_DISC shall be preferred to a route without ! MULTI_EXIT_DIST. ! ! b) Otherwise, select the route that has the lowest cost (interior ! distance) to the entity depicted by the NEXT_HOP attribute of the ! route. If there are several routes with the same cost, then the ! tie-breaking shall be broken as follows: ! ! - if at least one of the candidate routes was advertised by the ! BGP speaker in a neighboring autonomous system, select the ! route that was advertised by the BGP speaker in a neighboring ! autonomous system whose BGP Identifier has the lowest value ! among all other BGP speakers in neighboring autonomous systems; ! ! - otherwise, select the route that was advertised by the BGP ! speaker whose BGP Identifier has the lowest value. 9.1.3 Phase 3: Route Dissemination --- 2437,2443 ---- INTERNET DRAFT August 1996 ! RIB-In. 9.1.3 Phase 3: Route Dissemination *************** *** 2425,2451 **** the less specific route. If a BGP speaker receives overlapping routes, the Decision Process ! shall take into account the semantics of the overlapping routes. In ! particular, if a BGP speaker accepts the less specific route while ! rejecting the more specific route from the same peer, then the ! destinations represented by the overlap may not forward along the ASs ! listed in the AS_PATH attribute of that route. Therefore, a BGP ! speaker has the following choices: ! ! a) Install both the less and the more specific routes ! ! b) Install the more specific route only ! ! c) Install the non-overlapping part of the less specific ! route only (that implies de-aggregation) ! ! d) Aggregate the two routes and install the aggregated route ! ! e) Install the less specific route only ! ! f) Install neither route ! If a BGP speaker chooses e), then it should add ATOMIC_AGGREGATE attribute to the route. A route that carries ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the NLRI of this route --- 2543,2554 ---- the less specific route. If a BGP speaker receives overlapping routes, the Decision Process ! shall consider both routes based on configured acceptance policy. ! If both are accepted the Decision Process will install both the ! less and the more specific routes or aggregate the two routes and ! install the aggregated route. ! If a BGP speaker chooses to aggregate, then it should add ATOMIC_AGGREGATE attribute to the route. A route that carries ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the NLRI of this route *************** *** 2462,2470 **** can not be made more specific. Forwarding along such a route does not guarantee that IP packets will actually traverse only ASs listed ! in the AS_PATH attribute of the route. If a BGP speaker chooses a), ! it must not advertise the more general route without the more ! specific route. 9.2 Update-Send Process --- 2565,2573 ---- can not be made more specific. Forwarding along such a route does not guarantee that IP packets will actually traverse only ASs listed ! in the AS_PATH attribute of the route. If a BGP speaker chooses to ! install both routes it must not advertise the more general route ! without the more specific route. 9.2 Update-Send Process *************** *** 2500,2531 **** When a BGP speaker receives a new route from a BGP speaker in a neighboring autonomous system, it shall advertise that route to all other BGP speakers in its autonomous system by means of an UPDATE ! message if any of the following conditions occur: ! ! 1) the degree of preference assigned to the newly received route ! by the local BGP speaker is higher than the degree of preference ! that the local speaker has assigned to other routes that have been ! received from BGP speakers in neighboring autonomous systems, or ! ! 2) there are no other routes that have been received from BGP ! ! ! ! Expiration Date February 1996 [Page 42] ! ! ! ! ! ! INTERNET DRAFT August 1996 ! ! ! speakers in neighboring autonomous systems, or ! ! 3) the newly received route is selected as a result of breaking a ! tie between several routes which have the highest degree of ! preference, and the same destination (the tie-breaking procedure ! is specified in 9.2.1.1). When a BGP speaker receives an UPDATE message with a non-empty WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all --- 2603,2610 ---- When a BGP speaker receives a new route from a BGP speaker in a neighboring autonomous system, it shall advertise that route to all other BGP speakers in its autonomous system by means of an UPDATE ! message if this route has become the best route installed in the ! Local-Rib according to the route selection rules in 9.1.2. When a BGP speaker receives an UPDATE message with a non-empty WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all *************** *** 2554,2598 **** All feasible routes which are advertised shall be placed in the appropriate Adj-RIBs-Out, and all unfeasible routes which are advertised shall be removed from the Adj-RIBs-Out. - - - 9.2.1.1 Breaking Ties (Internal Updates) - - - If a local BGP speaker has connections to several BGP speakers in - neighboring autonomous systems, there will be multiple Adj-RIBs-In - associated with these peers. These Adj-RIBs-In might contain several - equally preferable routes to the same destination, all of which were - advertised by BGP speakers located in neighboring autonomous systems. - The local BGP speaker shall select one of these routes according to - the following rules: - - a) If the candidate routes differ only in their NEXT_HOP and - - - - Expiration Date February 1996 [Page 43] - - - - - - INTERNET DRAFT August 1996 - - - MULTI_EXIT_DISC attributes, and the local system is configured to - take into account the MULTI_EXIT_DISC attribute, select the route - that has the lowest value of the MULTI_EXIT_DISC attribute. A - route with the MULTI_EXIT_DISC attribute shall be preferred to a - route without the MULTI_EXIT_DISC attribute. - - b) If the local system can ascertain the cost of a path to the - entity depicted by the NEXT_HOP attribute of the candidate route, - select the route with the lowest cost. - - c) In all other cases, select the route that was advertised by the - BGP speaker whose BGP Identifier has the lowest value. - 9.2.2 External Updates --- 2633,2638 ---- - - - - - - - - - - - - - - - - - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 4 11:50:34 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id LAA04734 for ipng-dist; Mon, 4 May 1998 11:45:47 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id LAA04719 for ; Mon, 4 May 1998 11:45:34 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA26130 for ; Mon, 4 May 1998 11:45:32 -0700 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA10018 for ; Mon, 4 May 1998 11:45:30 -0700 (PDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id OAA46632; Mon, 4 May 1998 14:44:45 -0400 (EDT) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA31694; Mon, 4 May 1998 14:44:45 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id OAA20814; Mon, 4 May 1998 14:45:15 -0400 (EDT) Message-Id: <199805041845.OAA20814@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: Steve Deering cc: "Theodore Y. Ts'o" , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: (IPng 5768) Re: [Karen Seo: Thomas Narten -- clarification, etc.] In-reply-to: Your message of "Fri, 01 May 1998 18:53:50 PDT." Date: Mon, 04 May 1998 14:45:14 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, Thanks for the explanation regarding IPv6 options. I was not (and am not) calling for changing the semantics of the "mutable" bit in the options; rather, I was seeking confirmation that the intended semantics were those as written in the current draft. Looking back at RFC 1883, the same text is there also. I was apparently confusing the IPv6 options and extension headers in my original note on this point, assuming they were intended to have similar semantics. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 4 13:59:16 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id NAA04984 for ipng-dist; Mon, 4 May 1998 13:53:56 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id NAA04977 for ; Mon, 4 May 1998 13:53:42 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA02472 for ; Mon, 4 May 1998 13:53:39 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA25719 for ; Mon, 4 May 1998 13:53:39 -0700 (PDT) Received: from [128.33.238.32] (ARA20.BBN.COM [128.89.30.20]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id QAA01514; Mon, 4 May 1998 16:53:11 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199805041609.QAA19272@orchard.arlington.ma.us> References: Your message of "Mon, 4 May 1998 11:41:27 -0400 ." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 May 1998 16:44:18 -0400 To: Bill Sommerfeld From: Stephen Kent Subject: (IPng 5769) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Cc: Steve Deering , "Theodore Y. Ts'o" , Robert Elz , Thomas Narten , jis@mit.edu, ipsec@tis.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, >However, the fact that the host implementation is in two pieces allows >for the possibility that the "real host" can generate extension >headers which the "bump" doesn't know about. Actually, given modular >software components, the same thing can happen within a single host >implementation. > >>From an engineering point of view, I think there should clearly be a >specified behavior in the presence of unknown extension headers.. Good point. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 4 21:56:46 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id VAA05435 for ipng-dist; Mon, 4 May 1998 21:52:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id VAA05428 for ; Mon, 4 May 1998 21:52:04 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA28873 for ; Mon, 4 May 1998 21:52:03 -0700 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by earth.sun.com (8.8.8/8.8.8) with SMTP id VAA22156 for ; Mon, 4 May 1998 21:52:05 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA02214; Tue, 5 May 98 00:50:44 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id AAA21748; Tue, 5 May 1998 00:50:32 -0400 Date: Tue, 5 May 1998 00:50:32 -0400 Message-Id: <199805050450.AAA21748@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Bill Sommerfeld Cc: Stephen Kent , Steve Deering , "Theodore Y. Ts'o" , Robert Elz , Thomas Narten , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.eng.sun.com In-Reply-To: Bill Sommerfeld's message of Mon, 04 May 1998 12:09:44 -0400, <199805041609.QAA19272@orchard.arlington.ma.us> Subject: (IPng 5771) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 04 May 1998 12:09:44 -0400 From: Bill Sommerfeld However, the fact that the host implementation is in two pieces allows for the possibility that the "real host" can generate extension headers which the "bump" doesn't know about. Actually, given modular software components, the same thing can happen within a single host implementation. >From an engineering point of view, I think there should clearly be a specified behavior in the presence of unknown extension headers.. The question is what a BITW (Bump In The Wire) implementation will do when it tries to apply AH. RFC 1883 specifies a recommended IPv6 extension header order: IPv6 header Hop-by-Hop Options header Destination Options header (note 1) Routing header Fragment header Authentication header (note 2) Encapsulating Security Payload header (note 2) Destination Options header (note 3) upper-layer header So, presumably a BITW implementation will need to paw through the extension headers looking for the right place to insert the AH header. Question --- what should it do if it finds an extension header that it doesn't know about? I suppose it could add the AH header before the unknown extension header, but it's not clear that will always be the right thing. In fact, I'm not sure that a BITW implementation is a good idea for IPV6, given my quick exposure to it. If the IPNG working group wants to preserve flexibility about adding new extension headers, some before the Authentication Header (so that intervening network-layer devices can more easily look at them, or modify them), and some after the Authentication Header, it's not at all clear how to make this work with a BITW implementation that doesn't know where to insert the authentication header. (And while we've been using the AH in this discussion, the same concerns apply for ESP as well. The question is at what point in the extension headers do you apply the security protocol when doing a BITW implementation.) - Ted -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 4 22:42:56 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id WAA05480 for ipng-dist; Mon, 4 May 1998 22:38:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id WAA05473 for ; Mon, 4 May 1998 22:38:31 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA04240 for ; Mon, 4 May 1998 22:38:32 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by earth.sun.com (8.8.8/8.8.8) with SMTP id WAA04503 for ; Mon, 4 May 1998 22:38:32 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA24207; Tue, 5 May 98 01:38:29 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id BAA21758; Tue, 5 May 1998 01:38:29 -0400 Date: Tue, 5 May 1998 01:38:29 -0400 Message-Id: <199805050538.BAA21758@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: (IPng 5772) [Theodore Y. Ts'o: Re: forward progress on IPSec AH] Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I meant to sent the following to the working group lists, sorry. - Ted ------- Forwarded Message Date: Tue, 5 May 1998 01:21:50 -0400 From: "Theodore Y. Ts'o" To: Thomas Narten Cc: "Theodore Y. Ts'o" , Steve Bellovin , jis@MIT.EDU, rgm-sec@htt-consult.com, mleech@nortel.ca In-Reply-To: Thomas Narten's message of Fri, 01 May 1998 09:34:54 -0400, <199805011334.JAA19312@cichlid.raleigh.ibm.com> Subject: Re: forward progress on IPSec AH Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Fri, 01 May 1998 09:34:54 -0400 From: Thomas Narten What needs to be done to get closure on these documents? OK, what to do... 1) The mutable bit semantics discussion in IPv6 options is (I believe) mostly an IPng discussion. In a sense, IPSec just needs to do what the IPng documents say. I'd like to wait for input from Deering (he's ACKed me that he will do so RSN). If the end result is leave things as currently defined, the issue goes away. Deering has weighed in to not change the mutable bit semantics for options. Assuming that we go with his recommendation, the IPSEC and IPNG drafts seem to be in agreement here, so the issue goes away. I think part of the confusion is caused by rather confusing terminology. There are Extensions (which are sometimes called options, I think incorrectly), as well as sets of individual options (taken from a different number space than the Extension headers) for the Hop by Hop and Destination options Extensions. As near as I can tell, calling the other extension headers "options" is a misnomer. Some extension headers are _optional_, but they should not be called _options_. Some of this confusion is in the AH spec, but I've seen it in other places as well. I think we will eventually want to clean up the text, before we go to draft standard, but I don't think we necessarily need to clear this up now. 2) The interoperability issue I raised with regards to whether the sender includes a "new" extension header in the AH check needs some sort of resolution. This problem is largely independent of 1). I believe that this is an IPSec decision to make. Just pick the least worst solution, it would seem. It looks like the IPV6 drafts very explicitly say that new extension headers cause the packet to be rejected. If we are to harmonize with this position, then the following text in section 3.3.3.1 of the auth-header document must be changed: If the IPsec implementation encounters an extension header that it does not recognize, it MUST zero the whole header except for the Next Header and Hdr Ext Len fields. The length of the extension header MUST be computed by 8 * Hdr Ext Len value + 8. ... since there's no good way to determine where the next header and header length fields were. (It would have been good if the location for next header and header-length were fixed for all non-terminal header, which apparently originally was a design goal, but several IPV6 folks have claimed that this is now a bad assumption to make.) If this is true, I don't see how to what else BITS or BITW implementations can do besides reject packets if they don't know what to do with an extension header which comes before the AH or ESP header. Processing has to stop, since there's no way to continue. Proposed replacement text for the above text in 3.3.3.1: If the IPsec implementation encounters an extension header that it does not recognize, it MUST reject it per section 4 of RFC 1883. Again, in the future, we may want to harmonize the terminology so that there aren't any confusion between how the IPV6 specs says things and the IPSEC spec says thing. We probably need to make more explicit that some IPV6 extension headers may appear before the Authentication Header, and some may appear afterwards, and that all extension headers appearing after the AH are included in the ICV. This is strongly implied, and apparently assumes this is the case, but it is not actually stated explicitly. Comments on the above approach for moving forward? (Leave the mutability text alone, and harmonize with the RFC-1883 position which says that unknown extension headers cause an ICMP code 2 packet.) - Ted ------- End Forwarded Message -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 5 03:59:59 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id DAA05683 for ipng-dist; Tue, 5 May 1998 03:56:24 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id DAA05676 for ; Tue, 5 May 1998 03:56:10 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id DAA06503 for ; Tue, 5 May 1998 03:56:07 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id DAA20783 for ; Tue, 5 May 1998 03:56:08 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA01887; Tue, 5 May 1998 06:55:47 -0400 (EDT) Message-Id: <199805051055.GAA01887@ietf.org> To: IETF-Announce:;;;@CNRI.Reston.VA.US; Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 5773) Last Call: Internet Protocol, Version 6 (IPv6) Specification to Draft Standard Reply-to: iesg@ietf.org Date: Tue, 05 May 1998 06:55:47 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider the following as Draft Standards: o Internet Protocol, Version 6 (IPv6) Specification replacing RFC 1883, currently a Proposed Standard. o Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification replacing RFC 1885, currently a Proposed Standard o Path MTU Discovery for IP version 6 , currently a 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@ietf.org or ietf@ietf.org mailing lists by May 19, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-spec-v2-01.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v2-00.txt ftp://ftp.isi.edu/in-notes/rfc1981.txt Implemenation Reports for all three can be found at http://www.ietf.org/IESG/implementation.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 5 09:58:33 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id JAA06008 for ipng-dist; Tue, 5 May 1998 09:52:42 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with ESMTP id JAA06001 for ; Tue, 5 May 1998 09:52:35 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with ESMTP id JAA13108 for ; Tue, 5 May 1998 09:52:33 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA28282 for ipng@sunroof.eng.sun.com; Tue, 5 May 1998 09:52:15 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id IAA04361 for ; Mon, 4 May 1998 08:29:54 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA04229 for ; Mon, 4 May 1998 08:29:53 -0700 Received: from orchard.arlington.ma.us (sommerfeld.ne.mediaone.net [24.128.88.62]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA12124 for ; Mon, 4 May 1998 08:29:53 -0700 (PDT) Received: from localhost (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with SMTP id PAA19130; Mon, 4 May 1998 15:25:52 GMT Message-Id: <199805041525.PAA19130@orchard.arlington.ma.us> To: Stephen Kent cc: Steve Deering , "Theodore Y. Ts'o" , Robert Elz , Thomas Narten , jis@mit.edu, ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: (IPng 5774) Re: [Karen Seo: Thomas Narten -- clarification, etc.] In-reply-to: Your message of "Mon, 4 May 1998 09:27:05 -0400 ." Date: Mon, 04 May 1998 11:25:51 -0400 From: Bill Sommerfeld Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Gateways that insert an AH header into a passing IPv6 packet (architecturally > >impure device that I hope no one is seriously advocating) will probably have > >to treat an unrecognized header as a potential end-to-end header (e.g., > >an unrecognized transport protocol header), and therefore will insert the > >AH header before the unrecognized header and forward it onward, rather than > >rejecting it. > > IPsec requires any security gateway to use tunnel mode for transit traffic, > avoiding the problem you cite. Thus such an implementation would not only > be "architectually impure," it also would be non-compliant. What about "bump in the cord" security devices which sit between a single host and the rest of the network, and do the AH/ESP protocol processing for them? They are, I believe, allowed for by the ipsec architecture spec, and, depending on how you look at them, they have aspects of both host and security-gateway implementations of AH/ESP.. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 5 09:58:32 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id JAA06017 for ipng-dist; Tue, 5 May 1998 09:53:14 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with ESMTP id JAA06010 for ; Tue, 5 May 1998 09:53:07 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with ESMTP id JAA13225 for ; Tue, 5 May 1998 09:53:05 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA28310 for ipng@sunroof.eng.sun.com; Tue, 5 May 1998 09:52:47 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id JAA04426 for ; Mon, 4 May 1998 09:13:32 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA14833 for ; Mon, 4 May 1998 09:13:31 -0700 Received: from orchard.arlington.ma.us (sommerfeld.ne.mediaone.net [24.128.88.62]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA06444 for ; Mon, 4 May 1998 09:13:30 -0700 (PDT) Received: from localhost (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with SMTP id QAA19272; Mon, 4 May 1998 16:09:44 GMT Message-Id: <199805041609.QAA19272@orchard.arlington.ma.us> To: Stephen Kent cc: Steve Deering , "Theodore Y. Ts'o" , Robert Elz , Thomas Narten , jis@mit.edu, ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: (IPng 5775) Re: [Karen Seo: Thomas Narten -- clarification, etc.] In-reply-to: Your message of "Mon, 4 May 1998 11:41:27 -0400 ." Date: Mon, 04 May 1998 12:09:44 -0400 From: Bill Sommerfeld Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I believe that the Arch Doc considers a BITW Ipsec device to be a host > implementation in that context (at least for a single homed host). If the > same device is used in front of a router, then it inherits the security > gateway requirements. However, the fact that the host implementation is in two pieces allows for the possibility that the "real host" can generate extension headers which the "bump" doesn't know about. Actually, given modular software components, the same thing can happen within a single host implementation. >From an engineering point of view, I think there should clearly be a specified behavior in the presence of unknown extension headers.. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 5 10:01:11 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id JAA06029 for ipng-dist; Tue, 5 May 1998 09:56:52 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with ESMTP id JAA06019 for ; Tue, 5 May 1998 09:56:39 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with ESMTP id JAA13954 for ; Tue, 5 May 1998 09:56:37 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA28339 for ipng@sunroof.eng.sun.com; Tue, 5 May 1998 09:56:19 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id LAA04663 for ; Mon, 4 May 1998 11:31:56 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA22344 for ; Mon, 4 May 1998 11:31:54 -0700 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA01792 for ; Mon, 4 May 1998 11:31:55 -0700 (PDT) Received: from orsmsx27.INTEL.COM (orsmsx27.jf.intel.com [192.168.74.27]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id LAA15399; Mon, 4 May 1998 11:45:45 -0700 (PDT) Received: by orsmsx27.jf.intel.com with Internet Mail Service (5.5.1960.3) id ; Mon, 4 May 1998 11:31:31 -0700 Message-ID: <3D33CF40366DD111AC4100A0C96B22AC015D53B4@FMSMSX34> From: "Patel, Baiju V" To: "'Stephen Kent'" , "'Steve Deering'" Cc: "'Theodore Y. Ts'o'" , "'Robert Elz'" , "'Thomas Narten'" , "'jis@MIT.EDU'" , "'ipsec@tis.com'" , "'ipng@sunroof.Eng.Sun.COM'" Subject: (IPng 5776) Re: [Karen Seo: Thomas Narten -- clarification, e tc.] Date: Mon, 4 May 1998 11:31:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Lets say that there is a large server on which it does not make sense to implement IPSEC. In that case, one would put a small dedicated device to do IPSEC transport mode for all the intranet use. It is not a gateway. The dedicated box is implementing IPSEC function on behalf of a single server (could be a coprocessor for a mainframe system for all I know). This I hope is legal and will suffer from the problems being discussed. Baiju -----Original Message----- From: owner-ipsec@ex.tis.com [mailto:owner-ipsec@ex.tis.com]On Behalf Of Stephen Kent Sent: Monday, May 04, 1998 6:27 AM To: Steve Deering Cc: Theodore Y. Ts'o; Robert Elz; Thomas Narten; jis@MIT.EDU; ipsec@tis.com; ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng 5759) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Steve >Gateways that insert an AH header into a passing IPv6 packet (architecturally >impure device that I hope no one is seriously advocating) will probably have >to treat an unrecognized header as a potential end-to-end header (e.g., >an unrecognized transport protocol header), and therefore will insert the >AH header before the unrecognized header and forward it onward, rather than >rejecting it. IPsec requires any security gateway to use tunnel mode for transit traffic, avoiding the problem you cite. Thus such an implementation would not only be "architectually impure," it also would be non-compliant. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 5 13:25:36 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id NAA06356 for ipng-dist; Tue, 5 May 1998 13:21:13 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with ESMTP id NAA06349 for ; Tue, 5 May 1998 13:21:08 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with ESMTP id NAA23066 for ; Tue, 5 May 1998 13:21:06 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id NAA28756 for ipng@sunroof.eng.sun.com; Tue, 5 May 1998 13:20:49 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id NAA06336 for ; Tue, 5 May 1998 13:19:46 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA02015 for ; Tue, 5 May 1998 13:19:42 -0700 Received: from MARENGO.BBN.COM (MARENGO.BBN.COM [128.89.6.82]) by earth.sun.com (8.8.8/8.8.8) with SMTP id NAA24361 for ; Tue, 5 May 1998 13:19:43 -0700 (PDT) Message-Id: <199805052019.NAA24361@earth.sun.com> Date: Tue, 5 May 98 16:10:28 EDT From: Karen Seo To: ipsec@tis.com, ipng@sunroof.eng.sun.com cc: kseo@BBN.COM Subject: (IPng 5778) Re: forward progress on IPSec AH Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ted, >>I think part of the confusion is caused by rather confusing terminology. >>There are Extensions (which are sometimes called options, I think >>incorrectly), as well as sets of individual options (taken from a >>different number space than the Extension headers) for the Hop by Hop >>and Destination options Extensions. As near as I can tell, calling the >>other extension headers "options" is a misnomer. Some extension headers >>are _optional_, but they should not be called _options_. :-) We mentioned this possible source of confusion in our message to you re: Thomas Narten's comments. >>Some of this confusion is in the AH spec, but I've seen it in other >>places as well. I think we will eventually want to clean up the text, >>before we go to draft standard, but I don't think we necessarily need to >>clear this up now. Hmmm...I thought we'd been pretty careful about this. Please let me know where in the AH text we have confused extension headers with either options or extension headers containing options (Hop-by-Hop and Destination). That should certainly get fixed. The above question is not aimed at your statement... "... since there's no good way to determine where the next header and header length fields were. (It would have been good if the location for next header and header-length were fixed for all non-terminal header, which apparently originally was a design goal, but several IPV6 folks have claimed that this is now a bad assumption to make.)" I understand your/other's point about this. Thanks, Karen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 5 13:52:44 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id NAA06399 for ipng-dist; Tue, 5 May 1998 13:45:10 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id NAA06392 for ; Tue, 5 May 1998 13:44:58 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA10142 for ; Tue, 5 May 1998 13:44:53 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by earth.sun.com (8.8.8/8.8.8) with SMTP id NAA10399 for ; Tue, 5 May 1998 13:44:39 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA11144; Tue, 5 May 98 16:44:36 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id QAA22046; Tue, 5 May 1998 16:44:36 -0400 Date: Tue, 5 May 1998 16:44:36 -0400 Message-Id: <199805052044.QAA22046@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Karen Seo Cc: ipsec@tis.com, ipng@sunroof.eng.sun.com, kseo@bbn.com In-Reply-To: Karen Seo's message of Tue, 5 May 98 16:10:28 EDT, <199805052019.QAA01506@relay.rv.tis.com> Subject: (IPng 5779) Re: forward progress on IPSec AH Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 5 May 98 16:10:28 EDT From: Karen Seo Hmmm...I thought we'd been pretty careful about this. Please let me know where in the AH text we have confused extension headers with either options or extension headers containing options (Hop-by-Hop and Destination). That should certainly get fixed. They really are minor nits, but since you asked, these were the ones which I was able to find: In section 4.1 of the security architecture document: ... In the case of AH, the protection is also extended to selected portions of the IP header (and options). For more details on the coverage afforded by AH, see the AH specification [KA98a]. "IP header (and options)" should probably read something like this "IP header, extension headers (IPV6), and options (IPV4/IPV6)". In section 3.3.3.1.2.2 Extension Headers -- Options: "The IPv6 extension headers (that are options)..." should probably read "that contain options", since the extension header isn't itself an option. This was one of the things which confused me until I read RFC 1883. I'd probably also change the section title to be "Extension Headers Containing Options". A similar change should probably be made to the following section, 3.3.3.1.2.3 Extension Headers -- non-Options. - Ted -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 6 11:04:38 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id KAA07991 for ipng-dist; Wed, 6 May 1998 10:59:02 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id KAA07984 for ; Wed, 6 May 1998 10:58:53 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA24895 for ; Wed, 6 May 1998 10:58:50 -0700 Received: from pimout2-int.prodigy.net (pimout2-ext.prodigy.net [207.115.59.113]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA01506 for ; Wed, 6 May 1998 10:58:51 -0700 (PDT) Received: from laptop.xmatrix.com (NYCMB204-13.splitrock.net [209.156.90.105]) by pimout2-int.prodigy.net (8.8.5/8.8.5) with SMTP id NAA06638 for ; Wed, 6 May 1998 13:55:20 -0400 Message-Id: <3.0.5.32.19980506135551.007b2100@mail.bettynet.com> X-Sender: pl@mail.bettynet.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Wed, 06 May 1998 13:55:51 -0400 To: ipng@sunroof.eng.sun.com From: Philippe Lourier Subject: (IPng 5781) ANN: Bob Hinden on Dr. Dobb's TechNetcast Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Hinden -no introduction necessary to readers of this list- will be the feature guest this week on Dr. Dobb's TechNetcast * Topic: IPv6 * When: Friday May 8, 3pm EST [stream also available on demand after live event] * Where: www.technetcast.com TechNetcast is interactive and you are encouraged to participate to help create an informative discussion about IPv6: * send advance questions to ddj@technetcast.com * join chat room during event * call-in during event (calls answered on the air) Please visit the website for details Thanks Philippe Lourier Dr. Dobb's TechNetcast www.technetcast.com ddj@technetcast.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 7 01:33:44 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id BAA08897 for ipng-dist; Thu, 7 May 1998 01:29:29 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id BAA08890 for ; Thu, 7 May 1998 01:29:16 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA08426 for ; Thu, 7 May 1998 01:29:16 -0700 Received: from ha1.rdc1.sfba.home.com (ha1.rdc1.sfba.home.com [24.0.0.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id BAA09506 for ; Thu, 7 May 1998 01:29:16 -0700 (PDT) Received: from c8-a.snvl1.sfba.home.com ([24.1.16.12]) by ha1.rdc1.sfba.home.com (Netscape Mail Server v2.02) with SMTP id AAA1438; Wed, 6 May 1998 22:01:55 -0700 Date: Thu, 7 May 98 04:47:51 GMT Daylight Time From: Ran Atkinson Subject: (IPng 5783) RE: [Karen Seo: Thomas Narten -- clarification, etc.] To: "Patel, Baiju V" Cc: "'ipng@sunroof.eng.sun.com'" , "'ipsec@tis.com'" , "'jis@MIT.EDU'" , "'Thomas Narten'" X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3D33CF40366DD111AC4100A0C96B22AC015D53AC@FMSMSX34> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Baiju, Tunnel-mode ESP does NOT provide the same security properties as AH. Wishing that it did and marketing it as if it did, doesn't make it true. Folks need to understand what security properties they desire, then use the appropriate mechanism(s) to provide those properties. Ran -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 7 20:27:46 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id UAA09786 for ipng-dist; Thu, 7 May 1998 20:21:36 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id UAA09779 for ; Thu, 7 May 1998 20:21:25 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA19185 for ; Thu, 7 May 1998 20:21:25 -0700 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id UAA12410 for ; Thu, 7 May 1998 20:21:11 -0700 (PDT) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.8+3.0Wbeta12/3.6W) with ESMTP id MAA24908 for ; Fri, 8 May 1998 12:20:30 +0900 (JST) To: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 5784) byteorder in advanced-api From: Jun-ichiro itojun Itoh Date: Fri, 08 May 1998 12:20:30 +0900 Message-ID: <24904.894597630@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, this is Jun-ichiro Itoh. Maybe I got confused, but I couldn't find a clue... In RFC2292 (Advanced API) section 3, we see the following text: > All data sent via raw sockets MUST be in network byte order and all > data received via raw sockets will be in network byte order. This > differs from the IPv4 raw sockets, which did not specify a byte > ordering and typically used the host's byte order. I believe cmsg_{len,level,type} are in host byte order. Does the "all data sent via raw sockets" covers cmsg_data[] too? To be more specific, what is the byteordering rule for in6_pktinfo.ipi6_ifindex? I believe it should be documented somewhere if we are going to revise RFC2292. Jun-ichiro itojun Itoh itojun@itojun.org itojun@iijlab.net -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 8 09:19:18 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id JAA10363 for ipng-dist; Fri, 8 May 1998 09:14:53 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with ESMTP id JAA10356 for ; Fri, 8 May 1998 09:14:47 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with ESMTP id JAA21140 for ; Fri, 8 May 1998 09:14:47 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA04365 for ipng@sunroof.eng.sun.com; Fri, 8 May 1998 09:14:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id IAA10316 for ; Fri, 8 May 1998 08:28:20 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA22678 for ; Fri, 8 May 1998 08:28:19 -0700 Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA19033 for ; Fri, 8 May 1998 08:28:20 -0700 (PDT) Received: from fmsmsx27.fm.intel.com (fmsmsx27.fm.intel.com [132.233.42.27]) by calliope1.fm.intel.com (8.8.6/8.8.5) with ESMTP id PAA21270; Fri, 8 May 1998 15:27:03 GMT Received: by FMSMSX27 with Internet Mail Service (5.5.1960.3) id ; Fri, 8 May 1998 08:27:02 -0700 Message-ID: <3D33CF40366DD111AC4100A0C96B22AC015D53DA@FMSMSX34> From: "Patel, Baiju V" To: "'Ran Atkinson'" Cc: "'ipng@sunroof.eng.sun.com'" , "'ipsec@tis.com'" , "'jis@MIT.EDU'" , "'Thomas Narten'" Subject: (IPng 5788) RE: [Karen Seo: Thomas Narten -- clarification, etc.] Date: Fri, 8 May 1998 08:27:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, sorry for being so naive but could you please point me to some reference material that articulates differences in security properties of the two so that I can use these two mechanisms appropriately. Thanks in advance -----Original Message----- From: owner-ipsec@ex.tis.com [mailto:owner-ipsec@ex.tis.com]On Behalf Of Ran Atkinson Sent: Wednesday, May 06, 1998 9:48 PM To: Patel, Baiju V Cc: 'ipng@sunroof.eng.sun.com'; 'ipsec@tis.com'; 'jis@MIT.EDU'; 'Thomas Narten' Subject: RE: [Karen Seo: Thomas Narten -- clarification, etc.] Baiju, Tunnel-mode ESP does NOT provide the same security properties as AH. Wishing that it did and marketing it as if it did, doesn't make it true. Folks need to understand what security properties they desire, then use the appropriate mechanism(s) to provide those properties. Ran -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 8 10:23:41 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id KAA10466 for ipng-dist; Fri, 8 May 1998 10:18:46 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id KAA10459 for ; Fri, 8 May 1998 10:18:33 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA19761 for ; Fri, 8 May 1998 10:18:31 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA25122 for ; Fri, 8 May 1998 10:18:32 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.7/8.6.10) with SMTP id KAA02480 for ; Fri, 8 May 1998 10:18:31 -0700 (PDT) Message-Id: <3.0.5.32.19980508101755.00a26c80@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 08 May 1998 10:17:55 -0700 To: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org (by way of Bob Hinden ) Subject: (IPng 5789) I-D ACTION:draft-ietf-diffserv-headers-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Definition of the Differentiated Services Field (DS Byte) in the IPv4 and IPv6 Headers Author(s) : K. Nichols, S. Blake Filename : draft-ietf-diffserv-headers-00.txt Pages : 11 Date : 07-May-98 Differentiated services are intended to provide scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. A variety of services may be built from a small, well-defined set of building blocks which are deployed in network nodes. The services may be either end-to-end or intra- domain. Services can be provided by a combination of: - setting bits in an IP header field at network edges and administrative boundaries, - using those bits to determine how packets are forwarded by the routers inside the network, and - conditioning the marked packets at network boundaries in accordance with the requirements or rules of each service. This document defines the IP header field, called the DS (for differentiated services) byte. In IPv4, it takes the place of the TOS octet; in IPv6, it takes the place of the Traffic Class octet. A differentiated services-capable network node includes a classifier that selects packets based on the value of the DS byte and is capable of delivering the specific packet forwarding treatment corresponding to that value. This document defines two packet forwarding treatments, or per-hop behaviors. Setting of the DS byte and other conditioning of the dynamic behavior of marked packets need only be performed at network boundaries and may vary in complexity. For a more complete understanding of differentiated services, this document should be read along with its companion documents, the differentiated services architecture [ARCH], the differentiated services framework [FWK], and other documents which specify additional per-hop behaviors, such as [Baker]. 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-diffserv-headers-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-diffserv-headers-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-headers-00.txt". NOTE: The mail server at ietf.org 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. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19980508125124.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-headers-00.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 8 12:22:14 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id MAA10593 for ipng-dist; Fri, 8 May 1998 12:17:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id MAA10586 for ; Fri, 8 May 1998 12:17:06 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA25973 for ; Fri, 8 May 1998 12:17:06 -0700 Received: from omega.uta.edu (omega.uta.edu [129.107.56.23]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA07336 for ; Fri, 8 May 1998 12:16:57 -0700 (PDT) Received: from localhost (sst2258@localhost) by omega.uta.edu (8.8.5/8.8.5) with SMTP id OAA31561 for ; Fri, 8 May 1998 14:16:52 -0500 (CDT) Date: Fri, 8 May 1998 14:16:52 -0500 (CDT) From: S Tadepalli To: ipng@sunroof.eng.sun.com Subject: (IPng 5790) Questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Can anyone please answer the following questions as soon as possible? Thank you for your help. 1. Can you tell me the advantages and disadvantages of IPv6's automatic configuration protocols, "plug-n-play" over the way it is done in IPv4? 2. Can you tell me a scheduling discipline I can use to implement all of IPv6's real-time support and tell me something of its advantages? 3. Can you tell me the potential strengths and weaknesses of the IPv6 nested header structure. If there is a weakness in this structure, can you propose an alternative? Thank you very much for your time and please have a nice day. Sriram -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 11 09:59:11 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id JAA14050 for ipng-dist; Mon, 11 May 1998 09:52:02 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with ESMTP id JAA14043 for ; Mon, 11 May 1998 09:51:48 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with ESMTP id JAA04007 for ; Mon, 11 May 1998 09:51:47 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA09399 for ipng@sunroof.eng.sun.com; Mon, 11 May 1998 09:51:22 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id JAA12669 for ; Sun, 10 May 1998 09:35:30 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA28525 for ; Sun, 10 May 1998 09:35:29 -0700 Received: from jis.ne.mediaone.net (jis.ne.mediaone.net [24.128.10.141]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA10759 for ; Sun, 10 May 1998 09:35:28 -0700 (PDT) Received: from mit.edu (localhost [127.0.0.1]) by jis.ne.mediaone.net (8.8.7/8.8.4) with ESMTP id MAA00507; Sun, 10 May 1998 12:35:14 -0400 Message-ID: <3555D742.22A88219@mit.edu> Date: Sun, 10 May 1998 12:35:14 -0400 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology X-Mailer: Mozilla 4.04 [en] (X11; U; Linux 2.0.30 i586) MIME-Version: 1.0 To: "Theodore Y. Ts'o" CC: Bill Sommerfeld , Stephen Kent , Steve Deering , Robert Elz , Thomas Narten , ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: (IPng 5796) Re: [Karen Seo: Thomas Narten -- clarification, etc.] References: <199805050450.AAA21748@dcl.MIT.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Of course one clever way of doing BITW is to have some cooperation from the host. Specifically the host puts in a skeletal AH header where it wants the real AH header to go and the bump finished the job. Presumably the reason you are using a BITW is because it has hardware encryption support and can do the processing more efficiently. -Jeff -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 12 13:57:54 1998 Received: by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) id NAA16186 for ipng-dist; Tue, 12 May 1998 13:52:40 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with SMTP id NAA16179 for ; Tue, 12 May 1998 13:52:29 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA17248 for ; Tue, 12 May 1998 13:52:29 -0700 Received: from snoopy.lucentmmit (smtp.Lucentmmit.com [38.160.171.35]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA11452 for ; Tue, 12 May 1998 13:52:25 -0700 (PDT) Received: by smtp.Lucentmmit.com with Internet Mail Service (5.5.1960.3) id ; Tue, 12 May 1998 17:07:32 -0400 Message-ID: <813D2854D1B0D111823600609717758103F3A3@smtp.Lucentmmit.com> From: "Conta, Alex" To: "'mankin@EAST.ISI.EDU'" , hinden@iprg.nokia.com, deering@cisco.com, jack@iclweb.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5799) RE: NLPID for IPv6 Date: Tue, 12 May 1998 17:07:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPv6 over Frame Relay I-D specifies the value of the NLPID = 0x8E to be used for IPv6 packets transmitted over Frame Relay networks. Alex > -----Original Message----- > From: owner-ipng@sunroof.Eng.Sun.COM > [mailto:owner-ipng@sunroof.Eng.Sun.COM] > Sent: Friday, May 01, 1998 10:38 AM > To: hinden@iprg.nokia.com; deering@cisco.com; jack@iclweb.com > Cc: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 5753) NLPID for IPv6 > > > Hi, > > There has been an NLPID assignment for IPv6 - 8E. > > Thank you to Jack Houldsworth. > > Allison > Liaison to SC6 > > --------- > From: jack@iclweb.com (Jack Holdsworth) > Subject: Re: Urgent! - Transport ECTP, RTP etc > Date: Fri, 1 May 1998 15:13:17 -0700 > Message-ID: <19980501141629.AAA3182@DEFAULT> > > I have just spoken to the SC6/WG7 chair (Alan Chambers) and > can confirm > that it is safe to go ahead and use Hexadecimal value 8E as > the NLPID value > for IPv6. This is agreed jointly by ISO/SC6 and ITU-T SG6. > He is quite > pleased that the IETF are interested in using it! > > If you need any more info, please let me know. > > Regards > > Jack Houldsworth > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 12 15:17:00 1998 Received: by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) id PAA00266 for ipng-dist; Tue, 12 May 1998 15:12:11 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with SMTP id OAA16312 for ; Tue, 12 May 1998 14:57:58 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA04341 for ; Tue, 12 May 1998 14:56:36 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA19346 for ; Tue, 12 May 1998 14:56:34 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.7/8.6.10) with SMTP id OAA26550; Tue, 12 May 1998 14:56:33 -0700 (PDT) Message-Id: <3.0.5.32.19980512145610.0094dbb0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 12 May 1998 14:56:10 -0700 To: ipng@sunroof.eng.sun.com, ipv6imp@munnari.OZ.AU From: Bob Hinden Subject: (IPng 5801) Implementation information Needed for ND and AddrConf Cc: hinden@iprg.nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have started collecting implementation information on IPv6 Neighbor Discovery and Stateless Address Autoconfiguration as part of moving these protocols to Draft Standard. If you have an implementation of these protocols please fill the out the following form and send it back to me. I will make the information available to the IESG. Thanks in advance, Bob ---------------------------------------------------------- Neighbor Discovery for IP Version 6 (IPv6) IPv6 Stateless Address Autoconfiguration Name of Implementation: Platform: Organization: Origin of Code: Features Implemented: Router Solicitations Router Advertisements Neighbor Solicitations Neighbor Advertisements Neighbor Unreachability Detection Redirects RA Prefix Information Option Tested Interoperability by Feature: Router Solicitations Router Advertisements Neighbor Solicitations Neighbor Advertisements Neighbor Unreachability Detection Redirects RA Prefix Information Option Information from: -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 13 08:38:28 1998 Received: by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) id IAA01657 for ipng-dist; Wed, 13 May 1998 08:35:11 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with SMTP id IAA01650 for ; Wed, 13 May 1998 08:35:02 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA20357 for ; Wed, 13 May 1998 08:35:03 -0700 Received: from mti6000.zfm.com (mti6000.zfm.com [206.0.67.254]) by earth.sun.com (8.8.8/8.8.8) with SMTP id IAA27680 for ; Wed, 13 May 1998 08:34:58 -0700 (PDT) Received: from mtint.zfm.com by mti6000.zfm.com with smtp (Smail3.1.28.1 #4) id m0yZdKE-0004LoC; Wed, 13 May 98 12:20 GRNLNDST Received: by MTINT with Internet Mail Service (5.0.1458.49) id ; Wed, 13 May 1998 12:34:20 -0300 Message-ID: <5D4FD0036882D011A9400060940A770D03656E@MTINT> From: Alberto Abudara To: "'ipng@sunroof.Eng.Sun.COM'" Subject: (IPng 5803) Ping6 Date: Wed, 13 May 1998 12:34:19 -0300 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We installed a small network with 3 computers. First, we installed IPv4 and every machine could see the others. Then we installed IPv6 and tried to ping each other but we could only ping the addresses with this format ::x.x.x.x but could not ping the IPv6 address that was made with the MAC address. Is this because we have the two protocols installed ? Can somebody help me ? Regards, ------------------------------------------------------------------------ ------------------------ Alberto Abudara Montevideo, URUGUAY - South America Montevideo Teleport International, ZONA FRANCA DE MONTEVIDEO RUTA 8 Km 17.500 Loc. 123 email: aabudara@zfm.com voice +598 982 2000 x 5728 fax +598 982 2000 x 5274 ------------------------------------------------------------------------ -------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 13 08:58:16 1998 Received: by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) id IAA01678 for ipng-dist; Wed, 13 May 1998 08:52:09 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with SMTP id IAA01671 for ; Wed, 13 May 1998 08:52:00 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA24932 for ; Wed, 13 May 1998 08:52:00 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA10145 for ; Wed, 13 May 1998 08:51:58 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.7/8.6.10) with SMTP id IAA17641; Wed, 13 May 1998 08:51:57 -0700 (PDT) Message-Id: <3.0.5.32.19980513085141.00b019f0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 13 May 1998 08:51:41 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 5804) Neighbor Discovery and Auto Configuration Implementation Reports Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The implementation report for: Neighbor Discovery for IP Version 6 (IPv6) IPv6 Stateless Address Autoconfiguration can be found at: ftp://playground.sun.com/pub/ipng/implementation-reports/ as nd-auto-implementations.txt As I get more reports I will add them. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 13 09:44:56 1998 Received: by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) id JAA01734 for ipng-dist; Wed, 13 May 1998 09:40:08 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with SMTP id JAA01727 for ; Wed, 13 May 1998 09:39:55 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA08948 for ; Wed, 13 May 1998 09:39:55 -0700 Received: from cookson.iclweb.com (cookson.iclnet.co.uk [194.176.194.192]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA13064 for ; Wed, 13 May 1998 09:39:53 -0700 (PDT) Received: from DEFAULT ([194.176.196.201]) by cookson.iclweb.com (Netscape Mail Server v2.0) with ESMTP id AAA2903; Wed, 13 May 1998 17:39:45 +0100 From: jack@iclweb.com (Jack Holdsworth) To: "Conta, Alex" , "'mankin@EAST.ISI.EDU'" , , Cc: Subject: (IPng 5806) Re: NLPID for IPv6 Date: Wed, 13 May 1998 17:34:14 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <19980513163942.AAA2903@DEFAULT> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 0x8E is correct to be totally specific. Jack Houldsworth ---------- > From: Conta, Alex > To: 'mankin@EAST.ISI.EDU'; hinden@iprg.nokia.com; deering@cisco.com; jack@iclweb.com > Cc: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 5799) RE: NLPID for IPv6 > Date: Tuesday, May 12, 1998 2:07 PM > > > The IPv6 over Frame Relay I-D specifies > the value > of the NLPID = 0x8E to be used for IPv6 packets transmitted over Frame > Relay networks. > > Alex > > > -----Original Message----- > > From: owner-ipng@sunroof.Eng.Sun.COM > > [mailto:owner-ipng@sunroof.Eng.Sun.COM] > > Sent: Friday, May 01, 1998 10:38 AM > > To: hinden@iprg.nokia.com; deering@cisco.com; jack@iclweb.com > > Cc: ipng@sunroof.Eng.Sun.COM > > Subject: (IPng 5753) NLPID for IPv6 > > > > > > Hi, > > > > There has been an NLPID assignment for IPv6 - 8E. > > > > Thank you to Jack Houldsworth. > > > > Allison > > Liaison to SC6 > > > > --------- > > From: jack@iclweb.com (Jack Holdsworth) > > Subject: Re: Urgent! - Transport ECTP, RTP etc > > Date: Fri, 1 May 1998 15:13:17 -0700 > > Message-ID: <19980501141629.AAA3182@DEFAULT> > > > > I have just spoken to the SC6/WG7 chair (Alan Chambers) and > > can confirm > > that it is safe to go ahead and use Hexadecimal value 8E as > > the NLPID value > > for IPv6. This is agreed jointly by ISO/SC6 and ITU-T SG6. > > He is quite > > pleased that the IETF are interested in using it! > > > > If you need any more info, please let me know. > > > > Regards > > > > Jack Houldsworth > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 13 10:54:27 1998 Received: by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) id KAA01940 for ipng-dist; Wed, 13 May 1998 10:50:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with SMTP id KAA01933 for ; Wed, 13 May 1998 10:50:27 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA01350 for ; Wed, 13 May 1998 10:50:27 -0700 Received: from mti6000.zfm.com (mti6000.zfm.com [206.0.67.254]) by earth.sun.com (8.8.8/8.8.8) with SMTP id KAA02211 for ; Wed, 13 May 1998 10:50:18 -0700 (PDT) Received: from mtint.zfm.com by mti6000.zfm.com with smtp (Smail3.1.28.1 #4) id m0yZfQ1-0004LqC; Wed, 13 May 98 14:34 GRNLNDST Received: by MTINT with Internet Mail Service (5.0.1458.49) id ; Wed, 13 May 1998 14:48:27 -0300 Message-ID: <5D4FD0036882D011A9400060940A770D036571@MTINT> From: Alberto Abudara To: "'Richard Draves'" , "'ipng@sunroof.Eng.Sun.COM'" , "'MSRIPV6-USERS@LIST.RESEARCH.MICROSOFT.COM'" Subject: (IPng 5807) Ping6 Date: Wed, 13 May 1998 14:48:25 -0300 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > We installed a small network with 3 computers. First, we installed > IPv4 and every machine could see the others. Then we installed IPv6 > and tried to ping each other but we could only ping the addresses with > this format ::x.x.x.x but could not ping the IPv6 address that was > made with the MAC address. Is this because we have the two protocols > installed ? > Can somebody help me ? > One of the IPv4 addresses was : 192.168.11.103 and when we display the ipv6 information of the interfaces we have the following information : i4 : link level address 48:54:e8:29:5c:49 peferred address fe80::4a54:e8ff:fe29:5c49/10 i3: link level 192.168.11.103 pref: :: c0a8:bc7/10 i2 link level : 0.0.0.0 pref ::192.168.11.103 / 96 I dont have the info about i1. The number after the / is the mask, isn't it ? When we ping ::192.168.11.103 we see the other machine because it encapsulates IPv6 in IPv4 packets ? Because when we ping fe80::4a54...... or ::caa8.... we cant see the other machine. Are we doing something wrong ? > > Regards, > > ---------------------------------------------------------------------- > -------------------------- > Alberto Abudara > Montevideo, URUGUAY - South America > Montevideo Teleport International, > ZONA FRANCA DE MONTEVIDEO > RUTA 8 Km 17.500 Loc. 123 > email: aabudara@zfm.com > voice +598 982 2000 x 5728 > fax +598 982 2000 x 5274 > ---------------------------------------------------------------------- > ---------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 13 11:27:59 1998 Received: by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) id LAA02011 for ipng-dist; Wed, 13 May 1998 11:24:10 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with SMTP id LAA02004 for ; Wed, 13 May 1998 11:23:53 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA12701 for ; Wed, 13 May 1998 11:23:54 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA26395 for ; Wed, 13 May 1998 11:23:51 -0700 (PDT) From: Masataka Ohta Message-Id: <199805131815.DAA08621@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id DAA08621; Thu, 14 May 1998 03:15:24 +0900 Subject: (IPng 5808) Re: Last Call: Internet Protocol, Version 6 (IPv6) to Draft Standard To: iesg-secretary@ietf.org (The IESG) Date: Thu, 14 May 98 3:15:23 JST Cc: IETF-Announce:;;;;@necom830.hpcl.titech.ac.jp;;;, ipng@sunroof.eng.sun.com In-Reply-To: <199805051055.GAA01887@ietf.org>; from "The IESG" at May 5, 98 6:55 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The IESG has received a request from the IPNG Working Group to consider the following as Draft Standards: > > > o Internet Protocol, Version 6 (IPv6) Specification > replacing RFC 1883, currently > a Proposed Standard. I'm agaist the promotion because: 1) The change on minimal MTU is significant to worth it be a proposed standard again. 2) The current specification does not limit the length of the header. 1) is a procedural problem, which may be technically ignored. On the other and,, technically speaking, 2) is a fatal problem. However, there seems to be a persistent confusion in IPNG WG that the problem could have been solved by fragmentation. The problem 2) is that, even though there are some non-TCP protocols such as DNS over UDP which needs a standard on smallest payload size, which is not given by IPv6. With IPv4, reassembly buffer is assured to be 576 byte long and headers are, at most, 64 byte long, which means 512 bytes of payload data can be safely transmitted betweeen IPv4 networks and a sender. To make the network more active, however, even though the size of the reassembly buffer of IPv6 Worse, the kernel may insert some header unknown to the applications. The solution to the problem is to limit the maximum header length, which should be considerablely smaller than the size of the reassembly buffer. For example, it is acceptable to make the minimum size of reassembly buffer 4096 bytes and the maximum header size 512 bytes, which keep enough room for, say, tunneling. Or, if the maximum header size is 768 bytes long, hosts which are unaware of PMTUD can just send 512 bytes of data packet (along with at most 768 byte-long header), without introduction the fragmentation header. Masataka Ohta Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 13 12:48:19 1998 Received: by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) id MAA02175 for ipng-dist; Wed, 13 May 1998 12:45:04 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with SMTP id MAA02168 for ; Wed, 13 May 1998 12:44:56 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA05506 for ; Wed, 13 May 1998 12:44:57 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA24522 for ; Wed, 13 May 1998 12:44:53 -0700 (PDT) Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail11.digital.com (8.8.8/8.8.8/WV1.0e) with SMTP id PAA22840 for ; Wed, 13 May 1998 15:44:52 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA25865; Wed, 13 May 1998 15:44:51 -0400 Message-Id: <199805131944.AA25865@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5809) Take Two: API sockaddr_in6 Update Discussion Date: Wed, 13 May 1998 15:44:51 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, If we can nail this down Richard Stevens and I are ready to start writing and filling in the new text. We will add boxes, etc for all this. What I suggest below causes a change to any existing implementation and I have more below for ipv6_mreq leaving us too. I believe this needs to be the last major change for awhile. But this is needed. See the "Also" breaks below too. Can we hear from folks please. struct sockaddr_in6 { uint8_t sin6_len; sa_family_t sin6_family; in_port_t sin6_port; uint32_t sin6_scope_id; uint32_t sin6_ifindex; uint32_t sin6_flowinfo; struct in6_addr sin6_addr; }; sin6_scope_id: unsigned 32 bit integer value identifying an interface or set of interfaces as appropriate for the scope of the address carried in the sin6_addr field. For a link scope sin6_addr, sin6_scope_id would be an interface index. For a site scope sin6_addr, sin6_scope_id would be a site identifier. The mapping from sin6_scope_id to an interface or set of interfaces is left to the implementation. sin6_ifindex: unsigned 32 bit integer value containing the interface index of the interface a packet will be sent or was received on. Also: There is no more reason for ipv6_mreq in IPv6. For setsockopt and getsockopt multicast options: sin6_addr and sin6_ifindex can now be used. ipv6_mreq should be removed from the spec. Also: There is no more reason to carry: unsigned int ipi6_ifindex; /* send/recv interface index */ in ipv6_pktinfo in the Advanced API. sin6_interface can be used and permits send/sendto and recv/recvfrom APIs to also use sin6_ifindex for system applications and ancillary data is not required via sendmsg/recvmsg for these applications that only need knowledge of interfaces. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 13 14:48:31 1998 Received: by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) id OAA02366 for ipng-dist; Wed, 13 May 1998 14:43:24 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with SMTP id OAA02359 for ; Wed, 13 May 1998 14:43:15 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA08836 for ; Wed, 13 May 1998 14:43:15 -0700 Received: from wizard.gsfc.nasa.gov (wizard.gsfc.nasa.gov [128.183.115.17]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA22406 for ; Wed, 13 May 1998 14:43:14 -0700 (PDT) Received: (from bill@localhost) by wizard.gsfc.nasa.gov (8.8.7/8.8.7) id RAA07671; Wed, 13 May 1998 17:41:15 -0400 (EDT) From: Bill Fink Message-Id: <199805132141.RAA07671@wizard.gsfc.nasa.gov> Subject: (IPng 5810) Re: Last Call: Internet Protocol, Version 6 (IPv6) Specification To: iesg@ietf.org Date: Wed, 13 May 1998 17:41:15 -0400 (EDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199805051055.GAA01887@ietf.org> from "The IESG" at May 5, 98 06:55:47 am 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 > The IESG has received a request from the IPNG Working Group to consider the following as Draft Standards: > > o Internet Control Message Protocol (ICMPv6) for the Internet Protocol > Version 6 (IPv6) Specification > replacing RFC 1885, currently a Proposed Standard The following paragraph in section 3.3 was removed from RFC 1885, and needs to be reinstated to make it clear that the interface on which packet forwarding fails when generating an ICMP Time Exceeded error message SHOULD be the interface on which the packet was received: "The router sending an ICMPv6 Time Exceeded message with Code 0 SHOULD consider the receiving interface of the packet as the interface on which the packet forwarding failed in following rule (d) for selecting the Source Address of the message." Note there was also a typo in the above quoted portion of RFC 1885. The reference to rule (d) should actually be a reference to rule (c). This is required because many IPv4 implementations actually do this incorrectly, owing to the ambiguity of the phrase "the interface on which the packet forwarding failed" in rule (c) of section 2.2, and this can lead to an arbitrary use of either the receiving or next outgoing interface for the source address of the ICMP error packet. This in turn can reduce the effectiveness of the traceroute diagnostic tool. I had originally argued that the SHOULD should be a MUST to eliminate any doubt, but at least the SHOULD text needs to be reinstated to remove the current ambiguity in the new ID. -Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 14 19:10:02 1998 Received: by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) id TAA04461 for ipng-dist; Thu, 14 May 1998 19:04:28 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with SMTP id TAA04454 for ; Thu, 14 May 1998 19:04:19 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA18330 for ; Thu, 14 May 1998 19:04:22 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id TAA04831 for ; Thu, 14 May 1998 19:04:20 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.7/8.6.10) with SMTP id TAA11505; Thu, 14 May 1998 19:04:18 -0700 (PDT) Message-Id: <3.0.5.32.19980514190347.00936800@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 14 May 1998 19:03:47 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 5812) New version of "Proposed TLA and NLA Assignment Rules" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new version of the "Proposed TLA and NLA Assignment Rules" draft was submitted to be an internet draft. It includes the changes discussed at the last IETF meeting. For anyone interested in can be found at: ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-tla-assignment-03.txt It will be discussed at next week's RIPE meeting. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 18 07:10:16 1998 Received: by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) id HAA07729 for ipng-dist; Mon, 18 May 1998 07:04:09 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with SMTP id HAA07720 for ; Mon, 18 May 1998 07:03:53 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA22976 for ; Mon, 18 May 1998 07:03:53 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA21692 for ; Mon, 18 May 1998 07:03:50 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA23177; Mon, 18 May 1998 10:03:46 -0400 (EDT) Message-Id: <199805181403.KAA23177@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@CNRI.Reston.VA.US; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 5815) I-D ACTION:draft-ietf-ipngwg-tla-assignment-03.txt Date: Mon, 18 May 1998 10:03:45 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Proposed TLA and NLA Assignment Rules Author(s) : B. Hinden Filename : draft-ietf-ipngwg-tla-assignment-03.txt Pages : 8 Date : 15-May-98 This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as defined in [AGGR]. These proposed rules apply to registries allocating TLA ID's and to organizations receiving TLA ID's. This proposal is intended as input from the IPng working group to the IANA and Registries. It is not intended for any official IETF status. 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-tla-assignment-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-tla-assignment-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-tla-assignment-03.txt". NOTE: The mail server at ietf.org 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. 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@ietf.org" Content-Type: text/plain Content-ID: <19980515105756.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-tla-assignment-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-tla-assignment-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980515105756.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 18 11:19:45 1998 Received: by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) id LAA08045 for ipng-dist; Mon, 18 May 1998 11:13:40 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with ESMTP id LAA08038 for ; Mon, 18 May 1998 11:13:35 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with ESMTP id LAA09602 for ; Mon, 18 May 1998 11:13:34 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id LAA05863 for ipng@sunroof.eng.sun.com; Mon, 18 May 1998 11:13:10 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with SMTP id LAA08025 for ; Mon, 18 May 1998 11:09:23 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA02975 for ; Mon, 18 May 1998 11:09:25 -0700 Received: from doorstep.unety.net (ns.unety.net [207.32.128.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id LAA20368 for ; Mon, 18 May 1998 11:09:21 -0700 (PDT) Received: from webster.unir.net ([207.32.159.5]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id NAA08089; Mon, 18 May 1998 13:09:13 -0500 Received: by webster.unir.net with Microsoft Mail id <01BD825D.61DA2E60@webster.unir.net>; Mon, 18 May 1998 13:03:42 -0500 Message-ID: <01BD825D.61DA2E60@webster.unir.net> From: Jim Fleming To: "mikec@twiddle.com" , "'Bob Fink'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 5817) RE: IPv6 Question Date: Mon, 18 May 1998 13:03:40 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Monday, May 18, 1998 9:34 AM, Bob Fink[SMTP:rlfink@lbl.gov] wrote: @Mike, @ @At 02:59 PM 5/18/98 +0200, Mike Crawfurd wrote: @>Hello People, @> @>I've read many papers about IPv6, but I want to know how IPv6 implements @>the private space addresses. @> @>Some of CMG's clients are running out of private Address space. How does @>IPv6 solve this problem ? @ @There is no private address space defined for IPv6, nor does there need to be (so seems to me). There is site local addressing, but that is only useful if your "private space" needs span only one site and you have no external/wide-area ISP connectivity. @ @However, I don't see why you need private space at all with IPv6 given the very large address size, as you will need a wide area service to talk to the outside anyway, and thus you automatically have an address space that is more than generous. @ @ @As an aside, you should take this kind of question to the IPng mailer (ipng@sunroof.eng.sun.com). @ For completeness, the following RFC 1918 IPv4 address ranges play a key role in the IPv8 0:0.x.x.x.x address space. User - DHCP Sub-Nets - 0:0.10.x.x.x Group - ISP Infrastructure - 0:0.172.16.0.0-0:0.172.31.0.0 World - Inter-ISP Links and Services - 0:0.192.168.1.x-0:0.192.168.254.x The 43 bit IPv8 addresses of course fit inside of the 128 bit IPv6 address fields. The various IPv8 Address Management Authorities can make their own policies about spaces such as G:S.10.x.x.x. and the other RFC 1918 spaces. http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt - Jim Fleming Unir Corporation - http://www.unir.net IPv8 - Designed for the Rest of the Human Race AM Radio Stations ---> http://www.DOT.AM -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 19 10:12:43 1998 Received: by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) id KAA08720 for ipng-dist; Tue, 19 May 1998 10:07:23 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with ESMTP id KAA08713 for ; Tue, 19 May 1998 10:07:18 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with ESMTP id KAA03296 for ; Tue, 19 May 1998 10:07:18 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id KAA01662 for ipng@sunroof.eng.sun.com; Tue, 19 May 1998 10:06:50 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with SMTP id AAA08511 for ; Tue, 19 May 1998 00:03:56 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id AAA26281 for ; Tue, 19 May 1998 00:04:01 -0700 Received: from atcmpg.ATComputing.nl (ns.ATComputing.nl [195.108.229.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id AAA28918 for ; Tue, 19 May 1998 00:03:55 -0700 (PDT) Received: from ATComputing.nl (john@localhost) by atcmpg.ATComputing.nl (8.8.5/8.8.5) with ESMTP id JAA01756 for ; Tue, 19 May 1998 09:03:54 +0200 (MET DST) Message-Id: <199805190703.JAA01756@atcmpg.ATComputing.nl> To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 5819) Re: IPv6 Question In-reply-to: Your message of "Mon, 18 May 1998 13:03:40 CDT." <01BD825D.61DA2E60@webster.unir.net> Date: Tue, 19 May 1998 09:03:53 +0200 From: John van Krieken Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <01BD825D.61DA2E60@webster.unir.net>, Jim Fleming writes: > On Monday, May 18, 1998 9:34 AM, Bob Fink[SMTP:rlfink@lbl.gov] wrote: > @Mike, > @ > @At 02:59 PM 5/18/98 +0200, Mike Crawfurd wrote: > @>Hello People, > @> > @>I've read many papers about IPv6, but I want to know how IPv6 implements > @>the private space addresses. > @> > @>Some of CMG's clients are running out of private Address space. How does > @>IPv6 solve this problem ? > @ > @There is no private address space defined for IPv6, nor does there need to > be (so seems to me). There is site local addressing, but that is only > useful if your "private space" needs span only one site and you have no > external/wide-area ISP connectivity. I would like to see an answer to the question as well. Why can't site local adresses be used when you actually acquire ISP connectivity. The adress spaces (Link Local/Site/Global) easily recognized. So why shouldn't a host trying to connect to a host on site get a site local adress from it's internal nameserver and select a site local prefix to use? If on the other hand the host ask for the IPv6-adddress from some other site's external DSN server it should get a global adress and use/aquire on the spot it's own global adress. I have seen at least one implementation actually attempting to do just that. Having site local connections for all your internal host will in fact render them impervious to the woos of host renumbering (which is a snap in IPv6 of course, but your internal number can have much largel valid times then those from your old ISP :-) ). --------------------------------- John van Krieken, AT Computing BV, 024-3527242 john@ATComputing.nl, http://www.ATComputing.nl/images/pasfotos/john.gif -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 19 13:38:44 1998 Received: by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) id NAA09008 for ipng-dist; Tue, 19 May 1998 13:34:13 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with ESMTP id NAA09001 for ; Tue, 19 May 1998 13:33:57 -0700 (PDT) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with SMTP id NAA01752; Tue, 19 May 1998 13:33:54 -0700 (PDT) Date: Tue, 19 May 1998 13:33:54 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5820) Re: Take Two: API sockaddr_in6 Update Discussion To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199805131944.AA25865@wasted.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > sin6_scope_id: unsigned 32 bit integer value identifying an > interface or set of interfaces as appropriate for the scope of the > address carried in the sin6_addr field. For a link scope sin6_addr, > sin6_scope_id would be an interface index. For a site scope > sin6_addr, sin6_scope_id would be a site identifier. The > mapping from sin6_scope_id to an interface or set of > interfaces is left to the implementation. Fine. Presumable you need to say that zero means "unspecified" so that applications that don't care would just set sin6_scope_id to zero. Also, I assume "link scope" means "link-local unicast address or link scope multicast address" and similarely for "site scope" i.e. the specification applies to both multicast and unicast. > sin6_ifindex: unsigned 32 bit integer value containing the > interface index of the interface a packet will be sent or > was received on. Why do we need this given sin6_scope_id? While there might be some applications that need to specify outgoing interfaces for non link local addresses I think such applications can use the advanced API support since they are trying to do something more unusual. If you have two fields then the specification would presumably have to state which one takes precendence when both are set as well as the rules when destination is site local sin6_scope_id says site "A" sin6_ifindex is an interface that does not belong to site "A". Thus I'd strongly suggest not adding sin6_ifindex and instead keeping simple with just sin6_scope_id. > There is no more reason for ipv6_mreq in IPv6. For setsockopt and > getsockopt multicast options: > > sin6_addr and sin6_ifindex > > can now be used. ipv6_mreq should be removed from the spec. This assumes we want sin6_ifindex. > There is no more reason to carry: > > unsigned int ipi6_ifindex; /* send/recv interface index */ > > in ipv6_pktinfo in the Advanced API. sin6_interface can be used > and permits send/sendto and recv/recvfrom APIs to also use sin6_ifindex > for system applications and ancillary data is not required via > sendmsg/recvmsg for these applications that only need knowledge of > interfaces. I'd argue to keep this in the advanced API for "advanced" applications and only have sin6_scope_id for the basic support of - multihomed nodes with applications using link-local addresses - "multisited" nodes with applications using site-local addresses Being able to arbitrarely control the sending interface is a feature not needed for those two cases. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 19 18:56:53 1998 Received: by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) id SAA09521 for ipng-dist; Tue, 19 May 1998 18:51:29 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with SMTP id SAA09514 for ; Tue, 19 May 1998 18:51:18 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA19562 for ; Tue, 19 May 1998 18:51:22 -0700 Received: from crcg.edu ([205.245.135.125]) by earth.sun.com (8.8.8/8.8.8) with SMTP id SAA09055 for ; Tue, 19 May 1998 18:51:18 -0700 (PDT) Received: from phoenix by crcg.edu (SMI-8.6/SMI-SVR4) id VAA10810; Tue, 19 May 1998 21:57:18 -0400 Message-ID: <356237A8.FCE148BC@crcg.edu> Date: Tue, 19 May 1998 21:53:45 -0400 From: Murat Goekdemir Organization: CRCG X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: "6bone@ISI.EDU" <6bone@ISI.EDU>, "ipng@sunroof.Eng.Sun.COM" Subject: (IPng 5821) traffic generator for Digital Unix X-Priority: 3 (Normal) Content-Type: multipart/mixed; boundary="------------904475A723C5834B37AF8C37" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------904475A723C5834B37AF8C37 Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi folks, i am currently working on my thesis and i need a traffic generator and other analyzing tools for Digital Unix IPv6 spec. Does anybody know if some tools are available ? And i would really like to know how far the implementation of IPv6 over ATM is. Are there some other information materials, except the draft-ietf-ion-ipv6-atm-02 ? If this is off topic here, I apologize. thanks Murat Goekdemir --------------904475A723C5834B37AF8C37 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Murat Goekdemir Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Murat Goekdemir n: Goekdemir;Murat org: Fraunhofer Center for Research in Computer Graphics adr: 321 South Main Street;;;Providence;Rhode Island;02903;USA email;internet: mgoeydem@crcg.edu tel;work: +1 401 453 63 63 xx 107 tel;fax: +1 401 453 0444 x-mozilla-cpt: ;0 x-mozilla-html: FALSE end: vcard --------------904475A723C5834B37AF8C37-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 19 20:26:59 1998 Received: by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) id UAA09568 for ipng-dist; Tue, 19 May 1998 20:24:14 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0.Gamma0+Sun/8.9.0.Gamma0) with SMTP id UAA09561 for ; Tue, 19 May 1998 20:24:06 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA00786 for ; Tue, 19 May 1998 20:24:09 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id UAA13348 for ; Tue, 19 May 1998 20:24:06 -0700 (PDT) Received: from death.mentat.com ([192.88.122.121]) by mentat.com (4.1/SMI-4.1) id AA11902; Tue, 19 May 98 20:23:57 PDT Received: by death.mentat.com (SMI-8.6/SMI-SVR4) id UAA14660; Tue, 19 May 1998 20:27:39 -0700 Date: Tue, 19 May 1998 20:27:39 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199805200327.UAA14660@death.mentat.com> To: Erik.Nordmark@Eng Subject: (IPng 5822) Re: Take Two: API sockaddr_in6 Update Discussion Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > Thus I'd strongly suggest not adding sin6_ifindex and instead keeping > simple with just sin6_scope_id. > I agree with this. > > I'd argue to keep this in the advanced API for "advanced" applications > and only have sin6_scope_id for the basic support of > - multihomed nodes with applications using link-local addresses > - "multisited" nodes with applications using site-local addresses > > Being able to arbitrarely control the sending interface is a feature not > needed for those two cases. > I agree with this as well. I would prefer not to have every application pay a performance and/or com- plexity penalty to save a few advance applications from have to deal with ancillary data. In fact, it is not clear that advanced applications will be able to do without ancillary data because many of them will still need to know the destination address of the datagram. This can only be had by receiving the IPV6_PKTINFO ancillary data item. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 20 08:48:50 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id IAA10110 for ipng-dist; Wed, 20 May 1998 08:45:44 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id IAA10103 for ; Wed, 20 May 1998 08:45:35 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA16258; Wed, 20 May 1998 08:45:38 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA13550; Wed, 20 May 1998 08:45:33 -0700 (PDT) Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail11.digital.com (8.8.8/8.8.8/WV1.0e) with SMTP id LAA18751; Wed, 20 May 1998 11:45:31 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA01661; Wed, 20 May 1998 11:45:26 -0400 Message-Id: <199805201545.AA01661@wasted.zk3.dec.com> To: Erik Nordmark Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 5823) Re: Take Two: API sockaddr_in6 Update Discussion In-Reply-To: Your message of "Tue, 19 May 1998 13:33:54 PDT." Date: Wed, 20 May 1998 11:45:26 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, We will take your input into consideration so far I have only heard two "developers" and vendors (you being the other) not believe we need sin6_ifindex. I would argue that new IPv6 applications that are interesting will use the sin6_ifindex more than the sin6_scope_id actually. If we are going to break existing implementations for scope thingees which no one can define a use for then I think biting the bullet and avoiding the index use in the advanced API and getting rid of the ipv6_mreq structure is too. If the issue is that folks don't want to break their code base then say that and not wiggle and worm about adding this index. Because if breaking applications now is the issue it should apply to other specifications and be the norm now for IPv6, not just for the API. thanks for your many inputs on the API, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 20 09:15:41 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id JAA10168 for ipng-dist; Wed, 20 May 1998 09:10:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id JAA10161 for ; Wed, 20 May 1998 09:10:11 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA22171; Wed, 20 May 1998 09:10:13 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA00421; Wed, 20 May 1998 09:10:06 -0700 (PDT) Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail11.digital.com (8.8.8/8.8.8/WV1.0e) with SMTP id MAA26429; Wed, 20 May 1998 12:10:05 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA04752; Wed, 20 May 1998 12:09:56 -0400 Message-Id: <199805201609.AA04752@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 5824) Re: Take Two: API sockaddr_in6 Update Discussion In-Reply-To: Your message of "Tue, 19 May 1998 20:27:39 PDT." <199805200327.UAA14660@death.mentat.com> Date: Wed, 20 May 1998 12:09:56 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, Just take my response I sent to Erik as a reply to you too. We will take your input as Erik's (your only number 2 with the issue onn this list). I am not sure now which way it should go but I don't buy your performance penalty argument. In fact if the index is in the socket structure for many of us with BSD kernels it is a performance win. All have performance penalty using ancillary data and it creates complexity for the programmer of IPv6 tomorrow too who just wants to use the interface for new IPv6 multihome applications.. But if the issue is it breaks your code please state that issue too. thanks for your input on this API discussion, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 20 10:41:34 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id KAA10294 for ipng-dist; Wed, 20 May 1998 10:36:58 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id KAA10287 for ; Wed, 20 May 1998 10:36:49 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA20755 for ; Wed, 20 May 1998 10:36:53 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id KAA27677 for ; Wed, 20 May 1998 10:36:47 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA18036; Wed, 20 May 98 10:36:37 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id KAA09883; Wed, 20 May 1998 10:38:27 -0700 Date: Wed, 20 May 1998 10:38:27 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199805201738.KAA09883@feller.mentat.com> To: bound@zk3.dec.com Subject: (IPng 5825) Re: Take Two: API sockaddr_in6 Update Discussion Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > We will take your input as Erik's (your only number 2 with the issue onn > this list). > That is true. I have heard no one support your proposal. > I am not sure now which way it should go but I don't buy your > performance penalty argument. In fact if the index is in the socket > structure for many of us with BSD kernels it is a performance win. > Fine. If it not a problem for your code then you are lucky. > All have performance penalty using ancillary data and it creates > complexity for the programmer of IPv6 tomorrow too who just wants to use > the interface for new IPv6 multihome applications.. > The problem is that a lot of these applications will need to use ancillary data anyway because they will need to know the destination address of the datagram. So where is the savings? > But if the issue is it breaks your code please state that issue too. > It does break my code. > > If the issue is that folks don't want to break their code base then say > that and not wiggle and worm about adding this index. Because if > breaking applications now is the issue it should apply to other > specifications and be the norm now for IPv6, not just for the API. > Is this a veiled threat to hold up other changes to other documents if you don't get your way? If so then it should be unveiled. Remember that the API documents are informational. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 20 11:26:40 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id LAA10331 for ipng-dist; Wed, 20 May 1998 11:20:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id LAA10324 for ; Wed, 20 May 1998 11:20:11 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA05656 for ; Wed, 20 May 1998 11:20:14 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA23995 for ; Wed, 20 May 1998 11:20:08 -0700 (PDT) Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail11.digital.com (8.8.8/8.8.8/WV1.0e) with SMTP id OAA27370; Wed, 20 May 1998 14:16:50 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA24787; Wed, 20 May 1998 14:16:49 -0400 Message-Id: <199805201816.AA24787@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 5826) Re: Take Two: API sockaddr_in6 Update Discussion In-Reply-To: Your message of "Wed, 20 May 1998 10:38:27 PDT." <199805201738.KAA09883@feller.mentat.com> Date: Wed, 20 May 1998 14:16:48 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, > We will take your input as Erik's (your only number 2 with the issue onn > this list). >That is true. I have heard no one support your proposal. WIDE group has and we got mail from INRIA too read your mail Tim. You suggested the index in the first place too. >> All have performance penalty using ancillary data and it creates >> complexity for the programmer of IPv6 tomorrow too who just wants to use >> the interface for new IPv6 multihome applications.. >The problem is that a lot of these applications will need to use ancillary >data anyway because they will need to know the destination address of the >datagram. So where is the savings? Using sendto or recvfrom does not require ancillary data. > If the issue is that folks don't want to break their code base then say > that and not wiggle and worm about adding this index. Because if > breaking applications now is the issue it should apply to other > specifications and be the norm now for IPv6, not just for the API. >Is this a veiled threat to hold up other changes to other documents if you >don't get your way? If so then it should be unveiled. Remember that the >API documents are informational. First how dare you even suggest I use threats in this professional society, that is bogus and I have said nothing to warrant it. I will send you more direct mail offline to this issue. Asking for more context is fine but you did it in a very negative way and attacked my character publicly. Because we have worked together for many years I will just write this off, otherwise I would be tempted to have my lawyer call you for slander and defamation of character. The IPv6 API is absolutely critical to get applications ported to IPv6, without it no one can use IPv6 in a useful way to solve the reason anyone spends money on computers and that is to solve a business problem with applications. If we cannot at this time make the API for IPv6 as efficient as possible because of existing code base that is a data point and milestone we need to capture in the community. For example we don't go mucking around with parts of DHCP or BGP at this point in IPv4 because we have found a better way to enhance these protocols if it will break existing code base in the market or vendor's implementations, usually. If sin6_ifindex is useful but we don't want to add it because it will break existing code, then yes I do believe it should be captured as a data point for IPv6 and I also believe if this is consensus we should in fact do the minimal fix to get scope into the structure, but I think we need to understand the reason why. Because it is informational is irrelevant because it will be internationalized and standardized by TOG XNET group, pretty much what we decide here. I consider that significant. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 20 11:57:02 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id LAA10383 for ipng-dist; Wed, 20 May 1998 11:53:11 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id LAA10376 for ; Wed, 20 May 1998 11:53:02 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA16670 for ; Wed, 20 May 1998 11:53:05 -0700 Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA17313 for ; Wed, 20 May 1998 11:52:58 -0700 (PDT) Received: (from dab@localhost) by frantic.bsdi.com (8.8.8/8.8.8) id NAA16693; Wed, 20 May 1998 13:52:26 -0500 (CDT) Date: Wed, 20 May 1998 13:52:26 -0500 (CDT) From: David Borman Message-Id: <199805201852.NAA16693@frantic.bsdi.com> To: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 5827) Re: Take Two: API sockaddr_in6 Update Discussion Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > From: bound@zk3.dec.com > Subject: (IPng 5809) Take Two: API sockaddr_in6 Update Discussion > Date: Wed, 13 May 1998 15:44:51 -0400 > ... > If we can nail this down Richard Stevens and I are ready to start > writing and filling in the new text. We will add boxes, etc for all > this. > ... > Can we hear from folks please. > > struct sockaddr_in6 { > uint8_t sin6_len; > sa_family_t sin6_family; > in_port_t sin6_port; > uint32_t sin6_scope_id; > uint32_t sin6_ifindex; > uint32_t sin6_flowinfo; > struct in6_addr sin6_addr; > }; This structure is fine by me. The addition of both the sin6_scope_id and sin6_ifindex is necessary, because a site identifier may identify multiple interfaces, and the interface doesn't know which the application will really be interested in. -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 20 12:40:59 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id MAA10420 for ipng-dist; Wed, 20 May 1998 12:37:47 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id MAA10413 for ; Wed, 20 May 1998 12:37:38 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA27762 for ; Wed, 20 May 1998 12:37:41 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id MAA13754 for ; Wed, 20 May 1998 12:37:36 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA19318; Wed, 20 May 98 12:37:25 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id MAA10184; Wed, 20 May 1998 12:39:15 -0700 Date: Wed, 20 May 1998 12:39:15 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199805201939.MAA10184@feller.mentat.com> To: bound@zk3.dec.com Subject: (IPng 5828) Re: Take Two: API sockaddr_in6 Update Discussion Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > >That is true. I have heard no one support your proposal. > > WIDE group has and we got mail from INRIA too read your mail Tim. > You suggested the index in the first place too. > I have not seen anything from them publicly regarding this specific proposal. I recall the WIDE folks being in favor of a single field. I can find it in the archives if necessary. If they have communicated something else to you privately then fine. As I noted to you privately, I became convinced that there was no benefit to the extra field and it broke a lot more code. I believe I said this on the list as well. > >> All have performance penalty using ancillary data and it creates > >> complexity for the programmer of IPv6 tomorrow too who just wants to use > >> the interface for new IPv6 multihome applications.. > > >The problem is that a lot of these applications will need to use ancillary > >data anyway because they will need to know the destination address of the > >datagram. So where is the savings? > > Using sendto or recvfrom does not require ancillary data. > But you will require ancillary data if you want to set the source address or receive the destination address. If one is writing an neighbor discovery daemon you will need to use the IPV6_PKTINFO ancillary data item because you need to know the destination address of the datagrams. Routing protocols will probably need to use it as well. Once again, where is the savings? > > First how dare you even suggest I use threats in this professional > society, that is bogus and I have said nothing to warrant it. I will > send you more direct mail offline to this issue. Asking for more > context is fine but you did it in a very negative way and attacked my > character publicly. Because we have worked together for many years I > will just write this off, otherwise I would be tempted to have my lawyer > call you for slander and defamation of character. > I should not have implied or stated that you were making "veiled threats". It appeared to me as though you were disregarding Erik's and my suggestions and I overeacted. That was inappropriate given our previous relationship. I apologize. That said, threatening people with legal action seems inappropriate as well, given the context of the discussion. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 20 13:54:13 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id NAA10564 for ipng-dist; Wed, 20 May 1998 13:50:19 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with ESMTP id NAA10557 for ; Wed, 20 May 1998 13:50:09 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id NAA14700; Wed, 20 May 1998 13:49:58 -0700 (PDT) Date: Wed, 20 May 1998 13:49:41 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5829) Re: Take Two: API sockaddr_in6 Update Discussion To: bound@zk3.dec.com Cc: Tim Hartrick , Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199805201609.AA04752@wasted.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk c89 -o ~/tmp/sun ~/tmp/sun.c> I am not sure now which way it should go but I don't buy your > performance penalty argument. In fact if the index is in the socket > structure for many of us with BSD kernels it is a performance win. For TCP I agree it is easy. But for udp it all depends on the interface between IP and UDP. While some implementations might just need to add an ifindex parameter to udp_input, in a streams based implementation like ours it will add a small performace hit to have to pass up the ifindex with all received UDP datagrams. Just doing for those with link-local destination addresses would be better. Thus, to summarize, if we require that sin6_ifindex always be present with recvfrom/recvmsg for UDP then the Solaris UDP IPv6 implementation will be slower than the Solaris UDP IPv4 implementation. I think this might create the wrong perception regarding IPv6 performance - I'd hate to see the trade journals complain about IPv6 being slower than IPv4. On the other hand, if all we add is the sin6_scope_id, which only needs to be set when the destination address is link local or site local, then the Solaris IPv6 implementation will not be slowed down for global addresses. (But when using link local or site local addresses there would be a performance penalty which I don't have a problem with.) Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 20 14:14:08 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id OAA10603 for ipng-dist; Wed, 20 May 1998 14:08:26 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with ESMTP id OAA10596 for ; Wed, 20 May 1998 14:08:16 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id OAA17302; Wed, 20 May 1998 14:08:07 -0700 (PDT) Date: Wed, 20 May 1998 14:07:50 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5830) Basic API: sockaddr_union showstopper To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I sent some mail a while back on sockaddr_union in (IPng 5558). Here is one additional issue which is showstopper for this API in Solaris. The structure is defined as union sockaddr_union { struct sockaddr sa; struct sockaddr_in sin; struct sockaddr_in6 sin6; struct sockaddr_un sun; char __maxsize[128]; }; This doesn't work with a compier for sun (our own or gcc) since the compiler defines "sun" to have the value 1. Thus after cpp the structure looks like ... struct sockaddr_un 1; ... The only way to avoid "sun" being defined is to build with strict ANSI-C but that impossible for the byte order aware networking code since the header files can't determine the byte order of the platform in strict ANSI-C. Thus at a minimum the name of the sockaddr_un field needs to be changed from "sun" to something like "un". Or all field names could have a prefix added in the normal BSD fashion such as "su_". (See below.) Also, would it make sense to add a family field to the union so that applications can check the family without using any of the family specific sockaddrs? I'd propose: union sockaddr_union { sa_family_t su_family; struct sockaddr su_sa; struct sockaddr_in su_sin; struct sockaddr_in6 su_sin6; struct sockaddr_un su_sun; char __su_maxsize[128]; }; Comments? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 20 17:05:56 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id RAA10889 for ipng-dist; Wed, 20 May 1998 17:02:43 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with ESMTP id RAA10882 for ; Wed, 20 May 1998 17:02:38 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0+Sun/8.9.0) with ESMTP id RAA16196 for ; Wed, 20 May 1998 17:02:37 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id RAA05496 for ipng@sunroof.eng.sun.com; Wed, 20 May 1998 17:02:14 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id QAA10861 for ; Wed, 20 May 1998 16:56:41 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA03693; Wed, 20 May 1998 16:56:42 -0700 Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id QAA14082; Wed, 20 May 1998 16:56:38 -0700 (PDT) Received: from hpindlk.cup.hp.com (stellaw@hpindlk.cup.hp.com [15.13.108.64]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id QAA11621; Wed, 20 May 1998 16:56:37 -0700 (PDT) Received: (from stellaw@localhost) by hpindlk.cup.hp.com (8.7.6/8.7.3 TIS Messaging 5.0) id RAA08120; Wed, 20 May 1998 17:00:51 -0700 (PDT) From: Stella Kwong Message-Id: <199805210000.RAA08120@hpindlk.cup.hp.com> Subject: (IPng 5833) Re: Basic API: sockaddr_union showstopper To: Erik.Nordmark@Eng Date: Wed, 20 May 1998 17:00:51 PDT Cc: ipng@sunroof.eng.sun.com X-Mailer: Elm [revision: 212.4] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'd propose: > union sockaddr_union { > sa_family_t su_family; > struct sockaddr su_sa; > struct sockaddr_in su_sin; > struct sockaddr_in6 su_sin6; > struct sockaddr_un su_sun; > char __su_maxsize[128]; > }; > I have no problem with the "su_" prefix. That's fine for me. However, I do have questions on this structure: 1. I assume the sockaddr_union will be defined in . In order for this to compile correctly, now we need to add and in since our header files must be self-contained. However, I notice that there are applications that do not expect nor to be automatically brought in when socket.h is included. Have you run into this kind of problem? It is not a big deal, but I am just wondering how you solve it. 2. If there is a need for the sockaddr (su_sa) field, I would think we also need a field for sockaddr_l. Are you assuming the su_maxsize can be used instead in this case? 3. How about other family such as AF_CCITT et al? Are you relying on the su_maxsize to take care of all other families? Stella -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 20 22:55:41 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id WAA11154 for ipng-dist; Wed, 20 May 1998 22:52:57 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id WAA11147 for ; Wed, 20 May 1998 22:52:44 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA23471 for ; Wed, 20 May 1998 22:52:49 -0700 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id WAA27623 for ; Wed, 20 May 1998 22:52:43 -0700 (PDT) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.8+3.0Wbeta12/3.6W) with ESMTP id OAA22645; Thu, 21 May 1998 14:50:34 +0900 (JST) To: thartric@mentat.com (Tim Hartrick) cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-reply-to: thartric's message of Wed, 20 May 1998 12:39:15 MST. <199805201939.MAA10184@feller.mentat.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 5834) Re: Take Two: API sockaddr_in6 Update Discussion From: Jun-ichiro itojun Itoh Date: Thu, 21 May 1998 14:50:34 +0900 Message-ID: <22641.895729834@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> WIDE group has and we got mail from INRIA too read your mail Tim. >> You suggested the index in the first place too. >I have not seen anything from them publicly regarding this specific >proposal. I recall the WIDE folks being in favor of a single field. >I can find it in the archives if necessary. If they have communicated >something else to you privately then fine. >As I noted to you privately, I became convinced that there was no benefit >to the extra field and it broke a lot more code. I believe I said this >on the list as well. Hello, (with "WIDE" hat on the head) Just to clarify... As for additional field (sin6_scope_id), we are happy with it if the relationship between sin6_scope_id and sin6_ifindex are clearly defined. For example, - how to bark/handle if sin6_scope_id and sin6_ifindex contradicts must be clearly defined. We do not push too much about "single field". All we want see is the new draft. If the new draft is published sooner, it is better. We are sitting right next to our source code and waiting for the new draft :-) Without draft we can't try implementing the spec. We will submit some comment on the draft later, after real experience with the new spec. Jun-ichiro itojun Itoh itojun@itojun.org itojun@wide.ad.jp itojun@kame.net -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 21 06:29:20 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id GAA11295 for ipng-dist; Thu, 21 May 1998 06:25:02 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id GAA11288 for ; Thu, 21 May 1998 06:24:51 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA27088; Thu, 21 May 1998 06:24:53 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA03356; Thu, 21 May 1998 06:24:48 -0700 (PDT) Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail11.digital.com (8.8.8/8.8.8/WV1.0e) with SMTP id JAA25438; Thu, 21 May 1998 09:24:47 -0400 (EDT) Received: by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA10906; Thu, 21 May 1998 09:24:46 -0400 Date: Thu, 21 May 1998 09:24:46 -0400 From: Jack McCann Message-Id: <199805211324.AA10906@wasted.zk3.dec.com> To: Erik.Nordmark@Eng Subject: (IPng 5835) Re: Basic API: sockaddr_union showstopper Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I'd propose: >union sockaddr_union { > sa_family_t su_family; > struct sockaddr su_sa; > struct sockaddr_in su_sin; > struct sockaddr_in6 su_sin6; > struct sockaddr_un su_sun; > char __su_maxsize[128]; >}; > >Comments? > Erik Yes, I favor field name prefixes based on structure name as a matter of practice, the 'su_' prefix sounds good. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 21 07:57:41 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id HAA11367 for ipng-dist; Thu, 21 May 1998 07:54:54 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id HAA11356 for ; Thu, 21 May 1998 07:54:44 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA09872 for ; Thu, 21 May 1998 07:54:49 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA16548 for ; Thu, 21 May 1998 07:54:43 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail11.digital.com (8.8.8/8.8.8/WV1.0e) with SMTP id KAA17348; Thu, 21 May 1998 10:49:11 -0400 (EDT) Received: by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA23178; Thu, 21 May 1998 10:49:03 -0400 Date: Thu, 21 May 1998 10:49:03 -0400 From: Jack McCann Message-Id: <199805211449.AA23178@wasted.zk3.dec.com> To: stellaw@cup.hp.com Subject: (IPng 5836) Re: Basic API: sockaddr_union showstopper Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Stella Kwong wrote: > 1. I assume the sockaddr_union will be defined in . > In order for this to compile correctly, now we need to add > and in since our header > files must be self-contained. > > However, I notice that there are applications that do not expect > nor to be automatically brought in when > socket.h is included. > > Have you run into this kind of problem? It is not a big deal, but > I am just wondering how you solve it. Yes, I am also concerned about the namespace issues, and Eric Nordmark raised this concern in (IPng 5558). Xnet has proposed the following wording to incorporate sockaddr_union into the XNS spec: The header defines the | sockaddr_union union that include | at least the following members | | member type | --------------------------------- | sa struct sockaddr | | The union must be sufficiently large to | hold the socket address structure for any | protocol family usable on the system. | (This can be achieved by using "pad-out" | union members. The names of these members | can vary between systems and applications | should not rely on them.) | The sockaddr_union union defined in the | header includes the | following member | | member type | --------------------------------- | sun struct sockaddr_un | The sockaddr_union union defined in the | header includes the | following member | | member type | --------------------------------- | sin struct sockaddr_in | The sockaddr_union union defined in the | header includes the | following member | | member type | --------------------------------- | sin6 struct sockaddr_in6 | I did not find mention that including socket.h may make visible symbols from un.h and in.h. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 21 08:06:28 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id IAA11398 for ipng-dist; Thu, 21 May 1998 08:04:23 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id IAA11391 for ; Thu, 21 May 1998 08:04:13 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA11694 for ; Thu, 21 May 1998 08:04:18 -0700 Received: from sco.COM (scol.london.sco.COM [150.126.1.48]) by earth.sun.com (8.8.8/8.8.8) with SMTP id IAA21859 for ; Thu, 21 May 1998 08:04:11 -0700 (PDT) Received: from tyne.london.sco.com by scol.sco.COM id aa21546; 21 May 98 15:57 BST Received: from stingray.pd.london.sco.com by tyne.sco.com id aa18117; 21 May 98 15:56 BST X-Uri: X-Face: "Ht#9&2KEo;v0Jn!m[7V}D}F5>{KUiNw cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 5837) Re: Basic API: sockaddr_union showstopper In-reply-to: Your message of "Wed, 20 May 1998 14:07:50 PDT." Date: Thu, 21 May 1998 15:56:06 +0100 Message-ID: <8844.895762566@sco.com> From: Harvey Thompson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Erik Nordmark > To: bound@zk3.dec.com > cc: ipng@sunroof.eng.sun.com > Subject: (IPng 5830) Basic API: sockaddr_union showstopper > Date: Wed, 20 May 1998 14:07:50 -0700 (PDT) > > [...] > > I'd propose: > union sockaddr_union { > sa_family_t su_family; > struct sockaddr su_sa; > struct sockaddr_in su_sin; > struct sockaddr_in6 su_sin6; > struct sockaddr_un su_sun; > char __su_maxsize[128]; > }; > > Comments? > Erik Probably want to have the option of including "uint8_t su_len" as the first member for those that have this field, for BSD4.4 based systems; union sockaddr_union { uint8_t su_len; sa_family_t su_family; struct sockaddr su_sa; struct sockaddr_in su_sin; struct sockaddr_in6 su_sin6; struct sockaddr_un su_sun; char __su_maxsize[128]; }; I realise we have SA_LEN() which returns this value given a structure, but without the above, BSD4.4 systems would have to add a pad byte, so we might as well specify it's the length. Also, we have SIN6_LEN which tells us that this field is present in the sockaddr_in6, but I've always wondered why we don't have a define like "SU_LEN" meaning that all sockaddrs have a length field. Perhaps in the light of SA_LEN() this isn't needed (in which case why do we still have SIN6_LEN, for backwards source compat?). --- Harvey Thompson harveyt@sco.com internet Engineering Group, SCO, London UK. +44 1923 813583 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 21 08:15:02 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id IAA11460 for ipng-dist; Thu, 21 May 1998 08:11:16 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id IAA11453 for ; Thu, 21 May 1998 08:11:07 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA13282 for ; Thu, 21 May 1998 08:11:07 -0700 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA26115 for ; Thu, 21 May 1998 08:11:01 -0700 (PDT) Received: by INET-05-IMC with Internet Mail Service (5.5.1960.3) id ; Thu, 21 May 1998 08:11:32 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810058322AF@red-msg-50.dns.microsoft.com> From: Richard Draves To: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 5838) Re: Take Two: API sockaddr_in6 Update Discussion Date: Thu, 21 May 1998 08:11:27 -0700 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think adding an index field to sockaddr_in6 (to disambiguate link-local and site-local addresses) is an important improvement, based on my experience with the MSR IPv6 implementation. I don't see the need for two index fields; I think it would be confusing. Caveat: I must admit that I have not tracked the advanced API spec and its issues, since the advanced API is defined in a way that makes it unimplementable on Winsock. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 21 08:18:02 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id IAA11487 for ipng-dist; Thu, 21 May 1998 08:15:49 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id IAA11480 for ; Thu, 21 May 1998 08:15:40 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA14138 for ; Thu, 21 May 1998 08:15:45 -0700 Received: from mail2-b.microsoft.com (mail2-b.microsoft.com [131.107.3.124]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA28914 for ; Thu, 21 May 1998 08:15:39 -0700 (PDT) Received: by mail2-b.microsoft.com with Internet Mail Service (5.5.2166.0) id ; Thu, 21 May 1998 08:16:08 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810058322B0@red-msg-50.dns.microsoft.com> From: Richard Draves To: Erik Nordmark Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 5839) Re: Basic API: sockaddr_union showstopper Date: Thu, 21 May 1998 08:16:00 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'd propose: > union sockaddr_union { > sa_family_t su_family; > struct sockaddr su_sa; > struct sockaddr_in su_sin; > struct sockaddr_in6 su_sin6; > struct sockaddr_un su_sun; > char __su_maxsize[128]; > }; (I assume you mean making it a struct with an su_family field, followed by a union of the different sockaddr types?) How is an application going to use sockaddr_union? If the purpose is to declare variables big enough to hold any sockaddr type, then I don't see the need for su_family: it would just get in the way. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 21 11:09:00 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id LAA11822 for ipng-dist; Thu, 21 May 1998 11:05:05 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id LAA11815 for ; Thu, 21 May 1998 11:04:57 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA00788 for ; Thu, 21 May 1998 11:05:01 -0700 Received: from sco.COM (scol.london.sco.COM [150.126.1.48]) by earth.sun.com (8.8.8/8.8.8) with SMTP id LAA15112 for ; Thu, 21 May 1998 11:04:54 -0700 (PDT) Received: from tyne.london.sco.com by scol.sco.COM id aa25433; 21 May 98 17:34 BST Received: from stingray.pd.london.sco.com by tyne.sco.com id aa21539; 21 May 98 17:32 BST X-Uri: X-Face: "Ht#9&2KEo;v0Jn!m[7V}D}F5>{KUiNw, bound@zk3.dec.com cc: ipng@sunroof.eng.sun.com Subject: (IPng 5840) Re: Basic API: sockaddr_union showstopper In-reply-to: Your message of "Thu, 21 May 1998 15:56:06 BST." <8844.895762566@sco.com> Date: Thu, 21 May 1998 17:32:43 +0100 Message-ID: <9939.895768363@sco.com> From: Harvey Thompson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > union sockaddr_union { > uint8_t su_len; > sa_family_t su_family; > struct sockaddr su_sa; > struct sockaddr_in su_sin; > struct sockaddr_in6 su_sin6; > struct sockaddr_un su_sun; > char __su_maxsize[128]; > }; Gack! How embarrassing, I probably meant something like this; union sockaddr_union { struct { uint8_t su_s_len; sa_family_t su_s_family; } su_s; struct sockaddr su_sa; struct sockaddr_in su_sin; struct sockaddr_in6 su_sin6; struct sockaddr_un su_sun; char __su_maxsize[128]; }; #define su_len su_s.su_s_len #define su_family su_s.su_s_family Which made me think, why not have this (where su_len definition is only on BSD4.4 derived systems); union sockaddr_union { struct sockaddr su_sa; struct sockaddr_in su_sin; struct sockaddr_in6 su_sin6; struct sockaddr_un su_sun; char __su_maxsize[128]; }; #define su_len su_sa.sa_len #define su_family su_sa.sa_family --- Harvey Thompson harveyt@sco.com internet Engineering Group, SCO, London UK. +44 1923 813583 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 21 11:21:46 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id LAA11842 for ipng-dist; Thu, 21 May 1998 11:15:07 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with ESMTP id LAA11835 for ; Thu, 21 May 1998 11:14:56 -0700 (PDT) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id LAA00298; Thu, 21 May 1998 11:14:51 -0700 (PDT) Date: Thu, 21 May 1998 11:14:51 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5841) Re: Basic API: sockaddr_union showstopper To: Richard Draves Cc: Erik Nordmark , bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D810058322B0@red-msg-50.dns.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > (I assume you mean making it a struct with an su_family field, followed by a > union of the different sockaddr types?) Yes, something like that. I forgot the warning about "half-baked proposal" :-) > How is an application going to use sockaddr_union? If the purpose is to > declare variables big enough to hold any sockaddr type, then I don't see the > need for su_family: it would just get in the way. Good question. If all we want is storage we can just define a struct with no exposed fields that is large enough such as: struct sockaddr_storage { char __ss_maxsize[128]; /* Impl specific */ /* * Plus implementation specific fields to ensure sufficient * alignment. */ }; and then application can do e.g. : struct sockaddr_storage ss; ... struct sockaddr_in6 *sin6; sin6 = (struct sockaddr_in6 *)&ss; Such a definition would avoid breaking any existing applications (such a gated) by introducing e.g. sockaddr_un when is included. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 22 04:31:54 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id EAA12667 for ipng-dist; Fri, 22 May 1998 04:28:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id EAA12660 for ; Fri, 22 May 1998 04:28:32 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA16336 for ; Fri, 22 May 1998 04:28:35 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id EAA18534 for ; Fri, 22 May 1998 04:28:30 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA01886; Fri, 22 May 1998 07:28:27 -0400 (EDT) Message-Id: <199805221128.HAA01886@ietf.org> To: IETF-Announce:;;;@CNRI.Reston.VA.US; Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 5842) Last Call: Neighbor Discovery for IP Version 6 (IPv6) to Draft Standard Reply-to: iesg@ietf.org Date: Fri, 22 May 1998 07:28:27 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider publication of the following Internet-Drafts as Draft Standards: o Neighbor Discovery for IP Version 6 (IPv6) Note: This is an update to RFC1970, currently a Proposed Standard o IPv6 Stateless Address Autoconfiguration Note: This is an update to RFC1971, currently a 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@ietf.org or ietf@ietf.org mailing lists by June 5, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-discovery-v2-02.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-v2-02.txt Implementation Reports can be found at http://www.ietf.org/IESG/nd-auto-implementations.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 22 13:17:21 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id NAA13480 for ipng-dist; Fri, 22 May 1998 13:12:34 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id NAA13473 for ; Fri, 22 May 1998 13:12:24 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA21945 for ; Fri, 22 May 1998 13:12:28 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA08642 for ; Fri, 22 May 1998 13:12:22 -0700 (PDT) Received: from mrohub2.mro.dec.com (mrohub2.mro.dec.com [16.34.192.32]) by mail13.digital.com (8.8.8/8.8.8/WV1.0e) with ESMTP id QAA31457; Fri, 22 May 1998 16:11:41 -0400 (EDT) Received: by mrohub2.mro.dec.com with Internet Mail Service (5.5.1960.3) id ; Fri, 22 May 1998 16:11:42 -0400 Message-ID: From: Ken Powell To: "'narten@raleigh.ibm.com'" , "'set@thumper.bellcore.com'" , "'ipng@sunroof.Eng.Sun.COM'" Subject: (IPng 5843) draft-ietf-ipngwg-addrconf-v2-02 comments Date: Fri, 22 May 1998 16:11:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Susan, Thomas, I reviewed the changes to the spec today and found a couple minor items. Section 2, Page 8, Interface Identifier definition. >> In many cases, the identifier will be the same as the >> interface's link-layer address. I don't know any cases where this is true now. "will be the same as" should be changed to something like "is based on" or "is derived from". Section 5.5.3, Page 19-20 >> An advertisement's O flag field is processed in an analogous manner. >> A host copies the value of the O flag into OtherConfigFlag. If the >> value of OtherConfigFlag changes from FALSE to TRUE, the host should >> invoke the stateful autoconfiguration protocol, requesting >> information (excluding addresses if ManagedFlag is set to FALSE). If >> the value of the OtherConfigFlag changes from TRUE to FALSE, the host >> should continue running the stateful address autoconfiguration >> protocol, i.e., the change in the value of OtherConfigFlag has no >> effect. Was the term "stateful address autoconfiguration" really intended in this last sentence, as opposed to "stateful autoconfiguration" used previously? ======================================================= Ken Powell ken.powell@digital.com DIGITAL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 22 13:29:42 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id NAA13512 for ipng-dist; Fri, 22 May 1998 13:19:28 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id NAA13505 for ; Fri, 22 May 1998 13:19:18 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA23292 for ; Fri, 22 May 1998 13:19:22 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id NAA12124 for ; Fri, 22 May 1998 13:19:16 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA11761; Fri, 22 May 98 13:19:05 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id NAA12952; Fri, 22 May 1998 13:20:55 -0700 Date: Fri, 22 May 1998 13:20:55 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199805222020.NAA12952@feller.mentat.com> To: Erik.Nordmark@Eng Subject: (IPng 5844) Re: Basic API: sockaddr_union showstopper Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > Good question. > If all we want is storage we can just define a struct with no exposed > fields that is large enough such as: > struct sockaddr_storage { > char __ss_maxsize[128]; /* Impl specific */ > /* > * Plus implementation specific fields to ensure sufficient > * alignment. > */ > }; > > and then application can do e.g. : > struct sockaddr_storage ss; > ... > struct sockaddr_in6 *sin6; > > sin6 = (struct sockaddr_in6 *)&ss; > > Such a definition would avoid breaking any existing applications (such a gated) > by introducing e.g. sockaddr_un when is included. > It is a good question. I think your suggestion is a good one. It avoids the circular header file dependencies and name space pollution problems of the current sockaddr_union. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 22 17:02:56 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id QAA13734 for ipng-dist; Fri, 22 May 1998 16:58:42 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id QAA13727 for ; Fri, 22 May 1998 16:58:32 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA10672 for ; Fri, 22 May 1998 16:58:35 -0700 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id QAA26843 for ; Fri, 22 May 1998 16:58:28 -0700 (PDT) Received: from desktop (desktop.ticl.co.uk [193.32.1.15]) by gate.ticl.co.uk (8.8.5/8.8.5) with SMTP id AAA04992; Sat, 23 May 1998 00:44:43 +0100 (BST) Message-Id: <199805222344.AAA04992@gate.ticl.co.uk> X-Sender: peter@gate (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sat, 23 May 1998 00:56:11 +0100 To: Ken Powell From: Peter Curran Subject: (IPng 5845) Re: draft-ietf-ipngwg-addrconf-v2-02 comments Cc: "'narten@raleigh.ibm.com'" , "'set@thumper.bellcore.com'" , "'ipng@sunroof.Eng.Sun.COM'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 16:11 22/05/98 -0400, Ken Powell wrote: >Susan, Thomas, > >I reviewed the changes to the spec today and found >a couple minor items. > > >Section 2, Page 8, Interface Identifier definition. > >>> In many cases, the identifier will be the same as the >>> interface's link-layer address. > >I don't know any cases where this is true now. "will be the >same as" should be changed to something like "is based on" >or "is derived from". > In fact this is completely the inverse (I must be going mad, I read this doc from cover to cover only a couple of weeks ago and missed this one) the link-layer address is derived from the interface identifier, not the other way around. Did you mean to say that the interface identifier is derived from the MAC address (not universally true)? In fact, it would be safest to drop the last sentance altogether! Peter ============================================================== Peter Curran pcurran@ticl.co.uk http://www.ticl.co.uk Consultant and Author PGP key available from http://wwwkeys.uk.pgp.net:11371 or ldap://certserver.pgp.com PubKey Fingerprint = 5F94 D9A9 45EC 40A7 FB24 18BE 9C2E 74D6 E051 7F1F =============================================================== -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 26 07:57:55 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id HAA15677 for ipng-dist; Tue, 26 May 1998 07:54:22 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id HAA15670 for ; Tue, 26 May 1998 07:54:10 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA06891 for ; Tue, 26 May 1998 07:54:16 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA09082 for ; Tue, 26 May 1998 07:54:08 -0700 (PDT) Received: from mrohub2.mro.dec.com (mrohub2.mro.dec.com [16.34.192.32]) by mail13.digital.com (8.8.8/8.8.8/WV1.0e) with ESMTP id KAA00480; Tue, 26 May 1998 10:53:58 -0400 (EDT) Received: by mrohub2.mro.dec.com with Internet Mail Service (5.5.1960.3) id ; Tue, 26 May 1998 10:53:57 -0400 Message-ID: From: Ken Powell To: "'Peter Curran'" Cc: "'narten@raleigh.ibm.com'" , "'set@thumper.bellcore.com'" , "'ipng@sunroof.Eng.Sun.COM'" Subject: (IPng 5851) RE: draft-ietf-ipngwg-addrconf-v2-02 comments Date: Tue, 26 May 1998 10:53:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, My comments are sliced in with "[Ken]" below. Ken -----Original Message----- From: Peter Curran [SMTP:pcurran@ticl.co.uk] Sent: Friday, May 22, 1998 7:56 PM To: Ken Powell Cc: 'narten@raleigh.ibm.com'; 'set@thumper.bellcore.com'; 'ipng@sunroof.Eng.Sun.COM' Subject: Re: (IPng 5843) draft-ietf-ipngwg-addrconf-v2-02 comments At 16:11 22/05/98 -0400, Ken Powell wrote: >Susan, Thomas, > >I reviewed the changes to the spec today and found >a couple minor items. > > >Section 2, Page 8, Interface Identifier definition. > >>> In many cases, the identifier will be the same as the >>> interface's link-layer address. > >I don't know any cases where this is true now. "will be the >same as" should be changed to something like "is based on" >or "is derived from". > In fact this is completely the inverse (I must be going mad, I read this doc from cover to cover only a couple of weeks ago and missed this one) the link-layer address is derived from the interface identifier, not the other way around. [Ken] I'm confused. I understood that the MAC address is the Link Layer address for ethernet, FDDI, token ring, and possibly others. If this is true, then I think it is correct to say that we derive the IPv6 interface identifier from the link layer address. Did you mean to say that the interface identifier is derived from the MAC address (not universally true)? In fact, it would be safest to drop the last sentance altogether! [Ken] True, the interface identifier is not always derived from the link-layer (MAC or whatever) address, but I don't see any need to drop the sentence. The phrase "In many cases" leaves the options open. ======================================================= Ken Powell Digital Equipment Corporation ken.powell@digital.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 26 08:39:22 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id IAA15755 for ipng-dist; Tue, 26 May 1998 08:35:11 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id IAA15748 for ; Tue, 26 May 1998 08:35:02 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA16164 for ; Tue, 26 May 1998 08:35:08 -0700 Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA01272 for ; Tue, 26 May 1998 08:34:54 -0700 (PDT) Received: from chocorua.east.isi.edu by east.isi.edu (8.8.5/5.61+local-24) id ; Tue, 26 May 1998 11:34:53 -0400 (EDT) Message-Id: <199805261534.LAA12994@east.isi.edu> To: ipng@sunroof.eng.sun.com Cc: perez@EAST.ISI.EDU Subject: (IPng 5852) icmp rate limiting Reply-To: perez@isi.edu Date: Tue, 26 May 1998 11:24:14 EDT From: Maryann Perez Maher Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, The current ICMPv6-v2 draft (draft-ietf-ipngwg-icmp-v2-00.txt) states that ICMP rate limiting should be done for informational replies as well as error messages (section 2.4). This statement might suggest that ND and MLD ICMP reply messages, along echo replies, should be rate limited, which is probably not the intention. Or is there some reason why they should be? If not, this should be made clear in the text. Btw, this is a change from RFC 1885, where it is mandatory to rate limit only error messages. Also, if echo replies are to be rate limited, the suggestion of a 1/second default is probably not so appropriate since most echo requests (pings) are usally sent per second. Maryann -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 26 10:13:03 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id KAA15869 for ipng-dist; Tue, 26 May 1998 10:09:24 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with ESMTP id KAA15862 for ; Tue, 26 May 1998 10:09:13 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0+Sun/8.9.0) with ESMTP id KAA14873 for ; Tue, 26 May 1998 10:09:09 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id KAA15529 for ipng@sunroof.eng.sun.com; Tue, 26 May 1998 10:08:43 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id WAA13941 for ; Fri, 22 May 1998 22:55:08 -0700 (PDT) From: owner-ipng%sunroof.Eng.Sun.COM@canadatrust.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA13264 for ; Fri, 22 May 1998 22:55:14 -0700 Received: from galileo.canadatrust.com (galileo.canadatrust.com [204.101.73.108]) by earth.sun.com (8.8.8/8.8.8) with SMTP id WAA26748 for ; Fri, 22 May 1998 22:55:08 -0700 (PDT) Received: id BAA21961; Sat, 23 May 1998 01:47:43 -0400 Received: by gateway id m0yd70S-00001bC; Sat, 23 May 98 01:38 EDT Message-Id: Date: Sat May 23 00:40:49 1998 To: Erik.Nordmark@Eng Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5854) Re: Basic API: sockaddr_union showstopper Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > Good question. > If all we want is storage we can just define a struct with no exposed > fields that is large enough such as: > struct sockaddr_storage { > char __ss_maxsize 128 ; /* Impl specific */ > /* > * Plus implementation specific fields to ensure sufficient > * alignment. > */ > }; > > and then application can do e.g. : > struct sockaddr_storage ss; > ... > struct sockaddr_in6 *sin6; > > sin6 = (struct sockaddr_in6 *)&ss; > > Such a definition would avoid breaking any existing applications (such a gated) > by introducing e.g. sockaddr_un when is included. > It is a good question. I think your suggestion is a good one. It avoids the circular header file dependencies and name space pollution problems of the current sockaddr_union. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 26 10:13:06 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id KAA15860 for ipng-dist; Tue, 26 May 1998 10:07:18 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with ESMTP id KAA15853 for ; Tue, 26 May 1998 10:07:09 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0+Sun/8.9.0) with ESMTP id KAA14593 for ; Tue, 26 May 1998 10:07:07 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id KAA15501 for ipng@sunroof.eng.sun.com; Tue, 26 May 1998 10:06:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id VAA13902 for ; Fri, 22 May 1998 21:49:55 -0700 (PDT) From: Ken.Powell%digital.com@canadatrust.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA09298 for ; Fri, 22 May 1998 21:50:00 -0700 Received: from galileo.canadatrust.com (galileo.canadatrust.com [204.101.73.108]) by earth.sun.com (8.8.8/8.8.8) with SMTP id VAA12942 for ; Fri, 22 May 1998 21:49:55 -0700 (PDT) Received: by gateway id m0yd64H-0001WTC; Sat, 23 May 98 00:38 EDT Message-Id: Date: Sat May 23 00:41:26 1998 To: narten@raleigh.ibm.com, set@thumper.bellcore.com, ipng@sunroof.eng.sun.com Subject: (IPng 5853) draft-ietf-ipngwg-addrconf-v2-02 comments Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Susan, Thomas, I reviewed the changes to the spec today and found a couple minor items. Section 2, Page 8, Interface Identifier definition. >> In many cases, the identifier will be the same as the >> interface's link-layer address. I don't know any cases where this is true now. "will be the same as" should be changed to something like "is based on" or "is derived from". Section 5.5.3, Page 19-20 >> An advertisement's O flag field is processed in an analogous manner. >> A host copies the value of the O flag into OtherConfigFlag. If the >> value of OtherConfigFlag changes from FALSE to TRUE, the host should >> invoke the stateful autoconfiguration protocol, requesting >> information (excluding addresses if ManagedFlag is set to FALSE). If >> the value of the OtherConfigFlag changes from TRUE to FALSE, the host >> should continue running the stateful address autoconfiguration >> protocol, i.e., the change in the value of OtherConfigFlag has no >> effect. Was the term "stateful address autoconfiguration" really intended in this last sentence, as opposed to "stateful autoconfiguration" used previously? ======================================================= Ken Powell ken.powell@digital.com DIGITAL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 26 11:44:59 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id LAA16110 for ipng-dist; Tue, 26 May 1998 11:40:09 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id LAA16102 for ; Tue, 26 May 1998 11:39:56 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA01753 for ; Tue, 26 May 1998 11:40:01 -0700 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA23695 for ; Tue, 26 May 1998 11:39:53 -0700 (PDT) Received: from creak.ticl.co.uk (close.ticl.co.uk [193.32.1.10]) by gate.ticl.co.uk (8.8.5/8.8.5) with SMTP id TAA12593; Tue, 26 May 1998 19:26:16 +0100 (BST) Reply-To: "Peter Curran" From: "Peter Curran" To: "Ken Powell" Cc: , , Subject: (IPng 5855) Re: draft-ietf-ipngwg-addrconf-v2-02 comments Date: Tue, 26 May 1998 19:35:04 +0100 Message-ID: <01bd88d4$ffee6620$4c11e8c3@creak.ticl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ken Please accept my humble apologies. I can only blame a lack of sleep :-) I read "link-layer" address as "link-local" address. You are completely correct, the interface identifier IS derived from the link-layer address (in most cases). Once again apologies for the confusion. Cheers Peter >Peter, > >My comments are sliced in with "[Ken]" below. > >Ken > >-----Original Message----- >From: Peter Curran [SMTP:pcurran@ticl.co.uk] >Sent: Friday, May 22, 1998 7:56 PM >To: Ken Powell >Cc: 'narten@raleigh.ibm.com'; 'set@thumper.bellcore.com'; >'ipng@sunroof.Eng.Sun.COM' >Subject: Re: (IPng 5843) draft-ietf-ipngwg-addrconf-v2-02 comments > >At 16:11 22/05/98 -0400, Ken Powell wrote: >>Susan, Thomas, >> >>I reviewed the changes to the spec today and found >>a couple minor items. >> >> >>Section 2, Page 8, Interface Identifier definition. >> >>>> In many cases, the identifier will be the same as the >>>> interface's link-layer address. >> >>I don't know any cases where this is true now. "will be the >>same as" should be changed to something like "is based on" >>or "is derived from". >> >In fact this is completely the inverse (I must be going mad, I read this >doc from cover to cover only a couple of weeks ago and missed this one) >the link-layer address is derived from the interface identifier, not the >other way around. >[Ken] I'm confused. I understood that the MAC address >is the Link Layer address for ethernet, FDDI, token ring, >and possibly others. If this is true, then I think it is >correct to say that we derive the IPv6 interface identifier >from the link layer address. > >Did you mean to say that the interface identifier is derived from the MAC >address (not universally true)? >In fact, it would be safest to drop the last sentance altogether! >[Ken] True, the interface identifier is not always >derived from the link-layer (MAC or whatever) address, >but I don't see any need to drop the sentence. The >phrase "In many cases" leaves the options open. > >======================================================= >Ken Powell >Digital Equipment Corporation >ken.powell@digital.com >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 26 16:39:26 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id QAA17053 for ipng-dist; Tue, 26 May 1998 16:25:54 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id QAA17046 for ; Tue, 26 May 1998 16:25:18 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA01804; Tue, 26 May 1998 16:25:23 -0700 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id QAA11282; Tue, 26 May 1998 16:25:09 -0700 (PDT) Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id QAA06633; Tue, 26 May 1998 16:25:08 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id QAA17098; Tue, 26 May 1998 16:25:07 -0700 (MST) Message-Id: <199805262325.QAA17098@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Tue, 26 May 1998 16:25:07 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: ipng@sunroof.eng.sun.com Subject: (IPng 5856) Re: Basic API: sockaddr_union showstopper Cc: Erik Nordmark Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of May 21, 11:14am you write:] > > Good question. > If all we want is storage we can just define a struct with no exposed > fields that is large enough such as: > struct sockaddr_storage { > char __ss_maxsize[128]; /* Impl specific */ > /* > * Plus implementation specific fields to ensure sufficient > * alignment. > */ > }; Yes, the original intent (since I put it in the draft on Craig Metz's request) is just to have something (1) large enough, with (2) correct alignment, for calls to functions like getsockname() and getpeername(), to help write protocol-independent code. A char[] array won't necessarily have the correct alignment and you don't want to force a call to malloc() just to get the alignment. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 26 17:57:57 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id RAA17168 for ipng-dist; Tue, 26 May 1998 17:53:26 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with ESMTP id RAA17161 for ; Tue, 26 May 1998 17:53:16 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id RAA21307; Tue, 26 May 1998 17:53:10 -0700 (PDT) Date: Tue, 26 May 1998 17:52:51 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5857) Re: Basic API: sockaddr_union showstopper To: "W. Richard Stevens" Cc: ipng@sunroof.eng.sun.com, Erik Nordmark In-Reply-To: "Your message with ID" <199805262325.QAA17098@kohala.kohala.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > [In your message of May 21, 11:14am you write:] > > > > Good question. > > If all we want is storage we can just define a struct with no exposed > > fields that is large enough such as: > > struct sockaddr_storage { > > char __ss_maxsize[128]; /* Impl specific */ > > /* > > * Plus implementation specific fields to ensure sufficient > > * alignment. > > */ > > }; > > Yes, the original intent (since I put it in the draft on Craig Metz's > request) is just to have something (1) large enough, with (2) correct > alignment, for calls to functions like getsockname() and getpeername(), > to help write protocol-independent code. A char[] array won't necessarily > have the correct alignment and you don't want to force a call to malloc() > just to get the alignment. In my proposal above an implementation can add whatever fields it needs to get appropriate alignment. The point is that a structure (or union) to solve the application portability issue doesn't need any exposed field members. It can just be specified as struct sockaddr_storage {}; where an implementation can fill in the content between the '{}' to get the appropriate size and alignment. That avoids any breakage of existing code due to "name space pollution" from which is not the case with the proposal in the draft. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 26 17:58:20 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id RAA17178 for ipng-dist; Tue, 26 May 1998 17:56:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id RAA17171 for ; Tue, 26 May 1998 17:56:09 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA26975; Tue, 26 May 1998 17:56:16 -0700 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id RAA03662; Tue, 26 May 1998 17:56:10 -0700 (PDT) Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id RAA06682; Tue, 26 May 1998 17:56:09 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id RAA17522; Tue, 26 May 1998 17:56:08 -0700 (MST) Message-Id: <199805270056.RAA17522@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Tue, 26 May 1998 17:56:08 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Erik Nordmark Subject: (IPng 5858) Re: Basic API: sockaddr_union showstopper Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry I wasn't clear. When I said > A char[] array won't necessarily > have the correct alignment and you don't want to force a call to malloc() > just to get the alignment. I meant declaring a variable like "char foo[_MAX_SOCKADDR_LEN];" won't work. I think Erik's propsal is fine. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 27 08:51:04 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id IAA17629 for ipng-dist; Wed, 27 May 1998 08:48:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id IAA17622 for ; Wed, 27 May 1998 08:48:17 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA06351 for ; Wed, 27 May 1998 08:48:22 -0700 Received: from aurora.cs.ucla.edu (Aurora.CS.UCLA.EDU [131.179.96.157]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA01493 for ; Wed, 27 May 1998 08:48:15 -0700 (PDT) Received: (from lixia@localhost) by aurora.cs.ucla.edu (8.8.8/UCLACS-4.0) id IAA25623; Wed, 27 May 1998 08:48:06 -0700 (PDT) From: Lixia Zhang Message-Id: <199805271548.IAA25623@aurora.cs.ucla.edu> Subject: (IPng 5859) Re: traffic generator for Digital Unix To: mgoeydem@crcg.edu (Murat Goekdemir) Date: Wed, 27 May 1998 08:48:06 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <356237A8.FCE148BC@crcg.edu> from "Murat Goekdemir" at May 19, 98 09:53:45 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Hi folks, > > i am currently working on my thesis and i need a traffic generator and > other analyzing tools for Digital Unix IPv6 spec. > > Does anybody know if some tools are available ? I'm so far behind email so dont know if this question has been answered. We have ported a test tool tg (traffic generator, originally developed by SRI in early 90's for DARTNET) to IPv6 for freeBSD and solaris http://irl.cs.ucla.edu/software.f.html If you have not heard: tg is a nice tool that can generate tcp or udp packets following specified patterns, load level, packet sizes, starting/ending time, etc, as well as providing basic measurement results (thruput, delay, loss...) > And i would really like to know how far the implementation of IPv6 over > ATM is. Are there some other information materials, except the > draft-ietf-ion-ipv6-atm-02 ? > > If this is off topic here, I apologize. > > thanks > Murat Goekdemir > > --------------904475A723C5834B37AF8C37 > Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" > Content-Transfer-Encoding: 7bit > Content-Description: Card for Murat Goekdemir > Content-Disposition: attachment; filename="vcard.vcf" > > begin: vcard > fn: Murat Goekdemir > n: Goekdemir;Murat > org: Fraunhofer Center for Research in Computer Graphics > adr: 321 South Main Street;;;Providence;Rhode Island;02903;USA > email;internet: mgoeydem@crcg.edu > tel;work: +1 401 453 63 63 xx 107 > tel;fax: +1 401 453 0444 > x-mozilla-cpt: ;0 > x-mozilla-html: FALSE > end: vcard > > > --------------904475A723C5834B37AF8C37-- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 29 02:00:29 1998 Received: by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) id BAA19935 for ipng-dist; Fri, 29 May 1998 01:57:47 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id BAA19917 for ; Fri, 29 May 1998 01:57:32 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA21902 for ; Fri, 29 May 1998 01:57:38 -0700 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id BAA23063 for ; Fri, 29 May 1998 01:57:30 -0700 (PDT) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.8+3.0Wbeta12/3.6W) with ESMTP id RAA09262 for ; Fri, 29 May 1998 17:57:28 +0900 (JST) To: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 5863) error code for getnameinfo() From: Jun-ichiro itojun Itoh Date: Fri, 29 May 1998 17:57:28 +0900 Message-ID: <9258.896432248@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, In draft-ietf-ipngwg-bsd-api-new-01.txt, no specific values are defined for return value of getnameinfo(). Is it assumed to be one of "EAI_foobaa"? Or else, should this be standardized somehow? Jun-ichiro itojun Itoh WIDE/KAME project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------