From owner-ipng@sunroof.eng.sun.com Thu Oct 1 11:45:41 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA08245 for ipng-dist; Thu, 1 Oct 1998 11:41:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA08238 for ; Thu, 1 Oct 1998 11:41: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 LAA08428 for ; Thu, 1 Oct 1998 11:41:07 -0700 Received: from send1c.yahoomail.com (send1c.yahoomail.com [205.180.60.38]) by earth.sun.com (8.9.1/8.9.1) with SMTP id LAA12636 for ; Thu, 1 Oct 1998 11:41:09 -0700 (PDT) Message-ID: <19980924174307.19693.rocketmail@send1c.yahoomail.com> Received: from [138.111.39.131] by send1c; Thu, 24 Sep 1998 10:43:07 PDT Date: Thu, 24 Sep 1998 10:43:07 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6563) Re: Host Fragmentation To: lindberg@cdg.chalmers.se, JimFleming@unety.net, Volsinians@aol.com, ipng@sunroof.eng.sun.com Cc: martillo@chem2.harvard.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hai, I read the paper "Fragmentation Considered Harmful". I think it is not applicable to present IPv6 environment. There are no such good points in that paper for argument "Whether to do host fragmentation or not". The solution proposed by paper is "Internet Probe Message Protocol" This is what we discussed few days back. (If I remember it correctly that one is "PATH MTU discovery " Which proved to be a bad option. -Raghu. == ------------------------------------------------------------ _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.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 Oct 1 13:22:02 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA08416 for ipng-dist; Thu, 1 Oct 1998 13:14:08 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA08409 for ; Thu, 1 Oct 1998 13:13:59 -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 NAA04334 for ; Thu, 1 Oct 1998 13:13:57 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA13303 for ; Thu, 1 Oct 1998 13:13:55 -0700 (PDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id NAA05959 for <@deliverator.sgi.com:ipng@sunroof.Eng.Sun.COM>; Thu, 1 Oct 1998 13:12:13 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for <@relay.sgi.com:ipng@sunroof.Eng.Sun.COM> id NAA17387; Thu, 1 Oct 1998 13:13:51 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA07596 for <@sgi.engr.sgi.com:ipng@sunroof.Eng.Sun.COM>; Thu, 1 Oct 1998 13:13:51 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA98563 for <@relay.engr.sgi.com:ipng@sunroof.Eng.Sun.COM>; Thu, 1 Oct 1998 13:13:50 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA19349 for ipng@sunroof.Eng.Sun.COM; Thu, 1 Oct 1998 13:13:49 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199810012013.NAA19349@bossette.engr.sgi.com> Subject: (IPng 6564) addr parsing problems To: ipng@sunroof.eng.sun.com Date: Thu, 1 Oct 1998 13:13:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Has anybody spent any time addressing the parsing problems introduced by using IPv6 addresses in syntaxes designed for IPv4. For example: Consider the following UNIX command: rcp 8::1:2:3:/abc/test.txt test.txt At first glance this would appear to copy the file /abc/test.txt from host 8::1:2:3. But it could also be copying the file 2:3:/abc/test.txt from host 8::1. The only way to cleanly solve this problem that comes to mind is to have the last colon in the string being used to delimit host and file names, but allowing quotes to force an alternative parsing. Then there's the problem with URLs with port numbers specified, such as: http://8::1::2:3:81/index.html I beleive this problem has been discussed at the IETF, but I don't know if there was any solution. There are probably others that I haven't come across yet. Any ideas/info appreciated. -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Oct 1 13:56:28 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA08473 for ipng-dist; Thu, 1 Oct 1998 13:51:23 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id NAA08466 for ; Thu, 1 Oct 1998 13:51:11 -0700 (PDT) Received: from antley.eng.sun.com (antley [129.146.86.225]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id NAA20512; Thu, 1 Oct 1998 13:50:55 -0700 (PDT) Received: by antley.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA28217; Thu, 1 Oct 1998 13:45:25 -0700 Date: Thu, 1 Oct 1998 13:45:25 -0700 From: Carl.Williams@eng.sun.com (Carl Williams) Message-Id: <199810012045.NAA28217@antley.eng.sun.com> To: sm@bossette.engr.sgi.com Subject: (IPng 6565) RE: addr parsing problems Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Since the textual representation of an IPv6 address is specified with ":" (colon) characters, a new syntax using "[" and "]" characters is introduced to handle the parsing of the ":" character so as to distinquish the ":" that makeups the IPv6 address from the ":" that seperates the literal IPv6 address from the path: Example for "rcp" command: rcp [2::9255:a00:20ff:fe78:f37c]:/home/carlw/foo.doc /tmp/foo.doc For URL's this issue was also raised at IETF-DC. It was proposed that the "[" and "]" characters also be used with literal addresses specified in the URL. If anyone is doing anything different, I would like to hear from them. Carl ----- Begin Included Message ----- From owner-ipng@sunroof.eng.sun.com Thu Oct 1 13:24:56 1998 From: sm@bossette.engr.sgi.com (Sam Manthorpe) Subject: (IPng 6564) addr parsing problems To: ipng@sunroof.eng.sun.com Date: Thu, 1 Oct 1998 13:13:49 -0700 (PDT) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Has anybody spent any time addressing the parsing problems introduced by using IPv6 addresses in syntaxes designed for IPv4. For example: Consider the following UNIX command: rcp 8::1:2:3:/abc/test.txt test.txt At first glance this would appear to copy the file /abc/test.txt from host 8::1:2:3. But it could also be copying the file 2:3:/abc/test.txt from host 8::1. The only way to cleanly solve this problem that comes to mind is to have the last colon in the string being used to delimit host and file names, but allowing quotes to force an alternative parsing. Then there's the problem with URLs with port numbers specified, such as: http://8::1::2:3:81/index.html I beleive this problem has been discussed at the IETF, but I don't know if there was any solution. There are probably others that I haven't come across yet. Any ideas/info appreciated. -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 -------------------------------------------------------------------- ----- End Included 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 Thu Oct 1 22:08:03 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id VAA09014 for ipng-dist; Thu, 1 Oct 1998 21:56:50 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id VAA09007 for ; Thu, 1 Oct 1998 21: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 VAA08270 for ; Thu, 1 Oct 1998 21:56:40 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA03171 for ; Thu, 1 Oct 1998 21:56:35 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id EAA02444 for ; Fri, 2 Oct 1998 04:55:15 GMT Message-Id: <199810020455.EAA02444@inner.net> To: ipng@sunroof.eng.sun.com Subject: (IPng 6566) Source route question X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Fri, 02 Oct 1998 00:54:47 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sort of a nit, but in this block: if Address [i] or the IPv6 Destination Address is multicast { discard the packet } else { swap the IPv6 Destination Address and Address[i] if the IPv6 Hop Limit is less than or equal to 1 { send an ICMP Time Exceeded -- Hop Limit Exceeded in Transit message to the Source Address and discard the packet } else { decrement the Hop Limit by 1 resubmit the packet to the IPv6 module for transmission to the new destination } } Why is the swap located there instead of after the hop limit decrement? It seems to be a wasted step, but does affect the contents of the ICMP error. -Craig -------------------------------------------------------------------- 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 Oct 1 23:10:58 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id XAA09065 for ipng-dist; Thu, 1 Oct 1998 23:07:12 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id XAA09058 for ; Thu, 1 Oct 1998 23:07: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 XAA15762 for ; Thu, 1 Oct 1998 23:07:01 -0700 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id XAA00770 for ; Thu, 1 Oct 1998 23:07:02 -0700 (PDT) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2232.9) id <4BAK9YC4>; Thu, 1 Oct 1998 23:07:01 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81382@RED-MSG-50> From: Richard Draves To: "'Craig Metz'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6567) RE: Source route question Date: Thu, 1 Oct 1998 23:07:01 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Why is the swap located there instead of after the hop > limit decrement? It > seems to be a wasted step, but does affect the contents of > the ICMP error. My conceptual picture is that everything up to the hop limit check is part of the routing header processing proper, while the hop limit check (and other checks which are not mentioned in that description) are part of a more general forwarding function. So reversing the two steps as you describe should be acceptable, I think, but it might not be desirable in an implementation that wants to share the routing header forwarding code with normal router forwarding code. 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 Fri Oct 2 02:26:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id CAA09185 for ipng-dist; Fri, 2 Oct 1998 02:21:10 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id CAA09178 for ; Fri, 2 Oct 1998 02:21:01 -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 CAA07713; Fri, 2 Oct 1998 02:21:00 -0700 Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA10203; Fri, 2 Oct 1998 02:20:56 -0700 (PDT) Received: from alden ([10.128.1.82]) by dokka.maxware.no (8.8.5/8.8.5) with SMTP id LAA03781; Fri, 2 Oct 1998 11:20:52 +0200 Message-Id: <3.0.2.32.19981002112100.019004b0@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 02 Oct 1998 11:21:00 +0200 To: Carl.Williams@Eng (Carl Williams), sm@bossette.engr.sgi.com From: Harald Tveit Alvestrand Subject: (IPng 6568) Re: addr parsing problems Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199810012045.NAA28217@antley.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 13:45 01.10.98 -0700, Carl Williams wrote: > >Since the textual representation of an IPv6 address is specified >with ":" (colon) characters, a new syntax using "[" and "]" >characters is introduced to handle the parsing of the ":" >character so as to distinquish the ":" that makeups the IPv6 >address from the ":" that seperates the literal IPv6 address >from the path: > >Example for "rcp" command: > >rcp [2::9255:a00:20ff:fe78:f37c]:/home/carlw/foo.doc /tmp/foo.doc > On what system is this problem-free? For Unix (bash, csh) it requires quoting the whole argument, since [] are shell metacharacters. The off-again, on-again discussions in the URL-related working groups has generally died down without anyone finding any alternative to http://2%3D%3D9255%3Da00%3D....../ (hex-quoting the colons). For mail, the DRUMS WG has also failed to converge on a solution, I believe. Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no -------------------------------------------------------------------- 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 Oct 2 10:18:51 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA09607 for ipng-dist; Fri, 2 Oct 1998 10:09:33 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA09600 for ; Fri, 2 Oct 1998 10:09: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 KAA23552 for ; Fri, 2 Oct 1998 10:09:15 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA01815 for ; Fri, 2 Oct 1998 10:08:56 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id RAA03149; Fri, 2 Oct 1998 17:07:01 GMT Message-Id: <199810021707.RAA03149@inner.net> To: Richard Draves cc: ipng@sunroof.eng.sun.com Subject: (IPng 6570) Re: Source route question In-reply-to: Your message of "Thu, 01 Oct 1998 23:07:01 PDT." <4D0A23B3F74DD111ACCD00805F31D8100AF81382@RED-MSG-50> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Fri, 02 Oct 1998 13:06:26 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <4D0A23B3F74DD111ACCD00805F31D8100AF81382@RED-MSG-50>, you write: >> Why is the swap located there instead of after the hop >> limit decrement? It >> seems to be a wasted step, but does affect the contents of >> the ICMP error. > >My conceptual picture is that everything up to the hop limit check is part >of the routing header processing proper, while the hop limit check (and >other checks which are not mentioned in that description) are part of a more >general forwarding function. So reversing the two steps as you describe >should be acceptable, I think, but it might not be desirable in an >implementation that wants to share the routing header forwarding code with >normal router forwarding code. Ok, I can see why you would want to do it this way. However, the wording in the current spec basically forces you to implement things this way, whether or not it's the most efficient way for you to implement. -Craig -------------------------------------------------------------------- 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 Oct 2 12:43:36 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA09770 for ipng-dist; Fri, 2 Oct 1998 12:34:05 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA09763 for ; Fri, 2 Oct 1998 12:33: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 MAA09464 for ; Fri, 2 Oct 1998 12:33:52 -0700 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA14393 for ; Fri, 2 Oct 1998 12:33:46 -0700 (PDT) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2232.9) id <41DAAFDG>; Fri, 2 Oct 1998 12:33:44 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81384@RED-MSG-50> From: Richard Draves To: "'Craig Metz'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6571) RE: Source route question Date: Fri, 2 Oct 1998 12:33:39 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Ok, I can see why you would want to do it this way. > However, the wording in > the current spec basically forces you to implement things > this way, whether or > not it's the most efficient way for you to implement. Your implementation can always do things differently than the spec's conceptual data structures or algorithms would imply, as long as the externally observed behavior is correct. I don't know if this is explicitly noted anywhere, but from past discussions I believe that if a packet might trigger multiple ICMP errors, an implementation has the freedom to send any one of them. Then the question is what about the content of the ICMP errors. How rigidly specified is it? I believe there is also a fair amount of implementation leeway here. For example in the routing header processing, when you send the Hop Limit Exceeded should Segments Left be shown as decremented and the addresses swapped? Should the Hop Limit be shown as 1 or 0? Etc. So in theory I think your implementation can check the Hop Limit before swapping the addresses, although conceptually that's not the intuitive ordering. Now in practice there are applications that may be sensitive to which ICMP error is generated and what it contains. For example it might make a difference to traceroute if you check the Hop Limit before checking if there's a route to the new destination. (The traceroute I've looked at reports better results if the route check is done before the hop limit check.) But I don't know of any "real" applications that care. 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 Fri Oct 2 14:57:21 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA10003 for ipng-dist; Fri, 2 Oct 1998 14:49:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA09996 for ; Fri, 2 Oct 1998 14:49: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 OAA20134 for ; Fri, 2 Oct 1998 14:49:42 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA08096 for ; Fri, 2 Oct 1998 14:49:34 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id VAA03525; Fri, 2 Oct 1998 21:47:10 GMT Message-Id: <199810022147.VAA03525@inner.net> To: Richard Draves cc: ipng@sunroof.eng.sun.com Subject: (IPng 6572) Re: Source route question In-reply-to: Your message of "Fri, 02 Oct 1998 12:33:39 PDT." <4D0A23B3F74DD111ACCD00805F31D8100AF81384@RED-MSG-50> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Fri, 02 Oct 1998 17:47:05 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <4D0A23B3F74DD111ACCD00805F31D8100AF81384@RED-MSG-50>, you write: >Your implementation can always do things differently than the spec's >conceptual data structures or algorithms would imply, as long as the >externally observed behavior is correct. The spec currently says: In that node, dispatching on the Next Header field of the immediately preceding header causes the Routing header module to be invoked, which, in the case of Routing Type 0, performs the following algorithm: Which I read to say that a strictly compliant algorithm MUST NOT do things differently than the way this algorithm states that they are to be done. If memory serves, this all came about in order to reduce confusion as to the steps in processing the routing header and to help ensure that people get it right. What I'd like most to see here is for the introduction to the algorithm description to be clearer as to whether following the steps in this algorithm is a SHOULD or a MUST. -Craig -------------------------------------------------------------------- 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 Sat Oct 3 00:44:57 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id AAA10286 for ipng-dist; Sat, 3 Oct 1998 00:41:18 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id AAA10279 for ; Sat, 3 Oct 1998 00:41: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 AAA29538 for ; Sat, 3 Oct 1998 00:41:00 -0700 Received: from www.fandom.net (fandom.net [203.35.8.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id AAA05960 for ; Sat, 3 Oct 1998 00:41:00 -0700 (PDT) Date: Sat, 3 Oct 1998 00:41:00 -0700 (PDT) Message-Id: <199810030741.AAA05960@earth.sun.com> Received: from certhas.fandom.net [203.35.8.5] by www.fandom.net with smtp id IULJGJCL; Sat, 03 Oct 98 07:40:35 GMT (PowerWeb version 4.04r6) Subject: (IPng 6573) Dumb User Question From: Andrew To: ipng@sunroof.eng.sun.com Reply-To: Andrew X-Priority: 3 (Normal) X-Mailer: BeatWare Mail-It 1.6 X-BeOS-Platform: Intel or clone Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id AAA10280 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry to ask but: Why do server apps such as httpd , ftpd etc. need to be drasticly modified for IPv6? When the Host's TCP stack is IPv6 shouldn't it establish a encrypted IPv6 connection with any IPv6 client wanting to talk to it. I would have expected they only needed to become aware of the new address options. -------------------------------------------------------------------- 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 Sun Oct 4 09:33:49 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA10804 for ipng-dist; Sun, 4 Oct 1998 09:29:49 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA10797 for ; Sun, 4 Oct 1998 09:29: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 JAA20352; Sun, 4 Oct 1998 09:29:29 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA11195; Sun, 4 Oct 1998 09:29:30 -0700 (PDT) Received: from flume.zk3.dec.com (broflume.zk3.dec.com [16.141.0.42]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id MAA08205; Sun, 4 Oct 1998 12:29:28 -0400 (EDT) Received: from brywasted.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA07363; Sun, 4 Oct 1998 12:29:28 -0400 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id MAA0000008316; Sun, 4 Oct 1998 12:29:26 -0400 (EDT) From: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group Message-Id: <199810041629.MAA0000008316@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Erik Nordmark Cc: bound@zk3.dec.com, Atsushi Onoe , ipng@sunroof.eng.sun.com Subject: (IPng 6576) Re: Base API: Check on IPv4 Literal Addresses In-Reply-To: Your message of "Wed, 30 Sep 1998 16:18:03 PDT." Date: Sun, 04 Oct 1998 12:29:26 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, >JIM, > >> >Actually the current spec for IPv4 literal address is very confusing: >> > with AI_V4MAPPED returns IPv4-mapped IPv6 address >> > with AI_V4MAPPED | AI_ALL returns NULL >> >> Agreed. Neither is required to be specified. > >Just to make sure ... >I assume you don't want to return a mapped address (even for literal IPv4 >addresses) unless AI_V4MAPPED is set since it might confuse applications. This is the question. I personally believe the AI_V4MAPPED MUST be specified. But if the family is AF_INET6 why bother what else could it return is the counter argument and why 2133 previously stated the flags are meaningless. I think specifying AI_V4MAPPED provides cohesion to the purpose of the API and should be specified as the flag will isolate resolver code too dealing with IPv6 so it is a good idea. >Thus I think the rules for IPv4 literals with getipnodebyname(AF_INET6, ...) >should be > If AI_V4MAPPED is set (with or without AI_ALL) return IPv4-mapped > Otherwise return NULL I will use this extended text if I hear no objections. So if anyone objects to Erik's proposal please respond. I will treat silence as agreement. Recall folks, Oct 8th is the deadline and then we will wrap this up and submitt an ID and ask for this work to be moved to new Info RFC to replace RFC 2133. 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 Mon Oct 5 06:44:45 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA11162 for ipng-dist; Mon, 5 Oct 1998 06:40:00 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA11155 for ; Mon, 5 Oct 1998 06:39: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 GAA04119 for ; Mon, 5 Oct 1998 06:39:47 -0700 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA04526 for ; Mon, 5 Oct 1998 06:39:49 -0700 (PDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA23080 for ; Mon, 5 Oct 1998 09:39:47 -0400 Received: from clemson.raleigh.ibm.com (clemson.raleigh.ibm.com [9.37.176.99]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA27930 for ; Mon, 5 Oct 1998 09:39:47 -0400 Received: from localhost.raleigh.ibm.com by clemson.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15382; Mon, 5 Oct 1998 09:38:26 -0400 Message-Id: <3618CBD2.9752CBB7@raleigh.ibm.com> Date: Mon, 05 Oct 1998 09:38:26 -0400 From: Brian Haberman Organization: Remote Access Products X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: IPng Subject: (IPng 6578) Mapping global addresses to link-local addresses Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, While in the process of working on the PIM for IPv6 spec, we came across a problem concerning the mapping of a global address to a linkk-local address. Consider the scenario : Rtr A ----- Rtr B ----- Host 1 Host 1 sends a PIM-SM join message destined for Rtr A. Our draft specifies that protocol messages use link-local addresses, so Host 1 addresses the packet to Rtr B's link-local address since it it the next upstream PIM router. Now Rtr B has the message and needs to address it to Rtr A. The problem is that Rtr B does not have Rtr A's link-local address since it is a direct route. The issue is how can Rtr B find out what Rtr A's link-local address is given a global IPv6 address assigned to A? This has been an on-again/off-again discussion on this list since Munich. Has anyone tried to address this problem? Thanks, Brian Haberman -------------------------------------------------------------------- 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 Oct 5 17:29:54 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA12246 for ipng-dist; Mon, 5 Oct 1998 17:25:15 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id RAA12239 for ; Mon, 5 Oct 1998 17:25:07 -0700 (PDT) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA07000; Mon, 5 Oct 1998 17:25:06 -0700 (PDT) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.9.1+Sun/8.9.1) id RAA19245; Mon, 5 Oct 1998 17:22:46 -0700 (PDT) Date: Mon, 5 Oct 1998 17:22:46 -0700 (PDT) From: Mukesh Kacker Message-Id: <199810060022.RAA19245@lucknow.eng.sun.com> To: bound@zk3.dec.com Subject: (IPng 6580) Basic API; "struct in6_addr" section needs to mention alignment issues Cc: ipng@sunroof.eng.sun.com, mukesh@lucknow.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Some comments on the Basic API. (They are not in the newly changed parts but I hope that is OK.) In Section 3.2, the "struct in6_addr" implementation illustrated is one with no alignment fields struct in6_addr { uint8_t s6_addr[16]; /* IPv6 address */ } We should add some text to hint how a real implementation may be different. In Section 2. (Design Considerations) has a bullet item that states that addresses should be aligned. In Section 3.3 "sockaddr_in6" also there is reference to 64-bit alignment boundary desirability for "struct in6_addr" for performance but the implementation shown is a "conceptual one" which does not force alignment. I think a strong hint is needed in section 3.2 also where the real IPv6 address data structure gets defined. The current definition shown if implemented literally does not do alignment ! I would suggest adding the following words at the end of Section 3.2 " The structure in6_addr above is usually implemented with an embedded union with extra fields that force the desired alignment level in manner similar to BSD implementations of "struct in_addr". Those additional implementation details are omitted here for simplicity. " -Mukesh Kacker Internet Engineering Sun Microsystems Inc mukesh.kacker@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 Mon Oct 5 17:46:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA12300 for ipng-dist; Mon, 5 Oct 1998 17:42:10 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA12293 for ; Mon, 5 Oct 1998 17:41: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 RAA25054 for ; Mon, 5 Oct 1998 17:41:56 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.9.1/8.9.1) with SMTP id RAA10211 for ; Mon, 5 Oct 1998 17:41:58 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA22603; Mon, 5 Oct 98 17:41:52 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id RAA15455; Mon, 5 Oct 1998 17:42:01 -0700 Date: Mon, 5 Oct 1998 17:42:01 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199810060042.RAA15455@feller.mentat.com> To: bound@zk3.dec.com, Mukesh.Kacker@Eng Subject: (IPng 6581) Re: Basic API; "struct in6_addr" section needs to mention alignment issues Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mukesh, Jim, > > In Section 3.2, the "struct in6_addr" implementation illustrated is > one with no alignment fields > > struct in6_addr { > uint8_t s6_addr[16]; /* IPv6 address */ > } > > We should add some text to hint how a real implementation may be different. > Indeed. In fact it may be useful to have an example of a more alignment friendly implementation in the document if the form of the example does not lead to a bunch of arguing about names and whatnot. Something like: struct in6_addr { union { uint8_t _S6_b[16]; uint32_t _S6_w[4]; uint64_t _S6_l[2]; } _S6_un; }; #define s6_addr _S6_un._S6_b Tim Hartrick -------------------------------------------------------------------- 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 Oct 5 20:30:27 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id UAA12431 for ipng-dist; Mon, 5 Oct 1998 20:27:36 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id UAA12424 for ; Mon, 5 Oct 1998 20:27:28 -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 UAA22250 for ; Mon, 5 Oct 1998 20:27:27 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA11968 for ; Mon, 5 Oct 1998 20:27:21 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id DAA06643; Tue, 6 Oct 1998 03:22:41 GMT Message-Id: <199810060322.DAA06643@inner.net> To: thartric@mentat.com (Tim Hartrick) cc: ipng@sunroof.eng.sun.com Subject: (IPng 6582) Re: Basic API; "struct in6_addr" section needs to mention alignment issues In-reply-to: Your message of "Mon, 05 Oct 1998 17:42:01 PDT." <199810060042.RAA15455@feller.mentat.com> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Mon, 05 Oct 1998 23:24:28 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199810060042.RAA15455@feller.mentat.com>, you write: >Something like: > >struct in6_addr { > union { > uint8_t _S6_b[16]; > uint32_t _S6_w[4]; > uint64_t _S6_l[2]; > } _S6_un; >}; >#define s6_addr _S6_un._S6_b I believe that this was once the way the structure looked (certainly, many implementations used to do it that way until the wording of the spec made it verboten). I'm not sure why it came to look the way it does now, though it might have had something to do with some people's issues with unions. -Craig -------------------------------------------------------------------- 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 Oct 5 21:27:28 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id VAA12482 for ipng-dist; Mon, 5 Oct 1998 21:18:58 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id VAA12475 for ; Mon, 5 Oct 1998 21:18:50 -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 VAA00130; Mon, 5 Oct 1998 21:18:48 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA29603; Mon, 5 Oct 1998 21:18:49 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id AAA02426; Tue, 6 Oct 1998 00:18:48 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA04640; Tue, 6 Oct 1998 00:18:47 -0400 Message-Id: <199810060418.AA04640@quarry.zk3.dec.com> To: Mukesh Kacker Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6584) Re: Basic API; "struct in6_addr" section needs to mention alignment issues In-Reply-To: Your message of "Mon, 05 Oct 1998 17:22:46 PDT." <199810060022.RAA19245@lucknow.eng.sun.com> Date: Tue, 06 Oct 1998 00:18:46 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A conceptual model should be good enough but I will add the hint. /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 Mon Oct 5 21:28:05 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id VAA12491 for ipng-dist; Mon, 5 Oct 1998 21:23:02 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id VAA12484 for ; Mon, 5 Oct 1998 21:22:54 -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 VAA00734 for ; Mon, 5 Oct 1998 21:22:52 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA00928 for ; Mon, 5 Oct 1998 21:22:54 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id AAA05969; Tue, 6 Oct 1998 00:22:53 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA05344; Tue, 6 Oct 1998 00:22:52 -0400 Message-Id: <199810060422.AA05344@quarry.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6585) Re: Basic API; "struct in6_addr" section needs to mention alignment issues In-Reply-To: Your message of "Mon, 05 Oct 1998 17:42:01 PDT." <199810060042.RAA15455@feller.mentat.com> Date: Tue, 06 Oct 1998 00:22:51 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Indeed. In fact it may be useful to have an example of a more alignment >friendly implementation in the document if the form of the example does >not lead to a bunch of arguing about names and whatnot. > >Something like: > >struct in6_addr { > union { > uint8_t _S6_b[16]; > uint32_t _S6_w[4]; > uint64_t _S6_l[2]; > } _S6_un; >}; >#define s6_addr _S6_un._S6_b I can add as "EXAMPLE" the folks at the time doing Cray words did not want it to be specified in this manner with the union. But as an example that is fine, but we need to leave in6_addr as defined now. thanks /jim Tim Hartrick -------------------------------------------------------------------- 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 Oct 5 21:28:55 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id VAA12500 for ipng-dist; Mon, 5 Oct 1998 21:25:16 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id VAA12493 for ; Mon, 5 Oct 1998 21:25:08 -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 VAA01048 for ; Mon, 5 Oct 1998 21:25:06 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA01654 for ; Mon, 5 Oct 1998 21:25:08 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id AAA11876; Tue, 6 Oct 1998 00:25:06 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA06070; Tue, 6 Oct 1998 00:25:04 -0400 Message-Id: <199810060425.AA06070@quarry.zk3.dec.com> To: Craig Metz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6586) Re: Basic API; "struct in6_addr" section needs to mention alignment issues In-Reply-To: Your message of "Mon, 05 Oct 1998 23:24:28 -0300." <199810060322.DAA06643@inner.net> Date: Tue, 06 Oct 1998 00:25:04 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I believe that this was once the way the structure looked (certainly, many >implementations used to do it that way until the wording of the spec made it >verboten). I'm not sure why it came to look the way it does now, though it >might have had something to do with some people's issues with unions. That was it. I will put it in as example though. 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 Tue Oct 6 07:19:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA12969 for ipng-dist; Tue, 6 Oct 1998 07:16:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA12962 for ; Tue, 6 Oct 1998 07:16:28 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA29050 for ; Tue, 6 Oct 1998 07:16:05 -0700 Received: from dee.inr.ac.ru (dee.inr.ac.ru [193.233.7.82]) by saturn.sun.com (8.9.1/8.9.1) with SMTP id HAA23454 for ; Tue, 6 Oct 1998 07:16:04 -0700 (PDT) Received: (from root@localhost) by dee.inr.ac.ru (8.6.13/ANK+IPv6) id RAA19457; Tue, 6 Oct 1998 17:30:47 +0400 Message-Id: <199810061330.RAA19457@dee.inr.ac.ru> Subject: (IPng 6587) Re: Basic API; "struct in6_addr" section needs to mention alignment issues To: bound@zk3.dec.com, cmetz@inner.net Date: Tue, 6 Oct 1998 17:30:47 +0400 (MSK DST) Cc: thartric@mentat.com, ipng@sunroof.eng.sun.com Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: <199810060422.AA05344@quarry.zk3.dec.com> from "bound@zk3.dec.com" at Oct 6, 98 00:22:51 am From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > I can add as "EXAMPLE" the folks at the time doing Cray words did not > want it to be specified in this manner with the union. But as an > example that is fine, but we need to leave in6_addr as defined now. It is not so minor issue: API should explicitly say about required in6_addr alignment constraints as a "MUST"("NOT") statement. F.e. RSVP (and PIM even worse) was badly designed and carries misaligned IPv6 addresses in messages. Particularly, it means that using in6_addr in protocol definition templates (as ISI rsvpd does) is illegal. Explicit statement in API is necessary just to avoid anarchy. F.e. if rsvpd developers will stuck on using in6_addr, believing that it is not aligned, it is not easy to port it to OS, where in6_addr is forced to be aligned. Alexey Kuznetsov -------------------------------------------------------------------- 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 Oct 6 07:22:19 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA12990 for ipng-dist; Tue, 6 Oct 1998 07:21:05 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA12983 for ; Tue, 6 Oct 1998 07:20: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 HAA05319 for ; Tue, 6 Oct 1998 07:20:49 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA15810 for ; Tue, 6 Oct 1998 07:20:48 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id KAA20458 for ; Tue, 6 Oct 1998 10:20:47 -0400 (EDT) Received: from brywasted.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA20104; Tue, 6 Oct 1998 10:20:46 -0400 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id KAA0000013644; Tue, 6 Oct 1998 10:20:45 -0400 (EDT) From: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group Message-Id: <199810061420.KAA0000013644@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: (IPng 6588) Base API : IPv4 Compatible Addresses :: and ::1 Date: Tue, 06 Oct 1998 10:20:45 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jean-Luc found this bug and it is also probably a bug in the bind code 8.1.2. which needs to be fixed. They (:: and ::1) should not be used as IPv4-compatible addresses in section 6.2 getipnodebyaddr(). Here is the existing text: -------------------------------------------- 1. If af is AF_INET6, and if len equals 16, and if the IPv6 address is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6 address, then skip over the first 12 bytes of the IPv6 address, set af to AF_INET, and set len to 4. 2. If af is AF_INET, lookup the name for the given IPv4 address (e.g., query for a PTR record in the in-addr.arpa domain). 3. If af is AF_INET6, lookup the name for the given IPv6 address (e.g., query for a PTR record in the ip6.int domain). 4. If the function is returning success, then the single address that is returned in the hostent structure is a copy of the first argument to the function with with the same address family that was passed as an argument to this function. All four steps listed are performed, in order. -------------------------------------------- Here is the proposed text to replace the last sentence above and fix the IN6_IS_ADDR_V4COMPAT macro: --------------------------------------------- All four steps listed are performed, in order. Also note that the IPv6 hex addresses "::" and "::1" MUST NOT be treated as an IPv4-compatible address to generate a query for a Host Name, and HOST_NOT_FOUND MUST be returned and a query of the Host Name not performed. Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return false for "::" and "::1". --------------------------------------------- Please comment. I did this as the simplest fix. 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 Tue Oct 6 07:37:03 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA13018 for ipng-dist; Tue, 6 Oct 1998 07:33:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA13011 for ; Tue, 6 Oct 1998 07:33: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 HAA07290 for ; Tue, 6 Oct 1998 07:33:02 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA22122 for ; Tue, 6 Oct 1998 07:32:59 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id KAA25097; Tue, 6 Oct 1998 10:30:57 -0400 (EDT) Received: from brywasted.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA24950; Tue, 6 Oct 1998 10:30:51 -0400 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id KAA0000015305; Tue, 6 Oct 1998 10:30:51 -0400 (EDT) From: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group Message-Id: <199810061430.KAA0000015305@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: kuznet@ms2.inr.ac.ru Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 6589) Re: Basic API; "struct in6_addr" section needs to mention alignment issues In-Reply-To: Your message of "Tue, 06 Oct 1998 17:30:47 +0400." <199810061330.RAA19457@dee.inr.ac.ru> Date: Tue, 06 Oct 1998 10:30:51 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alexey, >It is not so minor issue: API should explicitly say about required >in6_addr alignment constraints as a "MUST"("NOT") statement. It was proposed as an example and it will stay an example unless we hear a strong consensus from the working group that this should change. It is not the IETF's role or The Open Group to mandate alignment in an API spec. It is an implementation issue and all we can do is advise them. >F.e. RSVP (and PIM even worse) was badly designed and carries misaligned >IPv6 addresses in messages. Particularly, it means that using >in6_addr in protocol definition templates (as ISI rsvpd does) is >illegal. If that is true then that is there problem not ours for the API. >Explicit statement in API is necessary just to avoid anarchy. >F.e. if rsvpd developers will stuck on using in6_addr, believing >that it is not aligned, it is not easy to port it to OS, where >in6_addr is forced to be aligned. The market will provide forthright corrections to vendors who break because of alignment issues, it is not the IETF's role to police alignment in implementations. We on IPng have provided direction for IPv6 to be aligned on 64bit architectures consistenly in our specs. We cannot mandate it. This is crossing a line that is not valid for standards except maybe for ANSI compiler standards and they even avoid mandating alignment. If we have done something to prevent alignment than that is an issue. /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 Tue Oct 6 07:40:37 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA13052 for ipng-dist; Tue, 6 Oct 1998 07:38:46 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA13045 for ; Tue, 6 Oct 1998 07:38: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 HAA08447 for ; Tue, 6 Oct 1998 07:38:31 -0700 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA25047 for ; Tue, 6 Oct 1998 07:38:31 -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 XAA12443; Tue, 6 Oct 1998 23:36:00 +0900 (JST) To: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com In-reply-to: bound's message of Tue, 06 Oct 1998 10:20:45 -0400. <199810061420.KAA0000013644@wasted.zk3.dec.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 6590) Re: Base API : IPv4 Compatible Addresses :: and ::1 Date: Tue, 06 Oct 1998 23:36:00 +0900 Message-ID: <12439.907684560@coconut.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Jean-Luc found this bug and it is also probably a bug in the bind code >8.1.2. which needs to be fixed. They (:: and ::1) should not be used as >IPv4-compatible addresses in section 6.2 getipnodebyaddr(). (snip) >Here is the proposed text to replace the last sentence above and fix the >IN6_IS_ADDR_V4COMPAT macro: >--------------------------------------------- >All four steps listed are performed, in order. Also note that the IPv6 >hex addresses "::" and "::1" MUST NOT be treated as an IPv4-compatible <- >address to generate a query for a Host Name, and HOST_NOT_FOUND MUST be <- >returned and a query of the Host Name not performed. <- > >Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return >false for "::" and "::1". >--------------------------------------------- >Please comment. I did this as the simplest fix. I believe the first part of the above be listed as the first item in the ordered steps listed, as: 0. If af is AF_INET6, and if len equals 16, and the IPv6 address equals to :: or ::1, go to step 3. Do the marked lines mean that we should not query 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int (old style) for PTR record? In IPv4 we usually have the following two RRs in the database, in practice. 1.0.0.127.in-addr.arpa. IN PTR localhost. localhost. IN A 127.0.0.1 Do you suggest that it will be different in IPv6? (sorry if I missed any of DNS-related drafts) itojun@kame.net jun-ichiro itoh -------------------------------------------------------------------- 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 Oct 6 08:00:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA13116 for ipng-dist; Tue, 6 Oct 1998 07:56:57 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA13109 for ; Tue, 6 Oct 1998 07:56:49 -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 HAA12296 for ; Tue, 6 Oct 1998 07:56:47 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA05286 for ; Tue, 6 Oct 1998 07:56:45 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id KAA01500; Tue, 6 Oct 1998 10:56:40 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA03711; Tue, 6 Oct 1998 10:56:38 -0400 Message-Id: <199810061456.AA03711@quarry.zk3.dec.com> To: Jun-ichiro itojun Itoh Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6591) Re: Base API : IPv4 Compatible Addresses :: and ::1 In-Reply-To: Your message of "Tue, 06 Oct 1998 23:36:00 +0900." <12439.907684560@coconut.itojun.org> Date: Tue, 06 Oct 1998 10:56:38 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun, >I believe the first part of the above be listed as the first item >in the ordered steps listed, as: >0. If af is AF_INET6, and if len equals 16, and the IPv6 address > equals to :: or ::1, go to step 3. I am suggesting that not even happen. > Do the marked lines mean that we should not query >1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int > (old style) for PTR record? In IPv4 we usually have the following > two RRs in the database, in practice. >1.0.0.127.in-addr.arpa. IN PTR localhost. >localhost. IN A 127.0.0.1 > Do you suggest that it will be different in IPv6? > (sorry if I missed any of DNS-related drafts) I am suggesting that if it does exist it is irrelevant to an application looking up a name for :: which is completely bogus and ::1 nonsensical. I believe ::1 for DNS should be deprecated yes but I don't have the energy to fight that battle, but it is not necessary in this api case and why it can be in this spec. More importantly they are not valid IPv4-Compatible addresses in the spirit of what those addresses are in RFC 2373. An IPv4 compatible address is used to convey a real IPv4 address and ::1 is our loopback address for IPv6. /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 Tue Oct 6 08:48:51 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA13216 for ipng-dist; Tue, 6 Oct 1998 08:40:56 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA13209 for ; Tue, 6 Oct 1998 08:40:45 -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 IAA24057 for ; Tue, 6 Oct 1998 08:40:43 -0700 Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA04334 for ; Tue, 6 Oct 1998 08:40:40 -0700 (PDT) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id KAA22841; Tue, 6 Oct 1998 10:40:07 -0500 (CDT) Date: Tue, 6 Oct 1998 10:40:07 -0500 (CDT) From: David Borman Message-Id: <199810061540.KAA22841@frantic.bsdi.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 6592) Re: Base API : IPv4 Compatible Addresses :: and ::1 Cc: bound@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > From: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group > Subject: (IPng 6588) Base API : IPv4 Compatible Addresses :: and ::1 > Date: Tue, 06 Oct 1998 10:20:45 -0400 > ... > > All four steps listed are performed, in order. > -------------------------------------------- > > Here is the proposed text to replace the last sentence above and fix the > IN6_IS_ADDR_V4COMPAT macro: > > --------------------------------------------- > All four steps listed are performed, in order. Also note that the IPv6 > hex addresses "::" and "::1" MUST NOT be treated as an IPv4-compatible > address to generate a query for a Host Name, and HOST_NOT_FOUND MUST be > returned and a query of the Host Name not performed. Shouldn't that be "address", not "Host Name"? > Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return > false for "::" and "::1". > --------------------------------------------- > > Please comment. I did this as the simplest fix. There is no reason why a query for ::1 should be *required* to fail. A query for :: can be required to fail, but as long as ::1 is the IPv6 loopback address, it should be able to succeed. Something more like: All four steps listed are performed, in order. Also note that the IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4-compatible addresses, and if the address is "::", HOST_NOT_FOUND MUST be returned and a query of the address not performed. Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return false for "::" and "::1". -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 Tue Oct 6 10:22:12 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA13379 for ipng-dist; Tue, 6 Oct 1998 10:16:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA13372 for ; Tue, 6 Oct 1998 10:16:36 -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 KAA24631 for ; Tue, 6 Oct 1998 10:16:34 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA10522 for ; Tue, 6 Oct 1998 10:16:34 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.8.8/8.8.8/WV1.0h) with SMTP id NAA15236; Tue, 6 Oct 1998 13:16:29 -0400 (EDT) Received: from brywasted.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA31481; Tue, 6 Oct 1998 13:16:27 -0400 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id NAA0000018997; Tue, 6 Oct 1998 13:16:28 -0400 (EDT) From: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group Message-Id: <199810061716.NAA0000018997@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: David Borman Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6593) Re: Base API : IPv4 Compatible Addresses :: and ::1 In-Reply-To: Your message of "Tue, 06 Oct 1998 10:40:07 CDT." <199810061540.KAA22841@frantic.bsdi.com> Date: Tue, 06 Oct 1998 13:16:28 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave, I think this is really excellent and appreciate your clarity. I will put this in the spec unless I hear significant objections. I have gotten offline input folks like Dave's proposal too. ----------------------------------- All four steps listed are performed, in order. Also note that the IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4-compatible addresses, and if the address is "::", HOST_NOT_FOUND MUST be returned and a query of the address not performed. Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return false for "::" and "::1". ----------------------------------- 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 Tue Oct 6 16:43:25 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA14104 for ipng-dist; Tue, 6 Oct 1998 16:38:05 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA14096 for ; Tue, 6 Oct 1998 16:37: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 QAA00047 for ; Tue, 6 Oct 1998 16:37:55 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA11743 for ; Tue, 6 Oct 1998 16:37:56 -0700 (PDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA17397; Tue, 6 Oct 1998 16:36:10 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id QAA03539; Tue, 6 Oct 1998 16:37:49 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA05700; Tue, 6 Oct 1998 16:37:48 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA49601; Tue, 6 Oct 1998 16:37:47 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA13740; Tue, 6 Oct 1998 16:37:42 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199810062337.QAA13740@bossette.engr.sgi.com> Subject: (IPng 6594) Re: Base API : IPv4 Compatible Addresses :: and ::1 To: dab@BSDI.COM (David Borman) Date: Tue, 6 Oct 1998 16:37:42 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com In-Reply-To: <199810061540.KAA22841@frantic.bsdi.com> from "David Borman" at Oct 6, 98 10:40:07 am X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David Borman wrote: > There is no reason why a query for ::1 should be *required* to fail. > A query for :: can be required to fail, but as long as ::1 is the > IPv6 loopback address, it should be able to succeed. Hmm. Is there an officially recognised `name' for ::1, such as localhost? How about localipnode? -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Oct 7 09:01:21 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA14813 for ipng-dist; Wed, 7 Oct 1998 08:56:18 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id IAA14806 for ; Wed, 7 Oct 1998 08:55:59 -0700 (PDT) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id IAA28131; Wed, 7 Oct 1998 08:55:58 -0700 (PDT) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.9.1+Sun/8.9.1) id IAA19921; Wed, 7 Oct 1998 08:53:36 -0700 (PDT) Date: Wed, 7 Oct 1998 08:53:36 -0700 (PDT) From: Mukesh Kacker Message-Id: <199810071553.IAA19921@lucknow.eng.sun.com> To: bound@zk3.dec.com, thartric@mentat.com Subject: (IPng 6596) Re: Basic API; "struct in6_addr" section needs to mention alignment issues Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >struct in6_addr { > > union { > > uint8_t _S6_b[16]; > > uint32_t _S6_w[4]; > > uint64_t _S6_l[2]; > > } _S6_un; > >}; > >#define s6_addr _S6_un._S6_b > > I can add as "EXAMPLE" the folks at the time doing Cray words did not > want it to be specified in this manner with the union. But as an > example that is fine, but we need to leave in6_addr as defined now. > Jim, If I get what you above correctly....Cray had problems with hints of "word" implying 32 bits. The hint for "long" and its size has a history too... Here is a variation on Tim's example which might avoid those issues.... It uses union field names _S6_u8, _S_u32, _S_u64 instead of those with letters derived from byte, word, long etc. [ I know...this is getting a bit into field naming issues Tim warned about :-)]. If this is controversial, feel free to drop the idea. Thus the EXAMPLE implementation variation I am suggesting would look like. struct in6_addr { union { uint8_t _S6_u8[16]; uint32_t _S6_u32[4]; uint64_t _S6_u64[2]; } _S6_un; }; #define s6_addr _S6_un._S6_u8 -Mukesh Kacker mukesh.kacker@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 Oct 7 20:08:24 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id UAA17150 for ipng-dist; Wed, 7 Oct 1998 20:04:55 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id UAA17143 for ; Wed, 7 Oct 1998 20:04:47 -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 UAA22466; Wed, 7 Oct 1998 20:04:47 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA13120; Wed, 7 Oct 1998 20:04:47 -0700 (PDT) Received: from flume.zk3.dec.com (broflume.zk3.dec.com [16.141.0.42]) by mail11.digital.com (8.8.8/8.8.8/WV1.0h) with SMTP id XAA02481; Wed, 7 Oct 1998 23:04:46 -0400 (EDT) Received: from brywasted.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA16375; Wed, 7 Oct 1998 23:04:44 -0400 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id XAA0000032448; Wed, 7 Oct 1998 23:04:43 -0400 (EDT) From: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group Message-Id: <199810080304.XAA0000032448@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Mukesh Kacker Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6598) Re: Basic API; "struct in6_addr" section needs to mention alignment issues In-Reply-To: Your message of "Wed, 07 Oct 1998 08:53:36 PDT." <199810071553.IAA19921@lucknow.eng.sun.com> Date: Wed, 07 Oct 1998 23:04:42 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sounds good to me I like the value better than the letter. 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 Fri Oct 9 09:22:38 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA18730 for ipng-dist; Fri, 9 Oct 1998 09:19:12 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA18723 for ; Fri, 9 Oct 1998 09:18: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 JAA14260 for ; Fri, 9 Oct 1998 09:18:56 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA26140 for ; Fri, 9 Oct 1998 09:18:55 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id JAA26547; Fri, 9 Oct 1998 09:16:52 -0700 (PDT) Message-Id: <3.0.5.32.19981009091437.00a3fd40@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 09 Oct 1998 09:14:37 -0700 To: narten@raleigh.ibm.com, Jeffrey Burgan From: Bob Hinden Subject: (IPng 6602) Request to Advance "Router Renumbering for IPv6" Cc: scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a Proposed Standard: Title : Router Renumbering for IPv6 Author(s) : M. Crawford Filename : draft-ietf-ipngwg-router-renum-05.txt Pages : 22 Date : 17-Sep-98 A working group last call for this document was completed on October 5, 1998. No comments were received. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- 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 Oct 9 13:56:17 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA19225 for ipng-dist; Fri, 9 Oct 1998 13:46:58 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA19218 for ; Fri, 9 Oct 1998 13:46: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 NAA06456 for ; Fri, 9 Oct 1998 13:46:47 -0700 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA20091 for ; Fri, 9 Oct 1998 13:46:46 -0700 (PDT) Received: by mail4.microsoft.com with Internet Mail Service (5.5.2232.9) id <4J7JH4A6>; Fri, 9 Oct 1998 13:46:45 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81406@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: (IPng 6603) fragmentation reassembly Date: Fri, 9 Oct 1998 13:46:43 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I was thinking recently about the provision in the spec that "An original packet is reassembled only from fragment packets that have the same Source Address, Destination Address, and Fragment Identification." In particular, I realized that since the destination & source addresses might have link-local or site-local scope, this provision is actually somewhat ambiguous. (A) If the implementation maintains a data structure of fragments pending reassembly that is per-interface, then there's no confusion about the scope of the addresses. But then suppose fragments arrive on different interfaces, fragments of a packet sent from a global source address to a global-scope multicast address where the fragments happened to be routed differently. Shouldn't they be reassembled even though they arrived on different interfaces? (B) If the implementation maintains a single data structure of fragments pending reassembly, then there's the danger of confusing fragments that really belong to different packets because the addresses involved have limited scope. (C) Or the implementation might keep a single data structure, but augment the source address, destination address, & identification with information about the interface & site that the fragment arrived on, to be used depending on the scope of the addresses involved. This makes matching fragments in the data structure more complicated. Is it "correct" to use implementation A or B? Or must a correct implementation use C? Thanks, 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 Fri Oct 9 14:35:51 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA19377 for ipng-dist; Fri, 9 Oct 1998 14:27:31 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA19370 for ; Fri, 9 Oct 1998 14:27: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 OAA18164 for ; Fri, 9 Oct 1998 14:27:17 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA16320 for ; Fri, 9 Oct 1998 14:27:17 -0700 (PDT) Received: from [171.69.199.124] (deering-office-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id OAA20222; Fri, 9 Oct 1998 14:26:49 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81406@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 9 Oct 1998 14:27:15 -0700 To: Richard Draves From: Steve Deering Subject: (IPng 6604) Re: fragmentation reassembly Cc: "'IPng List'" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:46 PM -0700 10/9/98, Richard Draves wrote: > Is it "correct" to use implementation A or B? Or must a correct > implementation use C? Rich, Certainly, neither A nor B is correct. Packets to or from a link local address may be reassembled with and only with packets arriving from the same link (possibly from different interfaces to that link). Packets to or from a site local address, where the other address is not link-local, may be reassembled with and only with packets arriving from the same site (possibly from different interfaces to that site). There are analogous restrictions on reassembling packets to scoped multicast addresses. So yes, you need a more sophisticated data structure than either one global reassembly list or one list per interface. What you need is one reassembly list for each attached "scope instance" (I need to think of a better term for this), where your scope instances are: - the global-scope instance - site instances for each site to which you are attached - link instances for each link to which you are attached plus instances for the various multicast scopes other than link, site, and global. I really need to get my "IPv6 architecture" document done one of these days.... 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 Oct 9 14:40:28 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA19436 for ipng-dist; Fri, 9 Oct 1998 14:37:36 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA19429 for ; Fri, 9 Oct 1998 14:37:26 -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 OAA21754 for ; Fri, 9 Oct 1998 14:37:24 -0700 Received: from cheetah.cs.ucla.edu (Cheetah.CS.UCLA.EDU [131.179.132.22]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA21819 for ; Fri, 9 Oct 1998 14:37:25 -0700 (PDT) Received: from localhost (pdyke@localhost) by cheetah.cs.ucla.edu (8.8.8+Sun/UCLACS-4.0) with SMTP id OAA15914 for ; Fri, 9 Oct 1998 14:37:24 -0700 (PDT) Date: Fri, 9 Oct 1998 14:37:24 -0700 (PDT) From: Paul Dyke Reply-To: Paul Dyke To: "'IPng List'" Subject: (IPng 6605) Re: fragmentation reassembly In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81406@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 9 Oct 1998, Richard Draves wrote: > I was thinking recently about the provision in the spec that "An original > packet is reassembled only from fragment packets that have the same Source > Address, Destination Address, and Fragment Identification." In particular, I > realized that since the destination & source addresses might have link-local > or site-local scope, this provision is actually somewhat ambiguous. > > (A) If the implementation maintains a data structure of fragments pending > reassembly that is per-interface, then there's no confusion about the scope > of the addresses. But then suppose fragments arrive on different interfaces, > fragments of a packet sent from a global source address to a global-scope > multicast address where the fragments happened to be routed differently. > Shouldn't they be reassembled even though they arrived on different > interfaces? Rich, this should never really happen because a node joins a multicast group on a specific interface, and multicast routing constructs a path to the multicast tree. Packets are then routed based on state in routers along the path to the receiver. However, another interesting case regarding fragmentation involves mobile IP. Since a mobile node's address changes as it moves about, if the change of address occurs while sending fragmented packets, the source address of some of the packets would be different from other packets, and reconstruction would break. Note that mobile IP defines a Home Address destination option, but technically this is part of the fragmentable part of the original packet. I suppose that a sender could place the home address option in the unfragmentable part of the packet, but I don't think this is what the mobile IP authors intended. Paul -------------------------------------------------------------------- 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 Oct 9 14:53:10 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA19473 for ipng-dist; Fri, 9 Oct 1998 14:46:15 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA19466 for ; Fri, 9 Oct 1998 14:46: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 OAA24478 for ; Fri, 9 Oct 1998 14:45:55 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA26361 for ; Fri, 9 Oct 1998 14:45:56 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id QAA24210 for ; Fri, 9 Oct 1998 16:45:55 -0500 (CDT) Message-Id: <199810092145.QAA24210@gungnir.fnal.gov> To: "'IPng List'" From: "Matt Crawford" Subject: (IPng 6606) Once in the morning does it (was Re: fragmentation reassembly) In-reply-to: Your message of Fri, 09 Oct 1998 14:27:15 PDT. Date: Fri, 09 Oct 1998 16:45:55 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What you need is one reassembly list for each attached "scope > instance" (I need to think of a better term for this), The word "scope" is groaning under its burden of meaning already. While discussing router renumbering with an implementor, I identified three completely different ones: 1. For the domain of validity and uniqueness of a unicast address there are three scopes: link-local, site-local and global. 2. For the derivation of an interface identifier there are two scopes: global and local. 3. For the bounds of a set of nodes receiving a multicast- addressed packet there are potentially 16 scopes, of which five are defined: node-local, link-local, site-local, organization-local and global. -------------------------------------------------------------------- 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 Oct 9 14:53:18 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA19496 for ipng-dist; Fri, 9 Oct 1998 14:48:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA19489 for ; Fri, 9 Oct 1998 14:48:28 -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 OAA25315 for ; Fri, 9 Oct 1998 14:48:26 -0700 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA27543 for ; Fri, 9 Oct 1998 14:48:26 -0700 (PDT) Received: by INET-IMC-01 with Internet Mail Service (5.5.2232.9) id <4J9WN8BC>; Fri, 9 Oct 1998 14:48:25 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81409@RED-MSG-50> From: Richard Draves To: "'Steve Deering'" Cc: "'IPng List'" Subject: (IPng 6607) Re: fragmentation reassembly Date: Fri, 9 Oct 1998 14:48:18 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Is it "correct" to use implementation A or B? Or must a correct > > implementation use C? > > Certainly, neither A nor B is correct. Then I'll bet there are a lot of incorrect implementations out there :-). The kind of implementation you outline is complicated - would it be possible to allow a simpler implementation (per-interface reassembly is the conservative alternative) and allow a more complicated implementation like you outline for ambitious implementations? Thanks, 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 Fri Oct 9 15:09:47 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA19537 for ipng-dist; Fri, 9 Oct 1998 15:03:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA19530 for ; Fri, 9 Oct 1998 15:03: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 PAA00774 for ; Fri, 9 Oct 1998 15:03:30 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.9.1/8.9.1) with SMTP id PAA05786 for ; Fri, 9 Oct 1998 15:03:30 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA20561; Fri, 9 Oct 98 15:03:07 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id PAA18379; Fri, 9 Oct 1998 15:03:24 -0700 Date: Fri, 9 Oct 1998 15:03:24 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199810092203.PAA18379@feller.mentat.com> To: richdr@microsoft.com, deering@cisco.com Subject: (IPng 6608) Re: fragmentation reassembly Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, > > Certainly, neither A nor B is correct. > > Packets to or from a link local address may be reassembled with > and only with packets arriving from the same link (possibly from > different interfaces to that link). > > Packets to or from a site local address, where the other address > is not link-local, may be reassembled with and only with packets > arriving from the same site (possibly from different interfaces to > that site). > > There are analogous restrictions on reassembling packets to scoped multicast > addresses. > > So yes, you need a more sophisticated data structure than either one global > reassembly list or one list per interface. What you need is one reassembly > list for each attached "scope instance" (I need to think of a better term > for this), where your scope instances are: > > - the global-scope instance > - site instances for each site to which you are attached > - link instances for each link to which you are attached > > plus instances for the various multicast scopes other than link, site, and > global. > > I really need to get my "IPv6 architecture" document done one of these days.... > I agree that B cannot work. However, A with internal forwarding mechanisms which direct fragments to the appropriate per-interface reassembly list will work. It requires the same address scope intelligence you cite above in order to implement it correctly but that intelligence will already need to exist in order to correctly implement multi-homed and multi-sited node functionality. Of course one could argue that such internal forwarding mechanisms are merely an implementation trick to achieve C. I would agree with that argument if pressed.:-) The point being that I would be unhappy to see any document start laying out in detail the data structures required to implement IPv6 reassembly. Specifying the expected result is fine. Specifying how to implement the expected result is unnecessary. There are lots of ways to skin this cat and we shouldn't start restricting all implementations to a specific style of cat skinning. Tim Hartrick -------------------------------------------------------------------- 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 Oct 9 15:10:01 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA19547 for ipng-dist; Fri, 9 Oct 1998 15:05:47 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA19540 for ; Fri, 9 Oct 1998 15:05: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 PAA01514 for ; Fri, 9 Oct 1998 15:05:31 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA07034 for ; Fri, 9 Oct 1998 15:05:31 -0700 (PDT) Received: from [171.69.199.124] (deering-office-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id PAA24761; Fri, 9 Oct 1998 15:05:29 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: References: <4D0A23B3F74DD111ACCD00805F31D8100AF81406@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 9 Oct 1998 15:05:59 -0700 To: Richard Draves From: Steve Deering Subject: (IPng 6609) Re: fragmentation reassembly Cc: "'IPng List'" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Floowing up on my own message: At 2:27 PM -0700 10/9/98, Steve Deering wrote: > What you need is one reassembly list for each attached "scope instance"... I didn't mean to imply that keeping a separate reassembly list for each scope instance was the only way to implement it. Anything that achieves the same result is OK of course. For example, you could derive the scope instance at the time of arrival (based on the arrival interface and the minimum scope of the fragment's source & destination addresses) and store an identifier for that instance with the fragment, in one node-wide list (which was your solution C, I think), or you could compute the scope instance for a stored fragment at the point in time where you check to see if it can be reassembled with a newly-arrived fragment (assuming stored fragments are tagged with arrival interface identifiers). 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 Oct 9 15:31:11 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA19594 for ipng-dist; Fri, 9 Oct 1998 15:23:23 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA19586 for ; Fri, 9 Oct 1998 15:23: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 PAA07824 for ; Fri, 9 Oct 1998 15:23:12 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA17872 for ; Fri, 9 Oct 1998 15:23:13 -0700 (PDT) Received: from [171.69.199.124] (deering-office-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id PAA27199; Fri, 9 Oct 1998 15:23:09 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199810092203.PAA18379@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 9 Oct 1998 15:23:37 -0700 To: thartric@mentat.com (Tim Hartrick) From: Steve Deering Subject: (IPng 6610) Re: fragmentation reassembly Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 3:03 PM -0700 10/9/98, Tim Hartrick wrote: > The point being that I would be unhappy to see any document start laying > out in detail the data structures required to implement IPv6 reassembly. > Specifying the expected result is fine. Specifying how to implement the > expected result is unnecessary. There are lots of ways to skin this cat > and we shouldn't start restricting all implementations to a specific style > of cat skinning. Tim, Yes, I agree 100%. I realized the error of my choice of description just after I posted my message, and you should have seen by now a follow-up message stating that any implementation is fine, as long as it results in correct behavior. The threatened architecture document won't try to prescribe implementations, but rather describe the architectural model and intended/consequential semantics in a way that (I hope) will help implementors to know *what* they need to accomplish, not *how* to accomplish it. 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 Oct 9 15:49:54 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA19681 for ipng-dist; Fri, 9 Oct 1998 15:43:53 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA19671 for ; Fri, 9 Oct 1998 15:43: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 PAA13617 for ; Fri, 9 Oct 1998 15:43:42 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA00165 for ; Fri, 9 Oct 1998 15:43:42 -0700 (PDT) Received: from [171.69.199.124] (deering-office-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id PAA29517; Fri, 9 Oct 1998 15:43:38 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81409@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 9 Oct 1998 15:44:07 -0700 To: Richard Draves From: Steve Deering Subject: (IPng 6611) Re: fragmentation reassembly Cc: "'IPng List'" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 2:48 PM -0700 10/9/98, Richard Draves wrote: > > Certainly, neither A nor B is correct. > > Then I'll bet there are a lot of incorrect implementations out there :-). > The kind of implementation you outline is complicated - would it be possible > to allow a simpler implementation (per-interface reassembly is the > conservative alternative) and allow a more complicated implementation like > you outline for ambitious implementations? Thinking about it a bit more, yes, per-interface reassembly would be mostly OK, because: - for a fragmented packet sent to a unicast address, all fragments are destined to the same interface (because a unicast address identifies a single interface, not one of a set of interfaces in the same scope instance). For a router that is a destination of a fragment, it would be necessary to associate the fragment with the interface it was destined to, regardless of which interface it actually arrived on (the notion of "internal forwarding" is one way to deal with this, as Tim suggested). - for a fragmented packet sent to a multicast address, all fragments are destined to all in-scope interfaces that are listening to that multicast address. So, if a node listens to the same multicast address on multiple interfaces, it ought to receive multiple copies of each fragment, one on each interface, and therefore it need not reply on being able to put together fragments that arrive on different interfaces. The only gotcha I can think of at the moment is if an anycast address has been assigned to multiple interfaces on the same node, in which case different fragments of the same original packet may arrive on different interfaces of that node, e.g., if routing changes occur during transmission of the fragments. As long as that's just a transient situation (i.e., not the result of intentional load-spreading or something), then reassembly failures that might occur in a "per-interface-reassembly" implementation would be just another type of loss that would be repairable by higher-layer retransmission. 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 Oct 9 15:54:05 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA19693 for ipng-dist; Fri, 9 Oct 1998 15:49:06 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA19686 for ; Fri, 9 Oct 1998 15:48: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 PAA15085 for ; Fri, 9 Oct 1998 15:48:47 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA03628 for ; Fri, 9 Oct 1998 15:48:47 -0700 (PDT) Received: from [171.69.199.124] (deering-office-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id PAA00086; Fri, 9 Oct 1998 15:48:45 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: References: <4D0A23B3F74DD111ACCD00805F31D8100AF81409@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 9 Oct 1998 15:49:15 -0700 To: Richard Draves From: Steve Deering Subject: (IPng 6612) Re: fragmentation reassembly Cc: "'IPng List'" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 3:44 PM -0700 10/9/98, Steve Deering wrote: > ..., and therefore it need not reply on being able to > put together fragments that arrive on different interfaces. Change "reply on" to "rely on". 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 Oct 9 16:33:40 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA19735 for ipng-dist; Fri, 9 Oct 1998 16:29:45 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id QAA19728 for ; Fri, 9 Oct 1998 16:29:34 -0700 (PDT) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id QAA15709; Fri, 9 Oct 1998 16:29:32 -0700 (PDT) Date: Fri, 9 Oct 1998 16:29:32 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6613) Re: fragmentation reassembly To: Steve Deering Cc: Richard Draves , "'IPng List'" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Certainly, neither A nor B is correct. Steve, Alternative A (per interface reassembly) would be correct if an implementation followed the "strong end-system model". Are you asserting that the IPv6 archiecture uses/requires the "weak ES model"? (I haven't seen such a requirement stated before - it would be good if we can nail this down in the architecture.) 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 Oct 9 17:11:54 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA19809 for ipng-dist; Fri, 9 Oct 1998 17:04:33 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA19802 for ; Fri, 9 Oct 1998 17:04: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 RAA04644 for ; Fri, 9 Oct 1998 17:04:22 -0700 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA10253 for ; Fri, 9 Oct 1998 17:04:23 -0700 (PDT) Received: by INET-IMC-01 with Internet Mail Service (5.5.2232.9) id <4J9W3H40>; Fri, 9 Oct 1998 17:04:23 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81411@RED-MSG-50> From: Richard Draves To: "'Erik Nordmark'" , Steve Deering Cc: "'IPng List'" Subject: (IPng 6614) Re: fragmentation reassembly Date: Fri, 9 Oct 1998 17:04:22 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Alternative A (per interface reassembly) would be correct if an > implementation followed the "strong end-system model". > > Are you asserting that the IPv6 archiecture uses/requires the > "weak ES model"? (I haven't seen such a requirement stated > before - it would > be good if we can nail this down in the architecture.) In my example I used a multicast destination address in an attempt to bypass this issue. I prefer the strong model, so I hope if this is nailed down it's an allowed alternative! I think the strong model is conceptually simpler when limited scope addresses are considered and when IPsec is considered. (Security policies are conceptually per-interface.) 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 Fri Oct 9 17:17:01 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA19830 for ipng-dist; Fri, 9 Oct 1998 17:13:32 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA19823 for ; Fri, 9 Oct 1998 17:13: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 RAA06425; Fri, 9 Oct 1998 17:13:19 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA13586; Fri, 9 Oct 1998 17:13:20 -0700 (PDT) Received: from [171.69.199.124] (deering-office-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id RAA10418; Fri, 9 Oct 1998 17:13:17 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: References: "Your message with ID" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 9 Oct 1998 17:13:47 -0700 To: Erik Nordmark From: Steve Deering Subject: (IPng 6615) Re: fragmentation reassembly Cc: Richard Draves , "'IPng List'" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 4:29 PM -0700 10/9/98, Erik Nordmark wrote: > Alternative A (per interface reassembly) would be correct if an > implementation followed the "strong end-system model". I'm not sure that's entirely true, because of anycast addresses (see previous message). > Are you asserting that the IPv6 archiecture uses/requires the > "weak ES model"? (I haven't seen such a requirement stated before - it would > be good if we can nail this down in the architecture.) There are actually two separable properties that the strong/weak model for multihomed hosts pertains to: (1) may a host originate a packet who source address does not belong to the originating interface? (strong: NO, weak: YES) (2) may a host accept a packet destined to one of its own addresses if the arrival interface is not the one to which that address belongs? (strong: NO, weak: YES) With regard to (1), I think we need to accept the weak model to allow, for example, a host attached to the receive end of a unidirectional link (like a direct-broadcast satellite channel) to answer a "ping" addressed to that interface. In that case, the source address of the ping reply needs to be the address of the arrival interface, but because that interface is unidirectional, the reply has to originate on a different interface. On the other hand, a problem with the weak model for this property is that it breaks ICMP Redirects, so one wants to discourage "exploiting the weakness". Therefore, with regard to property (1), I think the IPv6 model should be: "the source address SHOULD belong to the originating interface", rather than "MUST belong". With regard to (2), which I think is the basis of your question, the arrival of a packet at an end host on an interface other than one belonging to the destination address indicates either an error in the routing system (including Neighbor Discovery as part of the routing system), or manual configuration of a neighbor to force delivery to the "wrong" interface. I don't feel it is necessary to insist on the strong model here, because violation either won't happen or will happen because some network administrator configured to happen. So, as one who used to argue vigorously for the strong model, I have now "converted" to support the weak model, FOR UNICAST. Multicast, on the other hand, MUST use the strong model, but that's a subject for another message, someday... Steve (now departing for the weekend -- offline till Sunday night) -------------------------------------------------------------------- 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 Oct 9 17:27:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA19852 for ipng-dist; Fri, 9 Oct 1998 17:22:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA19845 for ; Fri, 9 Oct 1998 17:21:52 -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 RAA08209 for ; Fri, 9 Oct 1998 17:21:49 -0700 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA16970 for ; Fri, 9 Oct 1998 17:21:48 -0700 (PDT) Received: by INET-IMC-05 with Internet Mail Service (5.5.2232.9) id <41D6ZHJN>; Fri, 9 Oct 1998 17:21:48 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81413@RED-MSG-50> From: Richard Draves To: "'Steve Deering'" Cc: "'IPng List'" , Erik Nordmark Subject: (IPng 6616) Re: fragmentation reassembly Date: Fri, 9 Oct 1998 17:21:45 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > With regard to (1), I think we need to accept the weak model to allow, > for example, a host attached to the receive end of a > unidirectional link I think it would be tricky to get unidirectional links to work properly. Consider Neighbor Unreachability Detection probes sent with link-local addresses. The reply can't be sent using a different link. Is IPv6 intended to support unidirectional links? 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 Fri Oct 9 17:30:11 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA19873 for ipng-dist; Fri, 9 Oct 1998 17:27:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA19866 for ; Fri, 9 Oct 1998 17:27: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 RAA09399; Fri, 9 Oct 1998 17:27:14 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA19189; Fri, 9 Oct 1998 17:27:16 -0700 (PDT) Received: from [171.69.199.124] (deering-office-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id RAA11918; Fri, 9 Oct 1998 17:27:11 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81411@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 9 Oct 1998 17:27:40 -0700 To: Richard Draves From: Steve Deering Subject: (IPng 6617) Re: fragmentation reassembly Cc: "'Erik Nordmark'" , "'IPng List'" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:04 PM -0700 10/9/98, Richard Draves wrote: > I prefer the strong model, so I hope if this is nailed down it's an allowed > alternative! I think the strong model is conceptually simpler when limited > scope addresses are considered and when IPsec is considered. Any "weakness" that would be allowed would not be permitted to violate scope boundaries, i.e., any flexibility in the choice of interface for originating and/or accepting a packet would be limited to the subset of interfaces belonging to the same scope instance, as determined by the scope of the addresses in the packet. Steve (NOW I'm leaving!) -------------------------------------------------------------------- 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 Oct 9 17:35:41 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA19894 for ipng-dist; Fri, 9 Oct 1998 17:30:47 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA19887 for ; Fri, 9 Oct 1998 17:30: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 RAA10033; Fri, 9 Oct 1998 17:30:30 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA20591; Fri, 9 Oct 1998 17:30:29 -0700 (PDT) Received: from [171.69.199.124] (deering-office-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id RAA12234; Fri, 9 Oct 1998 17:30:28 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81413@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 9 Oct 1998 17:30:57 -0700 To: Richard Draves From: Steve Deering Subject: (IPng 6618) Re: fragmentation reassembly Cc: "'IPng List'" , Erik Nordmark Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:21 PM -0700 10/9/98, Richard Draves wrote: > I think it would be tricky to get unidirectional links to work properly. > Consider Neighbor Unreachability Detection probes sent with link-local > addresses. The reply can't be sent using a different link. We already recognized that not all parts of ND are applicable to all types of links. > Is IPv6 intended to support unidirectional links? It would be nice if we could answer "yes" to that question. Steve (Lemme outa here!) -------------------------------------------------------------------- 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 Oct 9 17:47:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA19916 for ipng-dist; Fri, 9 Oct 1998 17:40:04 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA19909 for ; Fri, 9 Oct 1998 17:39: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 RAA12147 for ; Fri, 9 Oct 1998 17:39:50 -0700 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA24693 for ; Fri, 9 Oct 1998 17:39:51 -0700 (PDT) Received: by INET-IMC-05 with Internet Mail Service (5.5.2232.9) id <41D6Z2CM>; Fri, 9 Oct 1998 17:39:51 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81414@RED-MSG-50> From: Richard Draves To: "'Paul Dyke'" , "'IPng List'" Subject: (IPng 6619) Re: fragmentation reassembly Date: Fri, 9 Oct 1998 17:39:48 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > However, another interesting case regarding fragmentation > involves mobile > IP. Since a mobile node's address changes as it moves about, > if the change > of address occurs while sending fragmented packets, the > source address of > some of the packets would be different from other packets, and > reconstruction would break. Note that mobile IP defines a Home Address > destination option, but technically this is part of the > fragmentable part > of the original packet. I suppose that a sender could place the home > address option in the unfragmentable part of the packet, but > I don't think > this is what the mobile IP authors intended. I haven't read the mobility spec, but surely fragment reassembly should always be based on the source address in the IPv6 header? It would be up to the mobile node to send fragments with a consistent source address. This does not sound like a difficult requirement. 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 Sat Oct 10 05:31:39 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA20171 for ipng-dist; Sat, 10 Oct 1998 05:26:02 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA20164 for ; Sat, 10 Oct 1998 05:25:52 -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 FAA06364 for ; Sat, 10 Oct 1998 05:25:50 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id FAA03896 for ; Sat, 10 Oct 1998 05:25:49 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id MA07203; Sat, 10 Oct 1998 22:25:45 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: IPng List Subject: (IPng 6620) Re: fragmentation reassembly In-Reply-To: Your message of "Fri, 09 Oct 1998 17:13:47 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 10 Oct 1998 22:25:45 +1000 Message-Id: <1370.908022345@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 9 Oct 1998 17:13:47 -0700 From: Steve Deering Message-ID: | With regard to (1), I think we need to accept the weak model to allow, | for example, a host attached to the receive end of a unidirectional link You don't need unidirectional links to see this need. It is entirely reasonable for the only known route from a multihomed host to many destinations (including 'default') be out one particular interface. In fact, I'd think that's a common case. When a node is replying to an incoming request, it needs to send out the interface which it believes will get the packet to the destination - regardless of what the source address happens to be. It also normally doesn't get to choose the source address, that is generally constrained by the destination address of the packet that was received. The interface the packet was received over need also have no relationship with the one it will reply through. Ever expecting that the source address of a packet will be related to the interface through which the packet is sent is folly. It is possible to construct administrative regimes where this will be true - but that's for the administrator of the system not for the implementor of its software. The software must have no restrictions in this area (nb: "no restrictions", which does not mean that the default source address, where there is no reason to use any particular one, should not be that of the outgoing interface). | With regard to (2), [...] | I don't feel it is necessary to insist on the strong model here, I agree, but at least this one is one where an implementation wouldn't be terminally broken by this choice (unlike the previous one). An implementation that implements the strong model for packet reception will limit the administrator's choices as to how the implementation is deployed, though in most cases, the admin will probably never see the difference. That is, I don't see that we need to prohibit the strong model (for packet reception) either, which would be the more likely question, not whether we need to insist upon it. 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 Sat Oct 10 16:25:57 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA20297 for ipng-dist; Sat, 10 Oct 1998 16:22:40 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA20290 for ; Sat, 10 Oct 1998 16:22: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 QAA14434 for ; Sat, 10 Oct 1998 16:22:29 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA18370 for ; Sat, 10 Oct 1998 16:22:29 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id XAA04078 for ; Sat, 10 Oct 1998 23:20:22 GMT Message-Id: <199810102320.XAA04078@inner.net> To: ipng@sunroof.eng.sun.com Subject: (IPng 6621) Results on Chicago hallway BoF on ioctls X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Sat, 10 Oct 1998 19:21:17 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There was a hallway BoF session at the Chicago IETF in which several implementors got together and mostly agreed on definitions for the basic IPv6 interface address ioctls() so that we could have some interoperability. These results represent no standard or specification of any form; they're just what we thought would be good to implement and will hopefully be what *is* implemented in our code bases. Productive comments are welcome. Note that the "l" means "large" or "large address". struct if_laddrreq { char iflr_name[IF_NAMSIZ]; unsigned int flags; unsigned int prefixlen; /* Ed. note: In my notes, this is at the end; I moved it here for alignment reasons. I don't think we ever discussed this */ struct sockaddr_storage addr; struct sockaddr_storage dstaddr; } #define SIOCALIFADDR -- add large interface address #define SIOCGLIFADDR -- get large interface address #define SIOCDLIFADDR -- del large interface address /* Ed. note: We talked about this, defined it, but never named it */ #define IFLR_PREFIX -- if present in flags, addr contains a prefix SIOCALIFADDR - kernel is expected to fill in the host part of the address (e.g., the EUI-64) SIOC{G,D}LIFADDR - kernel is expected to match an interface address on that prefix (or return ESRCH) -Craig PS: Sorry it took so long for me to post my notes; it got buried under a pile of stuff to do, not the least of which is an implementation ;) -------------------------------------------------------------------- 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 Sun Oct 11 07:41:27 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA20483 for ipng-dist; Sun, 11 Oct 1998 07:38:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA20475 for ; Sun, 11 Oct 1998 07:38: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 HAA13612; Sun, 11 Oct 1998 07:38:15 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA11492; Sun, 11 Oct 1998 07:38:15 -0700 (PDT) Received: from flume.zk3.dec.com (flume.zk3.dec.com [16.140.112.3]) by mail11.digital.com (8.8.8/8.8.8/WV1.0h) with SMTP id KAA27064; Sun, 11 Oct 1998 10:38:11 -0400 (EDT) Received: from brywasted.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA09794; Sun, 11 Oct 1998 10:38:10 -0400 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id KAA0000001063; Sun, 11 Oct 1998 10:38:10 -0400 (EDT) From: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group Message-Id: <199810111438.KAA0000001063@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Steve Deering Cc: Erik Nordmark , Richard Draves , "'IPng List'" Subject: (IPng 6622) Re: fragmentation reassembly In-Reply-To: Your message of "Fri, 09 Oct 1998 17:13:47 PDT." Date: Sun, 11 Oct 1998 10:38:10 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >> Alternative A (per interface reassembly) would be correct if an >> implementation followed the "strong end-system model". >I'm not sure that's entirely true, because of anycast addresses (see >previous message). The anycast model by definition is the weak model IMO. Also is it time to show anycast addresses are in fact needed by hosts or at least server machines for networking? >> Are you asserting that the IPv6 archiecture uses/requires the >> "weak ES model"? (I haven't seen such a requirement stated before - it would >> be good if we can nail this down in the architecture.) >There are actually two separable properties that the strong/weak model for >multihomed hosts pertains to: First nothing in anyones vision of what the IPv6 architecture is or is not should break implementations. Steve whats up with your document I assume your doing some kind of FAQ? I am building one too and it will go to the masses soon!!!! (1) may a host originate a packet who source address does not belong to the originating interface? (strong: NO, weak: YES) I would say the default is strong but we cannot disallow the weak. (2) may a host accept a packet destined to one of its own addresses if the arrival interface is not the one to which that address belongs? (strong: NO, weak: YES) I would say a host must accept a packet if it has that address within its node. So I believe the entire discussion is purely academic and customers require that a product must permit both behaviors to be flexible for the consumer. Where it becomes relevant is to resolve the issues Richard brought up about fragement/reassembly. But that was because of those darn scopes again. But here the academic discussion can be useful. Lets be careful here what this discussion is depicting and not let it be misleading that we will try to nail down a weak or strong model consensus will never happen in the IETF community. It is like EIDs vs Locators discussion. >With regard to (1), I think we need to accept the weak model to allow, >for example, a host attached to the receive end of a unidirectional link >(like a direct-broadcast satellite channel) to answer a "ping" addressed >to that interface. In that case, the source address of the ping reply >needs to be the address of the arrival interface, but because that >interface is unidirectional, the reply has to originate on a different >interface. On the other hand, a problem with the weak model for this >property is that it breaks ICMP Redirects, so one wants to discourage >"exploiting the weakness". Therefore, with regard to property (1), I >think the IPv6 model should be: "the source address SHOULD belong to >the originating interface", rather than "MUST belong". I agree with you on this one. Where are these SHOULDs and MUSTs going to exist? Again my question to you what is this document? Please respond to this as if your going to build a spec that affects the very nature of IPv6 implementations then I would like to know that and I am sure other implementors will to? I will say more if the answer is yes? >With regard to (2), which I think is the basis of your question, the arrival >of a packet at an end host on an interface other than one belonging to the >destination address indicates either an error in the routing system >(including Neighbor Discovery as part of the routing system), or >manual configuration of a neighbor to force delivery to the "wrong" >interface. I don't feel it is necessary to insist on the strong model >here, because violation either won't happen or will happen because some >network administrator configured to happen. >So, as one who used to argue vigorously for the strong model, I have >now "converted" to support the weak model, FOR UNICAST. Multicast, on the >other hand, MUST use the strong model, but that's a subject for another >message, someday... At the end of the day we will support what the customer wants as both models are needed depending on the reqs of the network for the customer. But the point of all of this is to address what Richard found from implementing frag/reassem code and testing it. The answer is if you can get it work with our scoped addresses do so. If you can't then tell the WG. Other than that it is not an IETF issue I can see at this point but an implementation issue for the IPv6 architecture which permits an uncanny scoping of addresses which will clearly be a nightmare for implementation deployment. /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 Sun Oct 11 20:27:57 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id UAA20658 for ipng-dist; Sun, 11 Oct 1998 20:23:36 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id UAA20651 for ; Sun, 11 Oct 1998 20:23:28 -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 UAA07642 for ; Sun, 11 Oct 1998 20:23:27 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA05203 for ; Sun, 11 Oct 1998 20:23:28 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.8.8/8.8.8/WV1.0h) with SMTP id XAA22577; Sun, 11 Oct 1998 23:23:27 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA22390; Sun, 11 Oct 1998 23:23:18 -0400 Message-Id: <199810120323.AA22390@quarry.zk3.dec.com> To: deering@cisco.com, hinden@ipsilon.com Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 6624) IPv6 Base API ready for Last Call and Replace RFC 2133 Date: Sun, 11 Oct 1998 23:23:18 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve and Bob, I have just submitted draft-ietf-ipngwg-bsd-api-new-02.txt to the Internet IETF ID folks to put out on our internet-drafts dirs. Also you and the WG can get a copy now of the 02.txt spec at: sipper.pa-x.dec.com (cd to pub dir) At this time we would like in the WG to use this draft to replace RFC 2133 as the Base API Spec. We have just spent two weeks putting these final changes and clarifications into the draft before this submit. We would like to ask you to do a Last Call if necessary and get this spec to replace RFC 2133 as a new Informational RFC on behalf of the IPng WG. 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 Mon Oct 12 09:04:33 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA21298 for ipng-dist; Mon, 12 Oct 1998 08:58:53 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA21290 for ; Mon, 12 Oct 1998 08:58: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 IAA00886 for ; Mon, 12 Oct 1998 08:58:41 -0700 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA03291 for ; Mon, 12 Oct 1998 08:58:36 -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 AAA22090 for ; Tue, 13 Oct 1998 00:58:17 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 6625) TCP6 to anycast address 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 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <22083.908207888.0@coconut.itojun.org> Date: Tue, 13 Oct 1998 00:58:17 +0900 Message-ID: <22085.908207897@coconut.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22083.908207888.1@coconut.itojun.org> Content-Transfer-Encoding: 7bit I've submitted an I-D about TCP6 and anycast address. This is related to my question in: >Subject: (IPng 6349) error to TCP6 toward anycast address? >From: Jun-ichiro itojun Itoh >Date: Thu, 27 Aug 1998 00:29:31 +0900 >Message-ID: <550.904145371@turmeric.itojun.org> Comments and suggestions are welcome, thanks! itojun@kame.net itojun@iijlab.net itojun@itojun.org jun-ichiro itoh ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Return-Path: adm@ietf.org Return-Path: Received: from ietf.org (odin.ietf.org [132.151.1.176]) by coconut.itojun.org (8.8.8+3.0Wbeta12/3.6W) with ESMTP id AAA21955 for ; Tue, 13 Oct 1998 00:54:26 +0900 (JST) Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id LAA22517 for ietf-123-outbound.10@ietf.org; Mon, 12 Oct 1998 11:35:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA20547 for ; Mon, 12 Oct 1998 10:39:48 -0400 (EDT) Message-Id: <199810121439.KAA20547@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-itojun-ipv6-tcp-to-anycast-00.txt Date: Mon, 12 Oct 1998 10:39:48 -0400 Sender: cclark@ns.cnri.reston.va.us X-Filter: mailagent [version 3.0 PL56] for itojun@itojun.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Disconnecting TCP connection toward IPv6 anycast address Author(s) : J. Itoh Filename : draft-itojun-ipv6-tcp-to-anycast-00.txt Pages : 4 Date : 09-Oct-98 IPv6 specification implicitly disallows TCP connection toward IPv6 anycast address. However, if such a connection request happens by mistake, currently there is no way to report the incident to the originator of the TCP connection. The document tries to define a way to disconnect TCP connections made toward IPv6 anycast addresses. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-itojun-ipv6-tcp-to-anycast-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-itojun-ipv6-tcp-to-anycast-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-itojun-ipv6-tcp-to-anycast-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. --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: <19981009124316.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-itojun-ipv6-tcp-to-anycast-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-itojun-ipv6-tcp-to-anycast-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981009124316.I-D@ietf.org> --OtherAccess-- --NextPart-- ------- =_aaaaaaaaaa0-- -------------------------------------------------------------------- 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 Oct 12 10:48:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA21635 for ipng-dist; Mon, 12 Oct 1998 10:42:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA21628 for ; Mon, 12 Oct 1998 10:42:12 -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 KAA06214 for ; Mon, 12 Oct 1998 10:42:05 -0700 Received: from send1d.yahoomail.com (send1d.yahoomail.com [205.180.60.48]) by earth.sun.com (8.9.1/8.9.1) with SMTP id KAA13665 for ; Mon, 12 Oct 1998 10:42:06 -0700 (PDT) Message-ID: <19981012174143.1881.rocketmail@send1d.yahoomail.com> Received: from [138.111.39.14] by send1d; Mon, 12 Oct 1998 10:41:43 PDT Date: Mon, 12 Oct 1998 10:41:43 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6626) Re: TCP6 to anycast address To: Jun-ichiro itojun Itoh , ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All, I was reading this draft and I have one quick question. I am not able to understand how the solution proposed in this draft is going to solve problem from the user's view. User is always hidden from the fact that the IP address he is trying to reach is any cast address. So he will try to establish connection again. So there will be lot of ICMP error messages. The possible solution can be after getting ICMP error message for X no. of times update ur local ANYCAST address cache. Please correct me If I am wrong. Thanks in advance -Raghu. == ------------------------------------------------------------ _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.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 Mon Oct 12 17:12:24 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA22353 for ipng-dist; Mon, 12 Oct 1998 17:05:03 -0700 (PDT) Received: from kebe.eng.sun.com (kebe [129.146.86.51]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id RAA22346 for ; Mon, 12 Oct 1998 17:04:51 -0700 (PDT) Received: (from danmcd@localhost) by kebe.eng.sun.com (8.9.1b+Sun/8.9.0) id RAA00443 for ipng@sunroof; Mon, 12 Oct 1998 17:04:03 -0700 (PDT) From: Dan McDonald Message-Id: <199810130004.RAA00443@kebe.eng.sun.com> Subject: (IPng 6627) LDAP draft problem... (fwd from IPsec) To: ipng@sunroof.eng.sun.com Date: Mon, 12 Oct 1998 17:04:02 -0700 (PDT) X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I should have dropped this off on this list too. The draft in question is: draft-ietf-ipsec-vpn-policy-schema-00.txt It blatantly doesn't learn any lessons about colons and IPv6 addresses. Dan ===================== (Cut up to and including here.) ===================== Forwarded message: From owner-ipsec@portal.ex.tis.com Mon Oct 12 10:24:11 1998 Delivery-Date: Mon, 12 Oct 1998 10:24:11 -0700 From: Dan McDonald Message-Id: <199810121717.KAA07557@kebe.eng.sun.com> Subject: LDAP draft problem... To: ipsec@tis.com Date: Mon, 12 Oct 1998 10:17:16 -0700 (PDT) X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk You've missed something important... > NAME SourceIPAddressRange > DESC Source IP addresses to which the policy applies > EQUALITY caseExactIA5Match > SYNTAX IA5String > SINGLE-VALUED > FORMAT SourceIPAddressRange is of the following form: three colon (':') > separated strings denoting a range of IP addresses. The > following formats are currently defined > > > 1:: > The IP v4 address is in dotted decimal format. The > CIDRPrefixLength is the number of unmasked leading bits. > A packet matches the condition if the unmasked > bits on the packet are identical to the unmasked bits on the > condition. > > > 2:: What about IPv6 addresses? Using a colon as a separator will break in the presence of IPv6 addresses. I don't even see IPv6 addressed in this document at all. Dan -------------------------------------------------------------------- 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 Oct 12 19:38:45 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA22495 for ipng-dist; Mon, 12 Oct 1998 19:33:28 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id TAA22485 for ; Mon, 12 Oct 1998 19:33: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 TAA08153 for ; Mon, 12 Oct 1998 19:33:13 -0700 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA04879 for ; Mon, 12 Oct 1998 19:33:13 -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 LAA00331; Tue, 13 Oct 1998 11:33:07 +0900 (JST) To: "Raghu V.V.J Vadapalli" cc: ipng@sunroof.eng.sun.com In-reply-to: iprsvp's message of Mon, 12 Oct 1998 10:41:43 MST. <19981012174143.1881.rocketmail@send1d.yahoomail.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 6628) Re: TCP6 to anycast address Date: Tue, 13 Oct 1998 11:33:07 +0900 Message-ID: <327.908245987@coconut.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I am not able to understand how the solution proposed in this >draft is going to solve problem from the user's view. >User is always hidden from the fact that the IP address he is >trying to reach is any cast address. So he will try to establish >connection again. So there will be lot of ICMP error messages. > >The possible solution can be after getting ICMP error message for >X no. of times update ur local ANYCAST address cache. I believe that hosts should NOT distinguish anycast addresses from (non-anycast) unicast addresses. So I did not take "anycast cache" approach. I think only routers (which have anycast address on their interfaces) should perform something special about tcp- toward-anycast. It should be also noted that, the restriction imposed on anycast address may be changed in the future (RFC2373 section 2.6 says "Until more experience has been gained ..."). If this kind of situation happens we may have to remove special treatment about tcp-toward-anycast. In my approach only routers have to be modified (and those routers must be updated for new anycast handling, anyway). For user-friendliness, we may be able to modify tcp stack and telnet applicaton, so that kernel will pass some special error code if "address unreach" ICMPv6 is received. I believe this is implementation issue (it is matter of extra functionality), not an protocol issue. itojun@kame.net jun-ichiro itoh -------------------------------------------------------------------- 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 Oct 13 02:47:54 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id CAA22656 for ipng-dist; Tue, 13 Oct 1998 02:43:19 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id CAA22649 for ; Tue, 13 Oct 1998 02:43: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 CAA24126; Tue, 13 Oct 1998 02:43:10 -0700 Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA04911; Tue, 13 Oct 1998 02:43:09 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id KAA45132; Tue, 13 Oct 1998 10:43:06 +0100 Received: from hursley.ibm.com (carpenterb.hursley.ibm.com [9.20.22.153]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id KAA18236; Tue, 13 Oct 1998 10:43:05 +0100 (BST) Message-ID: <36232098.266A269@hursley.ibm.com> Date: Tue, 13 Oct 1998 10:42:48 +0100 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Dan McDonald CC: ipng@sunroof.eng.sun.com Subject: (IPng 6629) Re: LDAP draft problem... (fwd from IPsec) References: <199810130004.RAA00443@kebe.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Right, I spotted this in a draft schema a few weeks ago and told the authors. I think we have caught it in time, and I'm sure the IESG will lean on the proposed Policy WG to avoid this trap. Brian Dan McDonald wrote: > > I should have dropped this off on this list too. The draft in question is: > > draft-ietf-ipsec-vpn-policy-schema-00.txt > > It blatantly doesn't learn any lessons about colons and IPv6 addresses. > > Dan > > ===================== (Cut up to and including here.) ===================== > Forwarded message: > >From owner-ipsec@portal.ex.tis.com Mon Oct 12 10:24:11 1998 > Delivery-Date: Mon, 12 Oct 1998 10:24:11 -0700 > From: Dan McDonald > Message-Id: <199810121717.KAA07557@kebe.eng.sun.com> > Subject: LDAP draft problem... > To: ipsec@tis.com > Date: Mon, 12 Oct 1998 10:17:16 -0700 (PDT) > X-Legal-Disclaimer: Please note that the information being provided does not > constitute a warranty or a modification of any agreement > you may have with Sun Microsystems, Inc., its subsidiaries > or its customers. > X-Mailer: ELM [version 2.4 PL25] > MIME-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Sender: owner-ipsec@ex.tis.com > Precedence: bulk > > You've missed something important... > > > NAME SourceIPAddressRange > > DESC Source IP addresses to which the policy applies > > EQUALITY caseExactIA5Match > > SYNTAX IA5String > > SINGLE-VALUED > > FORMAT SourceIPAddressRange is of the following form: three colon (':') > > separated strings denoting a range of IP addresses. The > > following formats are currently defined > > > > > > 1:: > > The IP v4 address is in dotted decimal format. The > > CIDRPrefixLength is the number of unmasked leading bits. > > A packet matches the condition if the unmasked > > bits on the packet are identical to the unmasked bits on the > > condition. > > > > > > 2:: > > > > What about IPv6 addresses? Using a colon as a separator will break in the > presence of IPv6 addresses. I don't even see IPv6 addressed in this document > at all. > > Dan > > -------------------------------------------------------------------- > 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 Oct 13 03:57:04 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id DAA22766 for ipng-dist; Tue, 13 Oct 1998 03:54:06 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id DAA22759 for ; Tue, 13 Oct 1998 03:53: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 DAA28980 for ; Tue, 13 Oct 1998 03:53:56 -0700 Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.161]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA24473 for ; Tue, 13 Oct 1998 03:53:48 -0700 (PDT) Received: from cauchy.cs.uni-bonn.de (cauchy.cs.uni-bonn.de [131.220.4.169]) by theory.cs.uni-bonn.de (8.8.8/8.8.8) with ESMTP id MAA12663 for ; Tue, 13 Oct 1998 12:53:42 +0200 (MET DST) Received: (ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.6.9) id MAA27674; Tue, 13 Oct 1998 12:53:41 +0200 (MET DST) Message-ID: <19981013125340.C27595@cs.uni-bonn.de> Date: Tue, 13 Oct 1998 12:53:40 +0200 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Subject: (IPng 6630) IPv6 over ARCnet draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [I thought I had already sent this message from home, but can't spot it, neither in the Archive nor in my mail folders here at work. If you already read it, I apologize for the inconvenience.] I finally found the time to write a new version of the IPv6 over ARCnet draft, based on the old one and lots of input mostly by Matt Crawford. It is available as ftp://ftp.isi.edu/internet-drafts/draft-souvatzis-ipv6-arcnet-04.txt Comments are welcome. If the working group wants to pick it up, feel free. Regards, Ignatios Souvatzis -------------------------------------------------------------------- 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 Oct 13 07:30:45 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA22862 for ipng-dist; Tue, 13 Oct 1998 07:27:09 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA22855 for ; Tue, 13 Oct 1998 07:26: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 HAA24119 for ; Tue, 13 Oct 1998 07:26:53 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA20125 for ; Tue, 13 Oct 1998 07:26:52 -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 KAA24979; Tue, 13 Oct 1998 10:26:49 -0400 (EDT) Message-Id: <199810131426.KAA24979@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6631) I-D ACTION:draft-ietf-ipngwg-bsd-api-new-02.txt Date: Tue, 13 Oct 1998 10:26:44 -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 : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens Filename : draft-ietf-ipngwg-bsd-api-new-02.txt Pages : 33 Date : 12-Oct-98 The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-bsd-api-new-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-bsd-api-new-02.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-bsd-api-new-02.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: <19981012141118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-new-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-bsd-api-new-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981012141118.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 Tue Oct 13 09:58:15 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA23067 for ipng-dist; Tue, 13 Oct 1998 09:48:29 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA23060 for ; Tue, 13 Oct 1998 09:48: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 JAA01425 for ; Tue, 13 Oct 1998 09:48:16 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA23028 for ; Tue, 13 Oct 1998 09:48:15 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id LAA09641; Tue, 13 Oct 1998 11:48:10 -0500 (CDT) Message-Id: <199810131648.LAA09641@gungnir.fnal.gov> To: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 6632) Re: IPv6 over ARCnet draft In-reply-to: Your message of Tue, 13 Oct 1998 12:53:40 +0200. <19981013125340.C27595@cs.uni-bonn.de> Date: Tue, 13 Oct 1998 11:48:06 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > ftp://ftp.isi.edu/internet-drafts/draft-souvatzis-ipv6-arcnet-04.txt > > Comments are welcome. If the working group wants to pick it up, feel free. I suggest that the chairs issue a WG last call on this or take preliminary action toward that end. ARCNET does exist in the real world and should not be neglected. 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 Tue Oct 13 12:28:44 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA23279 for ipng-dist; Tue, 13 Oct 1998 12:17:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA23272 for ; Tue, 13 Oct 1998 12:17:21 -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 MAA19748 for ; Tue, 13 Oct 1998 12:17:16 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA07825 for ; Tue, 13 Oct 1998 12:17:18 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id MAA13762; Tue, 13 Oct 1998 12:17:17 -0700 (PDT) Message-Id: <3.0.5.32.19981013121512.008d5490@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 13 Oct 1998 12:15:12 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6633) W.G. Last Call on "A Method for the Transmission of IPv6 Packets over ARCnet Networks" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as a Proposed Standard: Title : A Method for the Transmission of IPv6 Packets over ARCnet Networks. Author(s) : I. Souvatzis Filename : draft-souvatzis-ipv6-arcnet-04.txt Pages : 6 Date : 28-Sep-98 Please send substantive comments to the ipng mailing list, and minor editorial comments to the author. This last call period will end two week from today on October 27, 1998. Bob Hinden / Steve Deering -------------------------------------------------------------------- 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 Oct 15 08:09:43 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA24878 for ipng-dist; Thu, 15 Oct 1998 08:06:16 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA24871 for ; Thu, 15 Oct 1998 08:05: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 IAA19046 for ; Thu, 15 Oct 1998 08:05:51 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA14316 for ; Thu, 15 Oct 1998 08:05:51 -0700 (PDT) Received: from spruce.iprg.nokia.com (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id PAA23050; Thu, 15 Oct 1998 15:04:11 GMT Message-Id: <3.0.5.32.19981015080202.0088fbc0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 15 Oct 1998 08:02:02 -0700 To: narten@raleigh.ibm.com, Jeffrey Burgan From: Bob Hinden Subject: (IPng 6635) Draft: Request to Advance "DNS Extensions to Support IP Version 6" Cc: hinden@iprg.nokia.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a Proposed Standard: Title : DNS Extensions to Support IP Version 6 Author(s) : M. Crawford, C. Huitema, S. Thomson Filename : draft-ietf-ipngwg-dns-lookups-02.txt Pages : 15 Date : 15-Sep-98 A working group last call for this document was completed on October 2, 1998. Comments received regarding transitioning from the current AAAA scheme to this scheme have been discussed and are thought to be manageable. Comments received during the last call regarding procedural issue were responded to by the w.g. chairs. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- 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 Oct 15 10:06:22 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA25075 for ipng-dist; Thu, 15 Oct 1998 09:58:19 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA25068 for ; Thu, 15 Oct 1998 09:58:05 -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 JAA25800 for ; Thu, 15 Oct 1998 09:57:50 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA29904 for ; Thu, 15 Oct 1998 09:57:38 -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 MAA14852; Thu, 15 Oct 1998 12:57:14 -0400 (EDT) Message-Id: <199810151657.MAA14852@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 6636) Last Call: Router Renumbering for IPv6 to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 15 Oct 1998 12:57:14 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider Router Renumbering for IPv6 as 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 October 29, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-05.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 Thu Oct 15 16:27:27 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA25537 for ipng-dist; Thu, 15 Oct 1998 16:12:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA25530 for ; Thu, 15 Oct 1998 16:12: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 QAA04466 for ; Thu, 15 Oct 1998 16:12:24 -0700 Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA07741 for ; Thu, 15 Oct 1998 16:12:25 -0700 (PDT) Received: from geocities.com (trawick@slip129-37-81-34.ma.us.ibm.net [129.37.81.34]) by out2.ibm.net (8.8.5/8.6.9) with ESMTP id XAA202730 for ; Thu, 15 Oct 1998 23:12:20 GMT Received: (from trawick@localhost) by geocities.com (8.8.7/8.8.7) id TAA32314; Thu, 15 Oct 1998 19:15:16 -0400 Date: Thu, 15 Oct 1998 19:15:16 -0400 Message-Id: <199810152315.TAA32314@geocities.com> From: Jeff Trawick To: ipng@sunroof.eng.sun.com Subject: (IPng 6637) specifications of if_nametoindex() and if_indextoname() Reply-to: trawick@us.ibm.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Referring to the descriptions in ... A. specification of if_nametoindex() Was some text inadvertently omitted regarding error situations? I just implemented this function for a certain platform using an existing ioctl() mechanism; I want to handle the various points of failure in a way consistent with other platforms. I would like to see error scenarios described in a manner consistent with if_indextoname(). Consider the following new description for if_nametoindex(): If the specified interface does not exist, the return value is 0 and errno is set to ENXIO. If there was a system error (such as running out of memory), the return value is 0 and errno is set to the proper value (e.g., ENOMEM). B. specification of if_indextoname() if_indextoname() is misspelled (as ifindextoname()) in one place. Thanks for consideration... (Please reply to trawick@us.ibm.com.) -- Jeff Trawick | trawick@ibm.net | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien... -------------------------------------------------------------------- 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 Oct 15 22:21:06 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id WAA25854 for ipng-dist; Thu, 15 Oct 1998 22:06:54 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id WAA25847 for ; Thu, 15 Oct 1998 22:06:44 -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 WAA16553 for ; Thu, 15 Oct 1998 22:06:43 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id WAA27979 for ; Thu, 15 Oct 1998 22:06:45 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.8.8/8.8.8/WV1.0h) with SMTP id BAA18925; Fri, 16 Oct 1998 01:06:44 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA23062; Fri, 16 Oct 1998 01:06:44 -0400 Message-Id: <199810160506.AA23062@quarry.zk3.dec.com> To: trawick@us.ibm.com Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 6638) Re: specifications of if_nametoindex() and if_indextoname() In-Reply-To: Your message of "Thu, 15 Oct 1998 19:15:16 EDT." <199810152315.TAA32314@geocities.com> Date: Fri, 16 Oct 1998 01:06:43 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff, >A. specification of if_nametoindex() > >Was some text inadvertently omitted regarding error >situations? I just implemented this function for a >certain platform using an existing ioctl() mechanism; I >want to handle the various points of failure in a way >consistent with other platforms. > >I would like to see error scenarios described in a manner >consistent with if_indextoname(). Consider the following >new description for if_nametoindex(): > >If the specified interface does not exist, the return value >is 0 and errno is set to ENXIO. If there was a system >error (such as running out of memory), the return value is >0 and errno is set to the proper value (e.g., ENOMEM). This was added in this last round of discussions for if_indextoname. I could use ENXIO for if_nametoindex, and clearly the system errno hint as in if_indextoname. ENXIO was not obvious to me so let it go but looking at the errno's descriptions again it can work and can be returned. What is happening is an interface cannot be found for a name, so ENXIO will work. Here is the fix: ------------------------------------------------- If the specified interface name does not exist, the return value is 0, and errno is set to ENXIO. If there was a system error (such as running out of memory), the return value is 0 and errno is set to the proper value (e.g., ENOMEM). ------------------------------------------------- >B. specification of if_indextoname() > >if_indextoname() is misspelled (as ifindextoname()) in one >place. Bummer I can't believe I missed that one................ 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 Fri Oct 16 06:04:43 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA26105 for ipng-dist; Fri, 16 Oct 1998 05:59:34 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA26098 for ; Fri, 16 Oct 1998 05:59:26 -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 FAA28424 for ; Fri, 16 Oct 1998 05:59:23 -0700 Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.161]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA24423 for ; Fri, 16 Oct 1998 05:59:11 -0700 (PDT) Received: from cauchy.cs.uni-bonn.de (cauchy.cs.uni-bonn.de [131.220.4.169]) by theory.cs.uni-bonn.de (8.8.8/8.8.8) with ESMTP id OAA10499 for ; Fri, 16 Oct 1998 14:58:51 +0200 (MET DST) Received: (ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.6.9) id OAA06485; Fri, 16 Oct 1998 14:58:48 +0200 (MET DST) Message-ID: <19981016145846.A6442@cs.uni-bonn.de> Date: Fri, 16 Oct 1998 14:58:46 +0200 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Subject: (IPng 6639) ARCnet, Ethernet, FDDI MTUs: implementor view question References: <3.0.5.32.19981013121512.008d5490@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2i In-Reply-To: <3.0.5.32.19981013121512.008d5490@mailhost.iprg.nokia.com>; from Bob Hinden on Tue, Oct 13, 1998 at 12:15:12PM -0700 X-Mutt-References: <3.0.5.32.19981013121512.008d5490@mailhost.iprg.nokia.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I was just re-reading the ARCnet, and then the Ethernet and FDDI paper, and stumbled over this passage [Ethernet paper; similar words used by the FDDI and ARCnet papers]: The default MTU size for IPv6 [IPV6] packets on an Ethernet is 1500 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option which specifies a smaller MTU, or by manual configuration of each node. Until here, ok. If a Router Advertisement received on an Ethernet interface has an MTU option specifying an MTU larger than 1500, or larger than a manually configured value, that MTU option may be logged to system management but must be otherwise ignored. What happens if two Router Advertisements come in, one with a small MTU, one with a bigger one? Does the driver code or protocol stack need to keep two MTU values per interface, one for the latest "manual" (which includes DHCP) value, and one for the active value (initialized to the manually configured one, and changed when receiving router advertisements with a MTU smaller than the manual value? Regards, -is -------------------------------------------------------------------- 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 Oct 16 06:17:45 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA26134 for ipng-dist; Fri, 16 Oct 1998 06:13:46 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA26127 for ; Fri, 16 Oct 1998 06:13: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 GAA29826 for ; Fri, 16 Oct 1998 06:13:34 -0700 Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.161]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA00401 for ; Fri, 16 Oct 1998 06:13:35 -0700 (PDT) Received: from cauchy.cs.uni-bonn.de (cauchy.cs.uni-bonn.de [131.220.4.169]) by theory.cs.uni-bonn.de (8.8.8/8.8.8) with ESMTP id PAA11242 for ; Fri, 16 Oct 1998 15:13:30 +0200 (MET DST) Received: (ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.6.9) id PAA06523; Fri, 16 Oct 1998 15:13:28 +0200 (MET DST) Message-ID: <19981016151327.B6442@cs.uni-bonn.de> Date: Fri, 16 Oct 1998 15:13:27 +0200 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Subject: (IPng 6640) Re: W.G. Last Call on "A Method for the Transmission of IPv6 Packets over ARCnet Networks" References: <3.0.5.32.19981013121512.008d5490@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2i In-Reply-To: <3.0.5.32.19981013121512.008d5490@mailhost.iprg.nokia.com>; from Bob Hinden on Tue, Oct 13, 1998 at 12:15:12PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Comparing it to the IPv6 over Ethernet and FDDI specifications, I found that this sentence is missing at the end of the MTU discussion: For purposes of this document, information received from DHCP is considered "manually configured". I didn't take part in the discussion leading to this, "back then", so I don't know the rationale, but ARCnet should certainly be handled in the same way as the other two protocols. Regards, -is -------------------------------------------------------------------- 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 Oct 16 07:49:12 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA26229 for ipng-dist; Fri, 16 Oct 1998 07:45:40 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA26222 for ; Fri, 16 Oct 1998 07:45: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 HAA12265 for ; Fri, 16 Oct 1998 07:45:29 -0700 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA16433 for ; Fri, 16 Oct 1998 07:45:29 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA27892; Fri, 16 Oct 1998 10:44:43 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA29194; Fri, 16 Oct 1998 10:44:44 -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 KAA23604; Fri, 16 Oct 1998 10:44:42 -0400 (EDT) Message-Id: <199810161444.KAA23604@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: Ignatios Souvatzis cc: ipng@sunroof.eng.sun.com Subject: (IPng 6641) Re: ARCnet, Ethernet, FDDI MTUs: implementor view question In-reply-to: Your message of "Fri, 16 Oct 1998 14:58:46 -0400." <19981016145846.A6442@cs.uni-bonn.de> Date: Fri, 16 Oct 1998 10:44:42 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What happens if two Router Advertisements come in, one with a small > MTU, one with a bigger one? Does the driver code or protocol stack need > to keep two MTU values per interface, one for the latest "manual" > (which includes DHCP) value, and one for the active value (initialized > to the manually configured one, and changed when receiving router > advertisements with a MTU smaller than the manual value? You process them in order, and when you get an update, you toss out the old value and use the new. If as a consequence you oscillate between multiple values, so be it. At the time, it was felt that the benefits of trying to specify something more complex wasn't worth the benefit. After all, this is a config error on the routers. If this causes a problem in practice, the sys admin (presumably) has an easy fix. :-) 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 Fri Oct 16 08:02:08 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA26271 for ipng-dist; Fri, 16 Oct 1998 07:57:15 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA26264 for ; Fri, 16 Oct 1998 07:57: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 HAA14680 for ; Fri, 16 Oct 1998 07:57:04 -0700 Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.161]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA22352 for ; Fri, 16 Oct 1998 07:57:03 -0700 (PDT) Received: from cauchy.cs.uni-bonn.de (cauchy.cs.uni-bonn.de [131.220.4.169]) by theory.cs.uni-bonn.de (8.8.8/8.8.8) with ESMTP id QAA16397; Fri, 16 Oct 1998 16:56:58 +0200 (MET DST) Received: (ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.6.9) id QAA06800; Fri, 16 Oct 1998 16:56:56 +0200 (MET DST) Message-ID: <19981016165654.D6442@cs.uni-bonn.de> Date: Fri, 16 Oct 1998 16:56:54 +0200 From: Ignatios Souvatzis To: Thomas Narten , Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6642) Re: ARCnet, Ethernet, FDDI MTUs: implementor view question References: <19981016145846.A6442@cs.uni-bonn.de> <199810161444.KAA23604@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2i In-Reply-To: <199810161444.KAA23604@cichlid.raleigh.ibm.com>; from Thomas Narten on Fri, Oct 16, 1998 at 10:44:42AM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Oct 16, 1998 at 10:44:42AM -0400, Thomas Narten wrote: > > What happens if two Router Advertisements come in, one with a small > > MTU, one with a bigger one? Does the driver code or protocol stack need > > to keep two MTU values per interface, one for the latest "manual" > > (which includes DHCP) value, and one for the active value (initialized > > to the manually configured one, and changed when receiving router > > advertisements with a MTU smaller than the manual value? > > You process them in order, and when you get an update, you toss out > the old value and use the new. If as a consequence you oscillate > between multiple values, so be it. > > At the time, it was felt that the benefits of trying to specify > something more complex wasn't worth the benefit. After all, this is a > config error on the routers. If this causes a problem in practice, the > sys admin (presumably) has an easy fix. :-) In case this wasn't clear: My concern is not oscillating per se, but limiting the received MTU as specified. After I first lowered it, I dont have the old limit anymore, if I use the traditional "1-MTU" approach, right? Regards, -is -------------------------------------------------------------------- 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 Oct 16 11:40:39 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA26562 for ipng-dist; Fri, 16 Oct 1998 11:32:24 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA26555 for ; Fri, 16 Oct 1998 11:32: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 LAA23717 for ; Fri, 16 Oct 1998 11:32:09 -0700 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA15489 for ; Fri, 16 Oct 1998 11:32:09 -0700 (PDT) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2232.9) id <40RM62MF>; Fri, 16 Oct 1998 11:31:18 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF8148A@RED-MSG-50> From: Richard Draves To: "'Ignatios Souvatzis'" , Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6643) Re: ARCnet, Ethernet, FDDI MTUs: implementor view question Date: Fri, 16 Oct 1998 11:24:55 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In case this wasn't clear: My concern is not oscillating per > se, but limiting > the received MTU as specified. After I first lowered it, I > dont have the old > limit anymore, if I use the traditional "1-MTU" approach, right? It's not difficult to implement. For MSR IPv6, we just keep two link MTU values per interface, the maximum MTU and the current MTU. 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 Sun Oct 18 21:20:20 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id VAA27808 for ipng-dist; Sun, 18 Oct 1998 21:15:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id VAA27801 for ; Sun, 18 Oct 1998 21:14:39 -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 VAA24665 for ; Sun, 18 Oct 1998 21:14:38 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA23316 for ; Sun, 18 Oct 1998 21:14:39 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.8.8/8.8.8/WV1.0h) with SMTP id AAA21733 for ; Mon, 19 Oct 1998 00:14:38 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA15197; Mon, 19 Oct 1998 00:14:38 -0400 Message-Id: <199810190414.AA15197@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: (IPng 6647) Basic API Update Oct 18th and XNET INput may be coming!!! Date: Mon, 19 Oct 1998 00:14:37 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Thanks for the final edits. It appears we have a solid spec and folks have implementations underway. I will sumbit final edit as draft-03.txt Monday evening. It is just edits nothing that affects implementation. But I heard that the XNET group is not happy with our namespace for the API, and will be submitting a set of changes for this name space. I have advised the Chairs this may be happening. It is my feeling we should go forward with last call and if this very untimely and very late input does come in from XNET we can review it as a WG last call item. I have not seen any document yet privately or otherwise but here is how I feel about this right now as an "individual IETF member and Internet Society member": 1. The input is just plain too late from this standards organization, (XNET) they have had more than enough time to respond to this specification. This is also not the way to work with the IETF as a standards body. RFC 2133 has been there for a long time, with any suggested name space problem. 2. XNET does not represent all members on this list but only the UNIX vendors (e.g. not PCs, Routers, BSDxxxx, other OS's), as far as participating interests in that standards body. 3. Any name space suggestions must be proven that they are truly needed for this API. At this point in time it is not enough that XNET feels this is a good idea but must prove it. 4. If they can prove that this is a good idea, it may be that XNET can produce a later draft in their respective technical bodies and set of UNIX YEAR/YEAR (e.g. 95, 98) standards. Then it can be adopted by those supporting those standards. The Basic API Informational RFC can be used as a base for that work. If vendors feel this is important they can implement the change at the time the XNET process produces such a standard update. Given that this will not break any binary portability of IPv6 implementations. But at the end of the day it is up to you the working group to decide what is best. But I will proceed with the Chairs to request a last call on draft-03.txt of this very important API which is needed by the market and IPv6 implementors to become stable now. As previously stated I will sumbit draft-03.txt Monday evening. Sincerely, And a very tired editor and co-author, /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 Mon Oct 19 15:17:16 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA28656 for ipng-dist; Mon, 19 Oct 1998 15:10:53 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id PAA28649 for ; Mon, 19 Oct 1998 15:10:34 -0700 (PDT) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id PAA05863; Mon, 19 Oct 1998 15:10:27 -0700 (PDT) Date: Mon, 19 Oct 1998 15:10:27 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6648) Re: Basic API Update Oct 18th and XNET INput may be coming!!! To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199810190414.AA15197@quarry.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 > But I heard that the XNET group is not happy with our namespace for the > API, and will be submitting a set of changes for this name space. I > have advised the Chairs this may be happening. One potential name space issue that shows up in our implementation is the use of IFNAMSIZ for the if_*() routines. This name has traditionally only been used with the SIOC* ioctls and "promoting" the name to the API might be a bad idea. So a name like IF_NAMESIZE might be better - that would reserve the if_* and IF_* name space. (Our implementation preserves IFNAMSIZ for binary compatibility of the "old" SIOC{S,G}IF ioctls while using a larger name size for the "large" ioctls used to carry IPv6 addresses etc. The larger name size is needed for composing network interface names like "le0.skip.ipqos".) Thus decoupling the API IF_NAMESIZE constant from the ioctl definition IFNAMSIZ would allow the implementations to evolve independently of the API. The change to the spec would be to replace 3 occurances of IFNAMSIZ. The change to an implementation would be to add #define IF_NAMESIZE IFNAMSIZ 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 Mon Oct 19 17:34:10 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA28833 for ipng-dist; Mon, 19 Oct 1998 17:23:50 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA28823 for ; Mon, 19 Oct 1998 17:23:28 -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 RAA00994; Mon, 19 Oct 1998 17:23:22 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA04657; Mon, 19 Oct 1998 17:23:16 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.8.8/8.8.8/WV1.0h) with SMTP id UAA10973; Mon, 19 Oct 1998 20:23:05 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA01938; Mon, 19 Oct 1998 20:23:05 -0400 Message-Id: <199810200023.AA01938@quarry.zk3.dec.com> To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6649) Re: Basic API Update Oct 18th and XNET INput may be coming!!! In-Reply-To: Your message of "Mon, 19 Oct 1998 15:10:27 PDT." Date: Mon, 19 Oct 1998 20:23:04 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, We can take this input as part of the last call that will happen. I just submitted draft-03. We should make a last call on that draft. What you just sent is a mere editorial fix. This can be fixed in draft-04 which will be the draft with edits from 03. Plus you have an implementation fix that is pretty good. 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 Tue Oct 20 07:40:40 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA29217 for ipng-dist; Tue, 20 Oct 1998 07:34:12 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA29210 for ; Tue, 20 Oct 1998 07:33: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 HAA19709 for ; Tue, 20 Oct 1998 07:33:52 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA14218 for ; Tue, 20 Oct 1998 07:33:52 -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 KAA19861; Tue, 20 Oct 1998 10:33:49 -0400 (EDT) Message-Id: <199810201433.KAA19861@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com, mobile-ip@smallworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6651) I-D ACTION:draft-ietf-ipngwg-resv-anycast-01.txt Date: Tue, 20 Oct 1998 10:33:44 -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 : Reserved IPv6 Subnet Anycast Addresses Author(s) : D. Johnson, S. Deering Filename : draft-ietf-ipngwg-resv-anycast-01.txt Pages : 5 Date : 19-Oct-98 The IP Version 6 addressing architecture defines an 'anycast' address as an IPv6 address that is assigned to one or more network interfaces (typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the 'nearest' interface having that address, according to the routing protocols' measure of distance. This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-resv-anycast-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-resv-anycast-01.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-resv-anycast-01.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: <19981019154519.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-resv-anycast-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-resv-anycast-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981019154519.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 Tue Oct 20 07:50:38 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA29239 for ipng-dist; Tue, 20 Oct 1998 07:44:15 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA29232 for ; Tue, 20 Oct 1998 07:44: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 HAA21859 for ; Tue, 20 Oct 1998 07:43:58 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA20221 for ; Tue, 20 Oct 1998 07:43:58 -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 KAA20068; Tue, 20 Oct 1998 10:43:54 -0400 (EDT) Message-Id: <199810201443.KAA20068@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6652) I-D ACTION:draft-ietf-ipngwg-bsd-api-new-03.txt Date: Tue, 20 Oct 1998 10:43:54 -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 : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens Filename : draft-ietf-ipngwg-bsd-api-new-03.txt Pages : 33 Date : 19-Oct-98 The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-bsd-api-new-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-bsd-api-new-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-bsd-api-new-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: <19981020102057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-new-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-bsd-api-new-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981020102057.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 Tue Oct 20 07:58:45 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA29300 for ipng-dist; Tue, 20 Oct 1998 07:54:28 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA29293 for ; Tue, 20 Oct 1998 07:54: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 HAA24919 for ; Tue, 20 Oct 1998 07:54:17 -0700 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA26431 for ; Tue, 20 Oct 1998 07:54:17 -0700 (PDT) Received: by mailgate.rdg.opengroup.org; id AA13318; Tue, 20 Oct 1998 14:55:58 GMT Received: from cjh.rdg.opengroup.org [192.153.166.111] by mailgate.rdg.opengroup.org via smtpd V1.22 (98/10/13 10:26:28) for ; Tue Oct 20 15:55 BST 1998 Message-Id: <3.0.3.32.19981020154700.007b32b0@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 20 Oct 1998 15:47:00 +0100 To: ipng@sunroof.eng.sun.com From: Chris Harding Subject: (IPng 6653) Re: Basic API Update Oct 18th and XNET INput may be coming!!! Cc: ogtgnet@opengroup.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi - Detailed XNET input will be coming - here's why. Use of namespace by a service implementation may give application writers problems. They tend to assume that they can use what names they want in their programs and get upset when they come unstuck because they picked a name that was already in use by the implementation. So application writers want service implementations to use namespace sparingly and cleanly. So, for example, if you are writing an application to enable you to control the blinds in your house, you might write functions "open()" and "close()". When you then decide it would be nice to do it remotely over the Internet, you run into problems (assuming you didn't already have problems because your blind controller had some kind of file system). There is also (as in the specific example quoted by Erik) the possibility that you may get problems when you try to put together two service interfaces that were designed in isolation and that don't use namespace carefully. This leads to the convention, used in new specifications defined by various industry bodies, including The Open Group and POSIX, that all names used by the implementation from the application's namespace should start with a prefix, or small set of prefixes, that are peculiar to the interface. This doesn't preclude the use of meaningful names - and even adds to readability because it becomes obvious at a glance when a function from a particular interface is used, and it is further obvious which interface is in question. This is fine for new interfaces, but many old ones - including sockets - don't follow this convention. Use of "close()" by the sockets interface - as well as "socket()", "accept()", "connect()", etc - is well-established and it would almost certainly cause more pain to change it than to leave it alone. But this argument doesn't apply to extensions to the sockets interface. Keeping "namespace pollution" to a minimum in any extensions will make the interface easier to use. So it is right to ask whether there are good reasons for not minimising namespace pollution. And I can't think of any. Why raise this now? Well, this is in some sense a cosmetic issue. Changing the name of a function or a data structure has no effect on what the function does or what the data structure contains. It is reasonable to get the functionality right first and argue about the names afterwards. This wastes less time than, for example, arguing heatedly about the name of a function which is then found to be unnecessary and removed from the interface. Detailed comments on this aspect - which will not impact the stability of the interface from a functional point of view - will be circulated in response to the "last call". >>>> Folks, Thanks for the final edits. It appears we have a solid spec and folks have implementations underway. I will sumbit final edit as draft-03.txt Monday evening. It is just edits nothing that affects implementation. But I heard that the XNET group is not happy with our namespace for the API, and will be submitting a set of changes for this name space. I have advised the Chairs this may be happening. It is my feeling we should go forward with last call and if this very untimely and very late input does come in from XNET we can review it as a WG last call item. I have not seen any document yet privately or otherwise but here is how I feel about this right now as an "individual IETF member and Internet Society member": 1. The input is just plain too late from this standards organization, (XNET) they have had more than enough time to respond to this specification. This is also not the way to work with the IETF as a standards body. RFC 2133 has been there for a long time, with any suggested name space problem. 2. XNET does not represent all members on this list but only the UNIX vendors (e.g. not PCs, Routers, BSDxxxx, other OS's), as far as participating interests in that standards body. 3. Any name space suggestions must be proven that they are truly needed for this API. At this point in time it is not enough that XNET feels this is a good idea but must prove it. 4. If they can prove that this is a good idea, it may be that XNET can produce a later draft in their respective technical bodies and set of UNIX YEAR/YEAR (e.g. 95, 98) standards. Then it can be adopted by those supporting those standards. The Basic API Informational RFC can be used as a base for that work. If vendors feel this is important they can implement the change at the time the XNET process produces such a standard update. Given that this will not break any binary portability of IPv6 implementations. But at the end of the day it is up to you the working group to decide what is best. But I will proceed with the Chairs to request a last call on draft-03.txt of this very important API which is needed by the market and IPv6 implementors to become stable now. As previously stated I will sumbit draft-03.txt Monday evening. Sincerely, And a very tired editor and co-author, /jim <<<< Regards, Chris +++++ ------------------------------------------------------------------------- Chris Harding T H E Development Manager O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Ph: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Fx: +44 118 950 0110 OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. ------------------------------------------------------------------------- -------------------------------------------------------------------- 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 Oct 20 11:42:32 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA29607 for ipng-dist; Tue, 20 Oct 1998 11:34:23 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA29595 for ; Tue, 20 Oct 1998 11:33:59 -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 LAA07338 for ; Tue, 20 Oct 1998 11:33:33 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA01671 for ; Tue, 20 Oct 1998 11:33:27 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id SAA11261; Tue, 20 Oct 1998 18:33:26 GMT Message-Id: <3.0.5.32.19981020113115.009e97a0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 20 Oct 1998 11:31:15 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6654) W.G. Last Call on "Reserved IPv6 Subnet Anycast Addresses" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as a Proposed Standard: Title : Reserved IPv6 Subnet Anycast Addresses Author(s) : D. Johnson, S. Deering Filename : draft-ietf-ipngwg-resv-anycast-01.txt Pages : 5 Date : 19-Oct-98 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on November 3, 1998. Bob Hinden / Steve Deering -------------------------------------------------------------------- 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 Oct 20 12:13:51 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA29684 for ipng-dist; Tue, 20 Oct 1998 12:03:23 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA29677 for ; Tue, 20 Oct 1998 12:03:14 -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 MAA17493 for ; Tue, 20 Oct 1998 12:03:10 -0700 Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.161]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA20355 for ; Tue, 20 Oct 1998 12:02:58 -0700 (PDT) Received: from euklid.cs.uni-bonn.de (euklid.cs.uni-bonn.de [131.220.4.162]) by theory.cs.uni-bonn.de (8.8.8/8.8.8) with ESMTP id VAA00788 for ; Tue, 20 Oct 1998 21:02:53 +0200 (MET DST) Received: (ignatios@localhost) by euklid.cs.uni-bonn.de (8.8.8/8.6.9) id VAA06668; Tue, 20 Oct 1998 21:02:52 +0200 (MET DST) Message-ID: <19981020210251.A6652@cs.uni-bonn.de> Date: Tue, 20 Oct 1998 21:02:51 +0200 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Subject: (IPng 6655) Re: W.G. Last Call on "A Method for the Transmission of IPv6 Packets over ARCnet Networks" References: <3.0.5.32.19981013121512.008d5490@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2i In-Reply-To: <3.0.5.32.19981013121512.008d5490@mailhost.iprg.nokia.com>; from Bob Hinden on Tue, Oct 13, 1998 at 12:15:12PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Oct 13, 1998 at 12:15:12PM -0700, Bob Hinden wrote: > This is a IPng working group last call for comments on advancing the > following document as a Proposed Standard: > > Title : A Method for the Transmission of IPv6 Packets > over ARCnet Networks. > Author(s) : I. Souvatzis > Filename : draft-souvatzis-ipv6-arcnet-04.txt > Pages : 6 > Date : 28-Sep-98 > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the author. This last call period will end two > week from today on October 27, 1998. Whats the procedure to do updates to the paper suggested during the last call period? -is -------------------------------------------------------------------- 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 Oct 20 13:56:40 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA29802 for ipng-dist; Tue, 20 Oct 1998 13:43:02 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA29795 for ; Tue, 20 Oct 1998 13:42: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 NAA18787 for ; Tue, 20 Oct 1998 13:42:45 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA28101 for ; Tue, 20 Oct 1998 13:42:37 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id UAA16123; Tue, 20 Oct 1998 20:42:35 GMT Message-Id: <3.0.5.32.19981020134005.009e2100@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 20 Oct 1998 13:40:05 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6656) W.G. Last Call on "Basic Socket Interface Extensions for IPv6" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as an Informational RFC: Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens Filename : draft-ietf-ipngwg-bsd-api-new-03.txt Pages : 33 Date : 19-Oct-98 This will replace RFC 2133. Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on November 3, 1998. Bob Hinden / Steve Deering -------------------------------------------------------------------- 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 Oct 20 23:47:40 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id XAA00329 for ipng-dist; Tue, 20 Oct 1998 23:42:16 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id XAA00322 for ; Tue, 20 Oct 1998 23:42: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 XAA23489 for ; Tue, 20 Oct 1998 23:42:05 -0700 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id XAA22363 for ; Tue, 20 Oct 1998 23:42:06 -0700 (PDT) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W) with ESMTP id PAA06153; Wed, 21 Oct 1998 15:41:45 +0900 (JST) To: Craig Metz cc: ipng@sunroof.eng.sun.com In-reply-to: cmetz's message of Sat, 10 Oct 1998 19:21:17 -0300. <199810102320.XAA04078@inner.net> 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 6657) Re: Results on Chicago hallway BoF on ioctls Date: Wed, 21 Oct 1998 15:41:45 +0900 Message-ID: <6149.908952105@coconut.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There was a hallway BoF session at the Chicago IETF in which several >implementors got together and mostly agreed on definitions for the basic IPv6 >interface address ioctls() so that we could have some interoperability. These >results represent no standard or specification of any form; they're just what >we thought would be good to implement and will hopefully be what *is* >implemented in our code bases. > Productive comments are welcome. We are about to implement this and I noticed that I've forgot one important thing... What was the consensus about grabbing one interface address from multiple addresses? itojun@kame.net jun-ichiro itoh -------------------------------------------------------------------- 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 Oct 21 06:54:35 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA00590 for ipng-dist; Wed, 21 Oct 1998 06:47:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA00583 for ; Wed, 21 Oct 1998 06:47:05 -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 GAA14163 for ; Wed, 21 Oct 1998 06:47:00 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA21419 for ; Wed, 21 Oct 1998 06:47:00 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.8.8/8.8.8/WV1.0h) with SMTP id JAA03506 for ; Wed, 21 Oct 1998 09:46:53 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA24429; Wed, 21 Oct 1998 09:46:54 -0400 Message-Id: <199810211346.AA24429@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: (IPng 6658) Base API Edit Question on error_num Date: Wed, 21 Oct 1998 09:46:54 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Quick editing question. We have gotten several inputs folks would like to use h_errno from multiple implementors. We don't really care if that is what folks want? Can we hear from you? >> applications. That is, porting simple applications to use IPv6 replaces >> the call >> >> hptr = gethostbyname(name); >> >> with >> >> hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &error_num); > >Wouldn't a more accurate equivalent actually be: > > hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &h_errno); ~~~~~~~~ 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 Oct 21 11:27:47 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA00934 for ipng-dist; Wed, 21 Oct 1998 11:15:48 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA00927 for ; Wed, 21 Oct 1998 11:15:23 -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 LAA02328 for ; Wed, 21 Oct 1998 11:15:17 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA29706 for ; Wed, 21 Oct 1998 11:15:18 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.8.8/8.8.8/WV1.0h) with SMTP id OAA04114 for ; Wed, 21 Oct 1998 14:15:15 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA23930; Wed, 21 Oct 1998 14:15:17 -0400 Message-Id: <199810211815.AA23930@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 6659) Re: Base API Edit Question on error_num In-Reply-To: Your message of "Wed, 21 Oct 1998 09:46:54 EDT." <199810211346.AA24429@quarry.zk3.dec.com> Date: Wed, 21 Oct 1998 14:15:17 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here is some private input I got on h_errno from a die hard implementor. This was my first impression but I have not worked with the gehostbyxxx_r routines hands on as an implementor, so I am listening. ------------------------ Bad idea. h_errno is a global variable, not thread safe, the whole reason for adding the "&error_num" parameter is to move away from using h_errno. That said, people could pass in &h_errno if they wanted to, but I don't think we want to encourage that usage. I'd stick with &error_num. The prototype is just an example anyway, people can pass in whatever 'int *' name they want. ----------------------------- /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 Oct 21 12:29:29 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA00988 for ipng-dist; Wed, 21 Oct 1998 12:22:16 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA00981 for ; Wed, 21 Oct 1998 12:22: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 MAA22728 for ; Wed, 21 Oct 1998 12:22:01 -0700 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by earth.sun.com (8.9.1/8.9.1) with SMTP id MAA16149 for ; Wed, 21 Oct 1998 12:22:00 -0700 (PDT) Received: by mailgate.rdg.opengroup.org; id AA11806; Wed, 21 Oct 1998 19:23:38 GMT Received: from cjh.rdg.opengroup.org [192.153.166.111] by mailgate.rdg.opengroup.org via smtpd V1.22 (98/10/13 10:26:28) for ; Wed Oct 21 20:23 BST 1998 Message-Id: <3.0.3.32.19981021201510.007d9d10@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 21 Oct 1998 20:15:10 +0100 To: ipng@sunroof.eng.sun.com From: Chris Harding Subject: (IPng 6660) (c.harding 21731) Re: Base API Edit Question on error_num Cc: xnet@opengroup.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi - h_errno is specified in XNS and in P1003.1g/D6.6 to be "a modifiable l-value of type int". This is similar to the definition of errno in POSIX. It allows h_errno to be defined in a thread-safe manner as (eg.) extern int *_h_errno(void) but preserves compatibility with applications that assume the old definition of int. Having said which, I would agree that if we were starting from scratch, it would be better to have a function parameter return the error value. The only argument for the h_errno usage is backwards compatibility. But at least there is a way of maintaining that usage while preserving thread-safety. >From: bound@zk3.dec.com >To: ipng@sunroof.eng.sun.com >Subject: (c.harding 21731) (IPng 6659) Re: Base API Edit Question on error_num >Date: Wed, 21 Oct 1998 14:15:17 -0400 >X-Mts: smtp >Sender: owner-ipng@sunroof.eng.sun.com >Comments: (c.harding 21731) > >Here is some private input I got on h_errno from a die hard implementor. >This was my first impression but I have not worked with the >gehostbyxxx_r routines hands on as an implementor, so I am listening. > >------------------------ >Bad idea. h_errno is a global variable, not thread safe, the >whole reason for adding the "&error_num" parameter is to move >away from using h_errno. That said, people could pass in >&h_errno if they wanted to, but I don't think we want to encourage >that usage. I'd stick with &error_num. The prototype is just >an example anyway, people can pass in whatever 'int *' name they >want. >----------------------------- > >/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 >-------------------------------------------------------------------- > > Regards, Chris +++++ ------------------------------------------------------------------------- Chris Harding T H E Development Manager O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Ph: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Fx: +44 118 950 0110 OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. ------------------------------------------------------------------------- -------------------------------------------------------------------- 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 Oct 21 13:07:15 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA01141 for ipng-dist; Wed, 21 Oct 1998 12:58:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA01133 for ; Wed, 21 Oct 1998 12:58:11 -0700 (PDT) From: akephart@austin.ibm.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 MAA03260 for ; Wed, 21 Oct 1998 12:58:06 -0700 Received: from ausmail1.austin.ibm.com (ausmail1.austin.ibm.com [192.35.232.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA07120 for ; Wed, 21 Oct 1998 12:58:08 -0700 (PDT) Received: from netmail1.austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96]) by ausmail1.austin.ibm.com (8.9.1/8.8.5) with ESMTP id OAA11380; Wed, 21 Oct 1998 14:55:46 -0500 Received: from aguila.austin.ibm.com (aguila.austin.ibm.com [9.53.150.192]) by netmail1.austin.ibm.com (8.8.5/8.8.5) with ESMTP id OAA44354; Wed, 21 Oct 1998 14:55:32 -0500 Received: (from akephart@localhost) by aguila.austin.ibm.com (AIX4.3/UCB 8.8.8/8.7-client1.01) id OAA27982; Wed, 21 Oct 1998 14:55:32 -0500 Message-Id: <199810211955.OAA27982@aguila.austin.ibm.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: bound@zk3.dec.com cc: ipng@sunroof.eng.sun.com Reply-To: akephart@austin.ibm.com Subject: (IPng 6661) Re: Base API Edit Question on error_num In-reply-to: (Your message of Wed, 21 Oct 98 14:15:17 -0400.)<199810211815.AA23930@quarry.zk3.dec.com> Date: Wed, 21 Oct 1998 14:55:32 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ho. It may have been mentioned already, but h_errno is not necessarily a global, and may already be thread safe in a number of implementations (it is in ours). -andrew > Here is some private input I got on h_errno from a die hard implementor. > This was my first impression but I have not worked with the > gehostbyxxx_r routines hands on as an implementor, so I am listening. > > ------------------------ > Bad idea. h_errno is a global variable, not thread safe, the > whole reason for adding the "&error_num" parameter is to move > away from using h_errno. That said, people could pass in > &h_errno if they wanted to, but I don't think we want to encourage > that usage. I'd stick with &error_num. The prototype is just > an example anyway, people can pass in whatever 'int *' name they > want. > ----------------------------- > > /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 > -------------------------------------------------------------------- -- +---------------------------------------------------------------------------+ | Andrew Kephart, AIX TCP/IP These are my opinions only...IBM might | | SMTP: akephart@austin.ibm.com agree, but I wouldn't count on it. | +---------------------------------------------------------------------------+ -------------------------------------------------------------------- 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 Oct 21 13:25:42 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA01175 for ipng-dist; Wed, 21 Oct 1998 13:13:08 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA01166 for ; Wed, 21 Oct 1998 13:12: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 NAA07783 for ; Wed, 21 Oct 1998 13:12:54 -0700 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA16866 for ; Wed, 21 Oct 1998 13:12:56 -0700 (PDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA08243; Wed, 21 Oct 1998 13:10:16 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA77948; Wed, 21 Oct 1998 13:10:16 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA26341; Wed, 21 Oct 1998 13:10:15 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199810212010.NAA26341@bossette.engr.sgi.com> Subject: (IPng 6662) Re: Base API Edit Question on error_num To: bound@zk3.dec.com Date: Wed, 21 Oct 1998 13:10:15 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199810211815.AA23930@quarry.zk3.dec.com> from "bound@zk3.dec.com" at Oct 21, 98 02:15:17 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk bound@zk3.dec.com wrote: > > Here is some private input I got on h_errno from a die hard implementor. > This was my first impression but I have not worked with the > gehostbyxxx_r routines hands on as an implementor, so I am listening. > > ------------------------ > Bad idea. h_errno is a global variable, not thread safe, the > whole reason for adding the "&error_num" parameter is to move > away from using h_errno. That said, people could pass in > &h_errno if they wanted to, but I don't think we want to encourage > that usage. I'd stick with &error_num. The prototype is just > an example anyway, people can pass in whatever 'int *' name they > want. > ----------------------------- I see your point; but if anybody blindly follows the example that the draft gives of replacing gethostbyname() with getipnodebyname(), any code that subsequently used h_errno would not give the expected result. Moreover, such code wouldn't be thread safe anyway if it's using gethostbyname. Maybe the text should be something like: > applications. That is, porting simple applications to use IPv6 replaces > the call > > hptr = gethostbyname(name); > > with > > hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &error_num); > > and changes any subsequent error diagnosis code to use error_num instead > of externally declared variables, such as h_errno. Or maybe this is just too obvious? -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Oct 21 17:59:15 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA01597 for ipng-dist; Wed, 21 Oct 1998 17:53:05 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA01587 for ; Wed, 21 Oct 1998 17:52:25 -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 RAA10880 for ; Wed, 21 Oct 1998 17:52:23 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA16218 for ; Wed, 21 Oct 1998 17:52:25 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.8.8/8.8.8/WV1.0h) with SMTP id UAA11075; Wed, 21 Oct 1998 20:52:25 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA01783; Wed, 21 Oct 1998 20:52:25 -0400 Message-Id: <199810220052.AA01783@quarry.zk3.dec.com> To: sm@bossette.engr.sgi.com (Sam Manthorpe) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6663) Re: Base API Edit Question on error_num In-Reply-To: Your message of "Wed, 21 Oct 1998 13:10:15 PDT." <199810212010.NAA26341@bossette.engr.sgi.com> Date: Wed, 21 Oct 1998 20:52:25 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sam, >I see your point; but if anybody blindly follows the example that the >draft gives of replacing gethostbyname() with getipnodebyname(), >any code that subsequently used h_errno would not give the expected >result. Moreover, such code wouldn't be thread safe anyway if it's >using gethostbyname. Maybe the text should be something like: >> applications. That is, porting simple applications to use IPv6 replaces >> the call >> >> hptr = gethostbyname(name); >> > with >>> > hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &error_num); >> >> and changes any subsequent error diagnosis code to use error_num instead >> of externally declared variables, such as h_errno. >Or maybe this is just too obvious? It was to me but that don't count. I can put this in if we don't change it to h_errno. Right now consensus seems split to me, with people using h_errno in different ways as a variable on their implementations. There is no backwards compatibility requirement for this API spec until this spec itself moves forward. So saying h_errno is needed for backwards compatibility is an argument I don't see right now as valid. So we are starting from scratch. error_num is what you want it to be and there is confusion with h_errno. If an implementor wants to return in error_num the h_errno value from a resolver for DNS then they can do that. What I don't like I think is to tell those who don't want to use h_errno in this manner they must use h_errno. This is why error_num was defined. It is the moderate engineering position which was assumed could satisfy all needs. /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 Oct 21 18:39:31 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id SAA01675 for ipng-dist; Wed, 21 Oct 1998 18:33:50 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id SAA01665 for ; Wed, 21 Oct 1998 18:33:41 -0700 (PDT) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id SAA07044; Wed, 21 Oct 1998 18:33:40 -0700 (PDT) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.9.1b+Sun/8.9.1) id SAA17740; Wed, 21 Oct 1998 18:33:21 -0700 (PDT) Date: Wed, 21 Oct 1998 18:33:21 -0700 (PDT) From: Mukesh Kacker Message-Id: <199810220133.SAA17740@lucknow.eng.sun.com> To: sm@bossette.engr.sgi.com, bound@zk3.dec.com Subject: (IPng 6664) Re: Base API Edit Question on error_num Cc: ipng@sunroof.eng.sun.com, mukesh@lucknow.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > error_num is what you want it to be and there is confusion with > h_errno. > What could be confusing people is a design decision to use the same "error code name space" by getipnodebyname() as the one used for "h_errno". [ i.e. the constants HOST_NOT_FOUND, NO_ADDRESS etc]. That has been done for ease of porting. However (as Jim stated) use of "global" variables is deprecated and here the application has to use its own local variable to store the error which is the more modern practice in world with threads (the dereference to function returning modifiable lvalue hack notwithstanding). Similar approach has been taken in the getaddrinfo() function where the error is passed back as return value [i.e the EAI_* error namespace ] but does not set any "global" variable. [ While we are on this topic...there is another thing someone here noticed recently. The getnameinfo() function has punted on defining errors. Not sure if this was "by design" or the intent was to work out the important details and leave error codes and such to the standards folks (Posix, XNET etc). It just says "non-zero ...indicates failure" If a complete error namespace is ever to be done, there will have to be an ENI_* error namespace (similar to EAI_* errors) and a gni_strerror() function (similar to gai_strerror()). Not sure if anyone would be tackling that at this stage :-) The "reference implementation" in Richard Stevens Unix Network Programming book chooses to return "1" for all error scenarios in getnameinfo() even though getaddrinfo() has meaningful getaddrinfo() error codes. ] -Mukesh Kacker Sun Microsystems Inc. -------------------------------------------------------------------- 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 Oct 21 19:03:03 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id SAA01722 for ipng-dist; Wed, 21 Oct 1998 18:55:55 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id SAA01710 for ; Wed, 21 Oct 1998 18:55:39 -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 SAA20981; Wed, 21 Oct 1998 18:55:37 -0700 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA11762; Wed, 21 Oct 1998 18:55:39 -0700 (PDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA07392; Wed, 21 Oct 1998 18:55:38 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA17084; Wed, 21 Oct 1998 18:55:36 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id SAA01944; Wed, 21 Oct 1998 18:55:35 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199810220155.SAA01944@bossette.engr.sgi.com> Subject: (IPng 6665) Re: Base API Edit Question on error_num To: Mukesh.Kacker@Eng (Mukesh Kacker) Date: Wed, 21 Oct 1998 18:55:35 -0700 (PDT) Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, mukesh@lucknow.eng.sun.com In-Reply-To: <199810220133.SAA17740@lucknow.eng.sun.com> from "Mukesh Kacker" at Oct 21, 98 06:33:21 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mukesh Kacker wrote: > > > > > error_num is what you want it to be and there is confusion with > > h_errno. > > > > What could be confusing people is a design decision to use the > same "error code name space" by getipnodebyname() as the one > used for "h_errno". [ i.e. the constants HOST_NOT_FOUND, NO_ADDRESS etc]. > > That has been done for ease of porting. However (as Jim stated) use of > "global" variables is deprecated and here the application has to use > its own local variable to store the error which is the more modern > practice in world with threads (the dereference to function returning > modifiable lvalue hack notwithstanding). Yes, I appreciate that. I was never suggesting that h_errno replace error_num as a general means of communicating error types. All I was saying was that the text that gives an example of how to modify an app to work with IPv6 could imply that this simple change is all that is required and that the app may continue to use h_errno elsewhere in the code. I originally proposed to replace error_num with h_error in the example, but have since realised that this would be misleading and could be interpreted as saying `one should use h_errno to store error values returned by getipnodeby*()'. That wasn't at all what I meant. Anyway, it's really a minor thing and probably not worth discussing at this much length ;-) -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Oct 21 19:03:41 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id SAA01721 for ipng-dist; Wed, 21 Oct 1998 18:55:55 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id SAA01706 for ; Wed, 21 Oct 1998 18:55:37 -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 SAA20973; Wed, 21 Oct 1998 18:55:35 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA11744; Wed, 21 Oct 1998 18:55:37 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.8.8/8.8.8/WV1.0h) with SMTP id VAA01982; Wed, 21 Oct 1998 21:55:36 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA31006; Wed, 21 Oct 1998 21:55:36 -0400 Message-Id: <199810220155.AA31006@quarry.zk3.dec.com> To: Mukesh Kacker Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6666) Re: Base API Edit Question on error_num In-Reply-To: Your message of "Wed, 21 Oct 1998 18:33:21 PDT." <199810220133.SAA17740@lucknow.eng.sun.com> Date: Wed, 21 Oct 1998 21:55:36 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mukesh, On getXXinfo parts. This is a POSIX reference and we (the IETF IPng WG) don't own it and can't change it, us changing it would be like the IEEE 1394 folks changing our IP over Foo specs to suite that standard. It stands as it is per the reference. We have limititations here for this work it will not solve all problems, it is mean't to get IPv6 deployed by applications, we have stretched that quite far since I first saw Bob Gilligan's draft in 1993 for this API. I think we should stop stretching it and ship it. I believe when we decided to replace gethostbyname with a new incantation that would be MT safe we basically trashed h_errno, because there is no market, standard, or implementation consensus it is not a global variable and can be a MT Safe error mechanism. /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 Oct 21 19:38:29 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA01773 for ipng-dist; Wed, 21 Oct 1998 19:27:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id TAA01766 for ; Wed, 21 Oct 1998 19:27: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 TAA24973 for ; Wed, 21 Oct 1998 19:27:29 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA23387 for ; Wed, 21 Oct 1998 19:27:30 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id CAA07820; Thu, 22 Oct 1998 02:21:55 GMT Message-Id: <199810220221.CAA07820@inner.net> To: Jun-ichiro itojun Itoh cc: ipng@sunroof.eng.sun.com Subject: (IPng 6667) Re: Results on Chicago hallway BoF on ioctls In-reply-to: Your message of "Wed, 21 Oct 1998 15:41:45 +0900." <6149.908952105@coconut.itojun.org> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Wed, 21 Oct 1998 18:26:10 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <6149.908952105@coconut.itojun.org>, you write: >> There was a hallway BoF session at the Chicago IETF in which several >>implementors got together and mostly agreed on definitions for the basic IPv6 >>interface address ioctls() so that we could have some interoperability. These >>results represent no standard or specification of any form; they're just what >>we thought would be good to implement and will hopefully be what *is* >>implemented in our code bases. >> Productive comments are welcome. > > We are about to implement this and I noticed that I've forgot one > important thing... > What was the consensus about grabbing one interface address > from multiple addresses? I believe it was that the app specifies a prefix and the kernel will return the first address that matches that. So, if you want to get the link-local, do a get on fe80::0/64 with the prefix flag set. If you have multiple globals, you might just bite the bullet and use something like SIOCGIFCONF. -Craig -------------------------------------------------------------------- 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 Oct 21 22:17:37 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id WAA01905 for ipng-dist; Wed, 21 Oct 1998 22:02:30 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id WAA01898 for ; Wed, 21 Oct 1998 22:01:13 -0700 (PDT) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id WAA25131; Wed, 21 Oct 1998 22:00:52 -0700 (PDT) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.9.1b+Sun/8.9.1) id WAA17896; Wed, 21 Oct 1998 22:00:32 -0700 (PDT) Date: Wed, 21 Oct 1998 22:00:32 -0700 (PDT) From: Mukesh Kacker Message-Id: <199810220500.WAA17896@lucknow.eng.sun.com> To: Mukesh.Kacker@Eng, bound@zk3.dec.com Subject: (IPng 6668) Re: Base API Edit Question on error_num Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > On getXXinfo parts. This is a POSIX reference and we (the IETF IPng WG) > don't own it and can't change it, us changing it would be like the IEEE > 1394 folks changing our IP over Foo specs to suite that standard. It > stands as it is per the reference. > As far as I am aware getaddrinfo() is a POSIX reference. getnameinfo() is not and appears in RFC2133 but is likely to be adopted by POSIX/XNET and I just pointed out its lack of error codes as a side issue in error space discussions. > We have limititations here for this work it will not solve all problems, I agree. I am NOT suggesting we make ANY changes at this stage. The worse case consequence is that under bug scenarios, appplications will not get a very specific error message from getnameinfo() which is good enough for now. I just mentioned it as something similar to error code discussions which MAY get attention in any further work at POSIX/XNET etc. I agree we should not attempt any more refinements into that and what we have now will do. It should not matter for normal correctly functioning application. -Mukesh Kacker Internet Engineering Sun Microsystems Inc. -------------------------------------------------------------------- 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 Oct 23 07:27:44 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA03997 for ipng-dist; Fri, 23 Oct 1998 07:22:32 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA03973 for ; Fri, 23 Oct 1998 07:22: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 HAA14124 for ; Fri, 23 Oct 1998 07:21:58 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA06492 for ; Fri, 23 Oct 1998 07:21:57 -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 KAA24883; Fri, 23 Oct 1998 10:21:53 -0400 (EDT) Message-Id: <199810231421.KAA24883@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6669) I-D ACTION:draft-ietf-ipngwg-ipaddressassign-00.txt Date: Fri, 23 Oct 1998 10:21:52 -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 : A method for flexible IPv6 address assignments Author(s) : M. Blanchet Filename : draft-ietf-ipngwg-ipaddressassign-00.txt Pages : 4 Date : 22-Oct-98 This draft presents a method for assigning IP address prefixes that enables the IP assigning autority - the organisation that assigns IP address prefixes to other organisations, like a registry to an internet service provider or an internet service provider to a client organisation connected to its network -to postpone the final decision of prefix length by keeping space between assigned bits of the different parts of the IP address. This enables the assigning autority to change the different part lengths of the prefix (TLA (top level aggregator), subTLA, NLA(next-level aggregator) SLA (site-level aggregator), ...) even after allocated spaces. This scheme is applicable to both IPv4 and IPv6 but is envisionned mainly for IPv6 where the address space is larger and more flexible. It is a generalization of RFC1219 and can be used for IPv6 assignments based on RFC2373 and RFC2374. 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-ipaddressassign-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-ipaddressassign-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-ipngwg-ipaddressassign-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. --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: <19981022151207.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipaddressassign-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipaddressassign-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981022151207.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 Fri Oct 30 07:09:19 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA09623 for ipng-dist; Fri, 30 Oct 1998 07:01:42 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA09616 for ; Fri, 30 Oct 1998 07:01:34 -0800 (PST) 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 HAA05659 for ; Fri, 30 Oct 1998 07:01:30 -0800 Received: from theoryx.cs.uni-bonn.de (theoryx.cs.uni-bonn.de [131.220.4.211]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA11309 for ; Fri, 30 Oct 1998 07:01:17 -0800 (PST) Received: from cauchy.cs.uni-bonn.de (cauchy [131.220.4.169]) by theoryx.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id QAA13765 for ; Fri, 30 Oct 1998 16:01:02 +0100 (MET) Received: (from ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.8.8) id QAA09743; Fri, 30 Oct 1998 16:01:14 +0100 (MET) Message-ID: <19981030160113.A9668@cs.uni-bonn.de> Date: Fri, 30 Oct 1998 16:01:13 +0100 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Subject: (IPng 6675) Metaposting: am I still connected? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk just a quick test... Majordomo claims I'm on the list, but I dont receive anything. -is -------------------------------------------------------------------- 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 Oct 30 08:53:37 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA09750 for ipng-dist; Fri, 30 Oct 1998 08:49:18 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA09743 for ; Fri, 30 Oct 1998 08:49:09 -0800 (PST) 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 IAA00149 for ; Fri, 30 Oct 1998 08:49:07 -0800 Received: from seralph10.essex.ac.uk (seralph10.essex.ac.uk [155.245.240.160]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA17710 for ; Fri, 30 Oct 1998 08:49:06 -0800 (PST) Received: from s1937.essex.ac.uk ([155.245.129.87]) by seralph10.essex.ac.uk with smtp (Exim 1.92 #5) id 0zZHjN-0000bK-00; Fri, 30 Oct 1998 16:48:57 +0000 From: K Sun Reply-To: ksun@essex.ac.uk To: Ignatios Souvatzis cc: ipng@sunroof.eng.sun.com Subject: (IPng 6676) Re: Metaposting: am I still connected? In-Reply-To: <19981030160113.A9668@cs.uni-bonn.de> Message-ID: Date: Fri, 30 Oct 1998 16:48:57 +0000 (GMT) X-Mailer: Simeon for Win32 Version 4.1.2 Build (32) X-Authentication: IMSP MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Me too! On Fri, 30 Oct 1998 16:01:13 +0100 Ignatios Souvatzis wrote: > just a quick test... > > Majordomo claims I'm on the list, but I dont receive anything. > -is > -------------------------------------------------------------------- > 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 Oct 30 09:18:51 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA09864 for ipng-dist; Fri, 30 Oct 1998 09:14:43 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA09857 for ; Fri, 30 Oct 1998 09:14:35 -0800 (PST) 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 JAA06947 for ; Fri, 30 Oct 1998 09:14:32 -0800 Received: from theoryx.cs.uni-bonn.de (theoryx.cs.uni-bonn.de [131.220.4.211]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA04744 for ; Fri, 30 Oct 1998 09:14:27 -0800 (PST) Received: from cauchy.cs.uni-bonn.de (cauchy [131.220.4.169]) by theoryx.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id SAA14545 for ; Fri, 30 Oct 1998 18:14:09 +0100 (MET) Received: (from ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.8.8) id SAA10258; Fri, 30 Oct 1998 18:14:22 +0100 (MET) Message-ID: <19981030181421.D10177@cs.uni-bonn.de> Date: Fri, 30 Oct 1998 18:14:21 +0100 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6677) Re: Metaposting: am I still connected? References: <19981030160113.A9668@cs.uni-bonn.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2i In-Reply-To: ; from K Sun on Fri, Oct 30, 1998 at 04:48:57PM +0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Oct 30, 1998 at 04:48:57PM +0000, K Sun wrote: > Me too! > > On Fri, 30 Oct 1998 16:01:13 +0100 Ignatios Souvatzis > wrote: > > just a quick test... > > > > Majordomo claims I'm on the list, but I dont receive anything. > > -is Uhm, thanks for replying, whoever did. It turns out the list was really quiet. -is -------------------------------------------------------------------- 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 Oct 30 16:18:07 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA10577 for ipng-dist; Fri, 30 Oct 1998 16:10:34 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA10570 for ; Fri, 30 Oct 1998 16:10:18 -0800 (PST) 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 QAA29938 for ; Fri, 30 Oct 1998 16:10:14 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA02604 for ; Fri, 30 Oct 1998 16:10:13 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id AAA29942 for ; Sat, 31 Oct 1998 00:10:02 GMT Message-Id: <3.0.5.32.19981030161021.0084bbe0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 30 Oct 1998 16:10:21 -0800 To: ipng@sunroof.eng.sun.com From: The IESG (by way of Bob Hinden ) Subject: (IPng 6679) Last Call: Service Location Protocol, Version 2 to Proposed Standard Reply-to: iesg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the Service Location Protocol Working Group to consider publication of the following Internet-Drafts as Proposed Standards: o Service Location Protocol, Version 2 o Service Templates and service: Schemes o Service Location Protocol Modifications for IPv6 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 November 13, 1998. Files can be obtained via: ftp://ftp.ietf.org/internet-drafts/draft-ietf-svrloc-protocol-v2-10.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-svrloc-service-scheme-12.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-svrloc-ipv6-05.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 --------------------------------------------------------------------