From owner-ipng@sunroof.eng.sun.com Mon Nov 2 06:24:37 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA11813 for ipng-dist; Mon, 2 Nov 1998 06:21:17 -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 GAA11806 for ; Mon, 2 Nov 1998 06:21:06 -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 GAA25526 for ; Mon, 2 Nov 1998 06:21:03 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA10782 for ; Mon, 2 Nov 1998 06:21:03 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA16369; Mon, 2 Nov 1998 09:21:00 -0500 (EST) Message-Id: <199811021421.JAA16369@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 6681) I-D ACTION:draft-ietf-ipngwg-6over4-00.txt Date: Mon, 02 Nov 1998 09:20:55 -0500 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 : Transmission of IPv6 over IPv4 Domains without Explicit Tunnels Author(s) : B. Carpenter, C. Jung Filename : draft-ietf-ipngwg-6over4-00.txt Pages : 9 Date : 29-Oct-98 This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link- layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 network. The motivation for this method is to allow isolated IPv6 hosts, located on a physical link which has no directly connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 domain that supports IPv4 multicast as their virtual local link. It uses IPv4 multicast as a 'virtual Ethernet.' Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-6over4-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-6over4-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-6over4-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: <19981029095433.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-6over4-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-6over4-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981029095433.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 2 09:15:15 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA12239 for ipng-dist; Mon, 2 Nov 1998 09:09:16 -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 JAA12232 for ; Mon, 2 Nov 1998 09:09:07 -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 JAA00700 for ; Mon, 2 Nov 1998 09:09:05 -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 JAA13251 for ; Mon, 2 Nov 1998 09:09:05 -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 RAA08052; Mon, 2 Nov 1998 17:09:03 GMT Message-Id: <3.0.5.32.19981102090914.00a026b0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 02 Nov 1998 09:09:14 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6682) W.G. Last Call on "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels" 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 : Transmission of IPv6 over IPv4 Domains without Explicit Tunnels Author(s) : B. Carpenter, C. Jung Filename : draft-ietf-ipngwg-6over4-00.txt Pages : 9 Date : 29-Oct-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 November 16, 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 -------------------------------------------------------------------- -------------------------------------------------------------------- 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 Nov 2 09:20:24 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA12294 for ipng-dist; Mon, 2 Nov 1998 09:13:57 -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 JAA12287 for ; Mon, 2 Nov 1998 09:13:26 -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 JAA01672 for ; Mon, 2 Nov 1998 09:13:21 -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 JAA15651 for ; Mon, 2 Nov 1998 09:13:22 -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 RAA08217; Mon, 2 Nov 1998 17:11:28 GMT Message-Id: <3.0.5.32.19981102091140.00a20200@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 02 Nov 1998 09:11:40 -0800 To: narten@raleigh.ibm.com, Jeffrey Burgan From: Bob Hinden Subject: (IPng 6683) Request to Advance "A Method for the Transmission of IPv6 Packets over ARCnet Networks" 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 : 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 A working group last call for this document was completed on October 27, 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 Mon Nov 2 10:09:07 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA12634 for ipng-dist; Mon, 2 Nov 1998 10:03:28 -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 KAA12624 for ; Mon, 2 Nov 1998 10:03: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 KAA19546 for ; Mon, 2 Nov 1998 10:03:04 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA17072 for ; Mon, 2 Nov 1998 10:02:50 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA22359; Mon, 2 Nov 1998 13:02:47 -0500 (EST) Message-Id: <199811021802.NAA22359@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 6684) Last Call: A Method for the Transmission of IPv6 Packets over ARCnet Networks. to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 02 Nov 1998 13:02:47 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider A Method for the Transmission of IPv6 Packets over ARCnet Networks. 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 November 16, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-souvatzis-ipv6-arcnet-04.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 Mon Nov 2 16:17:35 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA13403 for ipng-dist; Mon, 2 Nov 1998 16:08:16 -0800 (PST) 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 QAA13396 for ; Mon, 2 Nov 1998 16:08:03 -0800 (PST) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id QAA29789; Mon, 2 Nov 1998 16:08:01 -0800 (PST) Date: Mon, 2 Nov 1998 16:08:01 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6685) Re: W.G. Last Call on "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels" To: Bob Hinden Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3.0.5.32.19981102090914.00a026b0@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The draft (in the second paragraph in section 7) is hand waving that the protocol can be used in the absense of IPv4 multicast support. I don't see how that can possibly be used without additional configuration information. For instance, consider the bootstrapping scenario: A dual host is booting. It wants to send an IPv6 Router Solicitation to the all router group. 1) How does the host know whether or not IPv4 multicast is supported in the site/subnet? It can always send IPv4 multicast packets on the wire. 2) Even once it somehow determines that IPv4 multicast is not supported how does the host determine the IPv4 unicast address(es) of the dual router(s) so that it can replicate and send the Router Solicitation using IPv4 unicast? I'd suggest completely removing that paragraph since this should be a protocol spec and not contain hand waving arguments of what might be possible without specifying or referring to the needed mechanisms and protocol elements. Perhaps the title should also be changed to Transmission of IPv6 over IPv4 Multicast Domains without Explicit Tunnels Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 3 03:42:04 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id DAA13846 for ipng-dist; Tue, 3 Nov 1998 03:39:31 -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 DAA13839 for ; Tue, 3 Nov 1998 03:39:22 -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 DAA24026; Tue, 3 Nov 1998 03:39:20 -0800 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 DAA27476; Tue, 3 Nov 1998 03:39:20 -0800 (PST) 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 LAA22136; Tue, 3 Nov 1998 11:39:17 GMT 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 LAA24052; Tue, 3 Nov 1998 11:39:17 GMT Message-ID: <363EEB32.A83C1BE@hursley.ibm.com> Date: Tue, 03 Nov 1998 11:38:26 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Erik Nordmark CC: Bob Hinden , ipng@sunroof.eng.sun.com Subject: (IPng 6686) Re: W.G. Last Call on "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, I'm fairly convinced that the hand waving could be turned into a complete definition, but it would be a bunch of work which is not obviously justified by a requirement. Personally I'd be happy to follow your suggestion, if my co-author and the WG agree. Brian Erik Nordmark wrote: > > The draft (in the second paragraph in section 7) is hand waving that the > protocol can be used in the absense of IPv4 multicast support. > I don't see how that can possibly be used without additional configuration > information. For instance, consider the bootstrapping scenario: > A dual host is booting. It wants to send an IPv6 Router Solicitation to > the all router group. 1) How does the host know whether or not IPv4 multicast > is supported in the site/subnet? It can always send IPv4 multicast packets > on the wire. 2) Even once it somehow determines that IPv4 multicast is not > supported how does the host determine the IPv4 unicast address(es) of the > dual > router(s) so that it can replicate and send the Router Solicitation > using IPv4 unicast? > > I'd suggest completely removing that paragraph since this should be a protocol > spec and not contain hand waving arguments of what might be possible without > specifying or referring to the needed mechanisms and protocol elements. > > Perhaps the title should also be changed to > Transmission of IPv6 over IPv4 Multicast Domains without Explicit Tunnels > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 Nov 3 13:58:55 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA14303 for ipng-dist; Tue, 3 Nov 1998 13:55: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 NAA14295 for ; Tue, 3 Nov 1998 13:55:33 -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 NAA22565 for ; Tue, 3 Nov 1998 13:55:30 -0800 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 NAA01294 for ; Tue, 3 Nov 1998 13:55:29 -0800 (PST) Received: by mailgate.rdg.opengroup.org; id AA27283; Tue, 3 Nov 1998 21:57:21 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 Nov 03 21:57 GMT 1998 Message-Id: <3.0.3.32.19981103214130.007c9100@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 03 Nov 1998 21:41:30 +0000 To: ipng@sunroof.eng.sun.com From: Chris Harding Subject: (IPng 6688) Non-Namespace comments on the IPv6 Basic API 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 - Here some comments on the draft Basic API to IPv6 that do not relate to namespace usage. 1. In sections 6.1, 6.2 and 6.4 the synopses of getipnodebyname(), getipnodebyaddr() and gai_strerror() give both and as include files. is not needed, and should be the only include file for all three functions. 2. In section 6.3, the synopsis of freehostent() gives as include file; this should be changed to . 3. In section 6.6, the synopsis of inet_pton() and inet_ntop() gives both and as include files. is not needed, and should be the only include file. 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 Nov 3 13:59:06 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA14296 for ipng-dist; Tue, 3 Nov 1998 13:55: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 NAA14287 for ; Tue, 3 Nov 1998 13:55:24 -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 NAA22524 for ; Tue, 3 Nov 1998 13:55:22 -0800 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 NAA01167 for ; Tue, 3 Nov 1998 13:55:19 -0800 (PST) Received: by mailgate.rdg.opengroup.org; id AA23882; Tue, 3 Nov 1998 21:57:10 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 Nov 03 21:57 GMT 1998 Message-Id: <3.0.3.32.19981103214448.007b5370@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 03 Nov 1998 21:44:48 +0000 To: ipng@sunroof.eng.sun.com From: Chris Harding Subject: (IPng 6687) Namespace Pollution and the IPv6 Basic API 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 - Here, as promised, are my comments on namespace usage in the draft Basic API to IPv6. I was asked to make them by XNET because XNET is concerned about this issue. The details of the comments, which have not been seen by other members of XNET, are however entirely my responsibility. First, my apologies for making them at such a late stage. It is true that some of the names used in the API were not finalised until recently, but much of what follows is not affected by differences between this version and the previous version. The main reason is that it has taken a considerable amount of concentrated effort to go through the draft and the relevant parts of the ISO C Standard and IEEE Std 1003.1 (POSIX), and scheduling the necessary time has been hard. Be that as it may, this is "last call", so I am calling while I can. The remainder of this message contains: - a brief discussion of namespace pollution - a summary of namespace use in P1003.1g - a summary of additional namespace use in the draft Basic API to IPv6 - requested changes that are necessary for the correctness of the draft - further requested changes that are not necessary for correctness but that would improve the draft from the point of view of namespace use. Namespace Pollution ------------------- The namespace pollution issue is discussed in section B.2.7.2 of IEEE Std 1003.1 (POSIX.1). This section contains the rationale for section 2.7.2, which is where POSIX's mechanism for dealing with namespace pollution is specified. The rationale runs to nearly 6 pages, and the following summary is necessarily somewhat over-simplified. Briefly, implementations and applications share the C namespace, and rules are needed to say who can use what. The "obvious" rule - that the implementation takes what it needs and the application can have the rest - doesn't work, because of three problems. 1. If the application writer doesn't know what the implementation has used, the application can unwittingly re-use a name, and mysteriously fail to compile. 2. Even if implementations document their namespace usage, an application that works with one implementation may fail with another implementation that uses namespace differently. So portability is compromised. 3. Even if an application is written to work with all existing implementations, a new version of the interface standard can use new names and break the application (and quite likely break implementations too). The ISO C standard is very precise about which parts of the namespace a C library can use. Most of the POSIX functions are in the forbidden part. To keep conformance with ISO C, and to address the three problems listed above, POSIX uses Feature Test Macros to control visibility of identifiers to applications. Feature Test Macros have names in the part of the namespace reserved by ISO to the implementation (eg. "_POSIX_SOURCE"). Unless a Feature Test Macro is defined by the application, the implementation will not make any identifiers visible to the application other than those allowed by ISO C. (This normally means that the application can't use any of the services that ihe implementation can provide). If the application defines a Feature Test Macro, and includes header files governed by that macro, then the identifiers defined in those headers are made visible to it, and the specification clearly states what those identifiers can be. This statement typically consists of lists of reserved identifiers, reserved prefixes, and reserved suffixes. The reasons for having reserved prefixes are (a) to enable implementations to define identifiers not explicitly listed in the standard (for example, to provide additional non-standard facilities to the application), and (b) to enable new versions of the standard to define additional identifiers within the reserved namespace. So, to regulate namespace use, a standard should define one or more Feature Test Macros and say what header files are governed by them, and what identifiers must - and what identifiers may - be made available by inclusion of those header files when the macros are defined. An added refinement is for symbol visibility to depend on what value the macro is given. So the 1998 version of a standard (say) can say that when the macro has value >= 1998 then a certain set of symbols are visible, and the 1999 version can say that a bigger set is visible when the value is >= 1999. Structure and union field names are in a slightly different category from other identifiers. Each structure or union has its own namespace for field names, but #defines can still interfere with them. POSIX says that an implementation can add field names that are not protected by Feature Test Macros, provided that this is done in such a way that a #define of one of these names by the application will not affect the implementation. Although it is possible for implementations to do this, it is rather complicated, and it is probably best if the standard reserves a prefix (protected by a Feature Test Macro) for each structure or union, so that implementations can add fields easily. It is good practice to keep the lists of reserved identifiers, prefixes and suffixes in the standards as brief as possible. For example, there could be just a single reserved prefix for each header. Standards are like sermons - the shorter the better. P1003.1g and Namespace ---------------------- The Feature Test Macro mechanism is used by P1003.1g. The following identifiers are or may be made available by the implementation when Feature Test Macro _POSIX_SOURCE is defined. When is included: prefixes in_ inet_ When is included: prefixes AI_ EAI_ ai_ h_ n_ p_ s_ individual identifiers endhostent endnetent endprotoent endservent getaddrinfo gethostbyaddr gethostbyname getnetbyaddr getnetbyname getprotobyname getprotobynumber getservbyaddr getservbyport sethostent setnetent setprotoent setservent When is included: prefixes IMPLINK_ IN_ INADDR_ IP_ IPPORT_ IPPROTO_ SOCK_ in_ s_ sin_ individual identifiers htonl htons ntohl ntohs When is included: prefixes AF_ CMSG_ MSG_ PF_ SO_ SOCK_ SOMAX cmsg_ l_ msg_ sa_ individual identifiers accept bind connect getpeername getsockname getsockopt isfdtype listen recv recvfrom recvmsg send sendmsg sendto setsockopt shutdown sockatmark socket socketpair Namespace Usage in the Basic API -------------------------------- The current draft of the Basic API to IPv6, draft-ietf-ipngwg-bsd-api-new-03.txt, makes the following namespace use in addition to that of P1003.1g. When is included: prefixes IN6_ IN6ADDR_ IPV6_ in6_ in6addr_ prefixes for field names ipv6mr_ s6_ sin6_ individual identifiers SIN6_LEN INET_ADDRSTRLEN INET6_ADDRSTRLEN ipv6_mreq sockaddr_in6 When is included: prefix (also used for field names) if_ individual identifier IFNAMSIZ When is included: prefixes NI_ individual identifiers freeaddrinfo freehostent gai_strerror getipnodebyaddr getipnodebyname getnameinfo When is included: prefixes for field names _ss_ _SS_ ss_ individual identifiers sockaddr_storage Essential Changes ----------------- The following changes should be made in order to correct incorrect statements in or impressions given by the draft. i) On page 3, at the end of the first bullet in section 2, immediately after "Simply put, the API changes for IPv6 should not break existing programs." add "This will be achieved provided that the new symbols are protected by Feature Test Macros as described in IEEE Std 1003.1. (Such Feature Test Macros are not defined by this RFC.)" ii) On page 5, at the end of the first paragraph of section 2.4, after "Additional, nonstandard members may also be defined by an implementation" add ", provided that they are protected by Feature Test Macros as described in IEEE Std 1003.1, or that user-defined macros with the same names as the nonstandard members can not interfere with the correct interpretation of the program". iii) Either change all instances of the _ss_ prefix (eg to _Ss_ or __ss_) or remove the statement in section 3.10 on page 13 "The implementation- specific definitions and structure field names start with an underscore to denote implementation private namespace" (For some reason, the ISO C standard [section 7.1.3] reserves identifiers beginning __ or _[A-Z] for any use but only reserves other identifiers beginning with underscore for use in the ordinary identifier and tag namespaces.) Changes to Improve Namespace Usage ---------------------------------- The following changes are not needed for correctness but would "clean up" the API from a namespace point of view, making it easier to implement, easier to use, and easier to enhance. These changes do not functionally affect the API in any way, they are simply changes of names. iv) Change all instances of "IN6ADDR_" to "IN6_ADDR_" v) Change all instances of "IPV6_" to "IN6_" vi) Change all instances of "in6addr_" to "in6_addr_" vii) Change "SIN6_LEN" to "IN6_SIN_LEN" viii) Change "INET_ADDRSTRLEN" to "IN_ADDRSTRLEN" and change "INET6_ADDRSTRLEN" to "IN6_ADDRSTRLEN". ix) Change "ipv6_mreq" to "in6_mreq". x) Change all instances of "ipv6mr_" to "in6_mr_" The effect of changes iv) through x) is that all new identifiers made visible by including would begin with IN6_, in6_, s6_, sin6_ or sockaddr_, which could be reserved prefixes. A further possible change in this area is change xi). xi) Define the new IN6_*, in6_*, s6_* and sin6_* symbols and sockaddr_in6 in a new header rather than in . xii) Change "IFNAMESIZ" to "IF_NAMESIZ" ("IF_" could then be a reserved prefix). 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 Nov 4 08:37:54 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA15026 for ipng-dist; Wed, 4 Nov 1998 08:34:16 -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 IAA15019 for ; Wed, 4 Nov 1998 08:34:07 -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 IAA01085 for ; Wed, 4 Nov 1998 08:34:06 -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 IAA17122 for ; Wed, 4 Nov 1998 08:33:54 -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 RAA21198; Wed, 4 Nov 1998 17:32:28 +0100 (MET) Received: (from ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.8.8) id RAA25217; Wed, 4 Nov 1998 17:32:48 +0100 (MET) Message-ID: <19981104173247.I24227@cs.uni-bonn.de> Date: Wed, 4 Nov 1998 17:32:47 +0100 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Cc: Ignatios Souvatzis , Thomas Narten Subject: (IPng 6691) Last Minute comments on "A Method for the Transmission of IPv6 Packets over ARCnet Networks" References: <199811041219.HAA00717@narten.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2i In-Reply-To: <199811041219.HAA00717@narten.cs.duke.edu>; from Thomas Narten on Wed, Nov 04, 1998 at 07:19:31AM -0500 X-Mutt-References: <199811041219.HAA00717@narten.cs.duke.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I received a few comments by Thomas Narten, some of turned out not to be purely editorial... I'll try to summarize and add my notes, with questions to the WG: (> > lines are by me (draft or comment), > lines are by TN) Thomas Narten wrote: > > The protocol id used is D4 hexadecimal, the same as for IPv4. IPv6 > > packets are recognized by looking at the version number in the high > > half of the first octet of the data, which is 4 for IPv4 and 6 for > > IPv6. This method of distinguishing IPv6 packets was chosen because > > there are only 256 values of ARCnet protocol ids available. > > I note that this is inconsistent with the IPng position that all link > layer types provide a way to identify IPv6 packets as distinct from > IPv4. The above will also make it impossible to implement Header > Compression as outlined in draft-degermark-ipv6-hc-06.txt on ARCnet > links. Is this a potential problem? Currently, there are no plans to implement header compression over ARCnet. Rereading the header compression paper, I note that header compression is aimed at slow to medium speed point to point style links, with some sort of link level negotiation protocol. So it would not be really desirable to implement header compression for ARCnet (at 2.5 MBit/s) (or Ethernet, FDDI, Token Ring...) Am I correct? > > Should that be planned, I guess it might be possible to get an additional > > "Protocol ID" from Datapoint Corporation for this use. They were not willing > > to give out an additional ID as long as none is needed. (Back then, when I > > asked, there was no generic header compression specification.) > The problem with > asking for a code point later (rather than now) is that you'll have to > deal with already deployed boxes that don't understand the new code > point. Even if somebody planned later to implement header compression for IPv6 over ARCnet: - it would like as many as 6 protocol ids. - if it can't have them, it can multiplex its packet types over a single protocol id with normal IPv6, by using a prefix byte and the first header nibble. => As I understand, it would be possible to route normal IPv6 over one ID and only the header compression variant over a seperate one. Is this correct? (If you think that header compression should never be implemented for ARCnet, dont bother to think about this issue ;-) > > The maximum IPv6 packet length possible using this encapsulation > > method is 60480 octets. Since this length is impractical because of > > its worst case transmission time of several seconds, all ARCnet > > implementations on a given ARCnet network should agree on a smaller > > value. > > > > Implementations SHOULD support an MTU of 9072 octets and MUST support > > the minimum MTU required by [IPV6]. > My read of the above is that the intention is that all ARCnet links > support an MTU of 9072 and that this be the default value unless > otherwise configured. If so, I'd like to see that wording made more > explicit. In particular, use MUST rather than SHOULD? Also (and this > is the reason why I think MUST makes sense), how about adding a > sentence along the lines of: > In the absence of explicit configuration (e.g., via reciept of > an MTU option in a Neigbor Advertisement message), the default > MTU for an ARCnet link is 9072 octets. > > I wanted to allow consenting implementations that can not receive > > 18-fragment (thats 9072 bytes) packets to coexist on a link. Embedded > > applications might want to make use of this. (9072 is for normal > > workstation/server use). > That goal seems fine. At the same time, in order to simplify > configuration it is desirable for there to be a standard configuration > that "works out of the box" without any configuartion. Thus, I think > that there should be one value that is defined to be the default. That > value can always be changed to a larger value if useful, and if the > system administrator has knowledge that all devices can support a > larger value. What I think is undesirable is to have it be possible > for "embedded applications" to use a small MTU (and not violate the > spec) while others use a different and incompatible MTU by > default. This would lead to interoperability problems. > > Note: I don't care what the exact MTU value is, I just care that > there be a well-defined one. This seems important to me. I'd still want the default value to be 9072 (thats 18 times 504 in case someone wonders) and consider to change the SHOULD to a "MUST", unless somebody tells me this is a real problem for embedded implementations. Also I think, that another sentence should be added: The MTU MAY only be enlarged above the value of 9072 using either router advertisements or manual configuration, if it is positively known that all connected nodes can receive packets of a larger size. I prepared an updated draft, containing editorial changes/corrections suggested by TN, and a strengthened "security" paragraph, available as http://www.rhein.de/~is/arcipv6.04c My intent is to add the above changes, and resubmit the paper. Btw: for conformity, I'd delete the "A method for the" from the title, as has happened with the other IPv6 over link documents. Is this ok at this stage of affairs? 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 Wed Nov 4 09:19:36 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA15139 for ipng-dist; Wed, 4 Nov 1998 09:16:03 -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 JAA15132 for ; Wed, 4 Nov 1998 09:15:53 -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 JAA12384 for ; Wed, 4 Nov 1998 09:15:51 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.9.1/8.9.1) with SMTP id JAA15045 for ; Wed, 4 Nov 1998 09:15:46 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA11633; Wed, 4 Nov 98 09:12:54 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id JAA07117; Wed, 4 Nov 1998 09:13:56 -0800 Date: Wed, 4 Nov 1998 09:13:56 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199811041713.JAA07117@feller.mentat.com> To: ipng@sunroof.eng.sun.com, ignatios@theory.cs.uni-bonn.de Subject: (IPng 6692) Re: Last Minute comments on "A Method for the Transmission of IPv6 Packets over ARCnet Networks" Cc: narten@cs.duke.edu X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ignatios, > > > > The protocol id used is D4 hexadecimal, the same as for IPv4. IPv6 > > > packets are recognized by looking at the version number in the high > > > half of the first octet of the data, which is 4 for IPv4 and 6 for > > > IPv6. This method of distinguishing IPv6 packets was chosen because > > > there are only 256 values of ARCnet protocol ids available. > > > > I note that this is inconsistent with the IPng position that all link > > layer types provide a way to identify IPv6 packets as distinct from > > IPv4. The above will also make it impossible to implement Header > > Compression as outlined in draft-degermark-ipv6-hc-06.txt on ARCnet > > links. Is this a potential problem? > > Currently, there are no plans to implement header compression over ARCnet. > > Rereading the header compression paper, I note that header compression > is aimed at slow to medium speed point to point style links, with some > sort of link level negotiation protocol. So it would not be really desirable > to implement header compression for ARCnet (at 2.5 MBit/s) (or Ethernet, > FDDI, Token Ring...) > Am I correct? > Unfortunately, there were other reasons for the IPng WG specifying that the link-layer provide a mechanism for distinguishing IPv4 from IPv6 packets. The principle reason was that it was assumed that a large percentage of the deployed IPv4 implementations would not check the version number. Indeed, at the time multiple vendors admitted as much. This lack of robustness in deployed IPv4 implementations could lead to problems when IPv6 packets suddenly start to arrive at those nodes. Header compression had nothing to do with the issue at the time but it is an issue now assuming that anyone would be interested in running header compression over ARCnet. My preference would be that there be a seperate "Protocol ID" for IPv6 since our implementation depends on this feature. I believe other implementations do as well. Tim Hartrick Mentat 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 Nov 4 14:58:36 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA15441 for ipng-dist; Wed, 4 Nov 1998 14:53:26 -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 OAA15434 for ; Wed, 4 Nov 1998 14:53:16 -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 OAA18580 for ; Wed, 4 Nov 1998 14:53:14 -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 OAA08891 for ; Wed, 4 Nov 1998 14:53:12 -0800 (PST) Received: from cosinus.cs.uni-bonn.de (IDENT:root@cosinus.cs.uni-bonn.de [131.220.4.181]) by theoryx.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id XAA21737; Wed, 4 Nov 1998 23:51:51 +0100 (MET) Received: (from ignatios@localhost) by cosinus.cs.uni-bonn.de (8.8.8/8.8.8) id UAA01647; Wed, 4 Nov 1998 20:59:42 +0100 (CET) Message-ID: <19981104205942.C1465@cosinus.cs.uni-bonn.de> Date: Wed, 4 Nov 1998 20:59:42 +0100 From: Ignatios Souvatzis To: Tim Hartrick , ipng@sunroof.eng.sun.com, ignatios@theory.cs.uni-bonn.de Cc: narten@cs.duke.edu Subject: (IPng 6693) Re: Last Minute comments on "A Method for the Transmission of IPv6 Packets over ARCnet Networks" References: <199811041713.JAA07117@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811041713.JAA07117@feller.mentat.com>; from Tim Hartrick on Wed, Nov 04, 1998 at 09:13:56AM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Nov 04, 1998 at 09:13:56AM -0800, Tim Hartrick wrote: > > > > Ignatios, > > > > > > > The protocol id used is D4 hexadecimal, the same as for IPv4. IPv6 > > > > packets are recognized by looking at the version number in the high > > > > half of the first octet of the data, which is 4 for IPv4 and 6 for > > > > IPv6. This method of distinguishing IPv6 packets was chosen because > > > > there are only 256 values of ARCnet protocol ids available. > The principle reason was that it was assumed that a large percentage of the > deployed IPv4 implementations would not check the version number. Indeed, > at the time multiple vendors admitted as much. This lack of robustness in > deployed IPv4 implementations could lead to problems when IPv6 packets > suddenly start to arrive at those nodes. Ok. ... e.g. all Net/2 derived, unless repaired later. 4.4BSDlite does. To see how much of a problem this would create, if we dont get a number: How many of them do have ARCnet support? BSD never had, before NetBSD. > My preference would be that there be a seperate "Protocol ID" for IPv6 since > our implementation depends on this feature. I believe other implementations > do as well. Bob Hinden has offered to ask for one ex officio. Lets wait for the result. 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 Wed Nov 4 19:19:52 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA15805 for ipng-dist; Wed, 4 Nov 1998 19:10:41 -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 TAA15798 for ; Wed, 4 Nov 1998 19:10:33 -0800 (PST) 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 TAA09101 for ; Wed, 4 Nov 1998 19:10:31 -0800 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 TAA05553 for ; Wed, 4 Nov 1998 19:10:33 -0800 (PST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0a) with SMTP id WAA08865; Wed, 4 Nov 1998 22:10:30 -0500 (EST) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA26610; Wed, 4 Nov 1998 22:10:29 -0500 Message-Id: <199811050310.AA26610@quarry.zk3.dec.com> To: Chris Harding Cc: ipng@sunroof.eng.sun.com, xnet@opengroup.org, bound@zk3.dec.com Subject: (IPng 6694) Re: Non-Namespace comments on the IPv6 Basic API In-Reply-To: Your message of "Tue, 03 Nov 1998 21:41:30 GMT." <3.0.3.32.19981103214130.007c9100@mailhome.rdg.opengroup.org> Date: Wed, 04 Nov 1998 22:10:28 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Chris, >Here some comments on the draft Basic API to IPv6 that do not relate to >namespace usage. >1. In sections 6.1, 6.2 and 6.4 the synopses of getipnodebyname(), >getipnodebyaddr() > and gai_strerror() give both and as include files. > is not needed, and should be the only include >file for > all three functions. You need sys/socket.h to support access to AF_INET and AF_INET6. >2. In section 6.3, the synopsis of freehostent() gives as >include file; > this should be changed to . This is valid. >3. In section 6.6, the synopsis of inet_pton() and inet_ntop() gives both > and as include files. is not >needed, > and should be the only include file. You need sys/socket.h to support access to AF_INET and AF_INET6. thanks /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 -------------------------------------------------------------------- -------------------------------------------------------------------- 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 Nov 4 19:52:14 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA15860 for ipng-dist; Wed, 4 Nov 1998 19:48:21 -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 TAA15853 for ; Wed, 4 Nov 1998 19:48:08 -0800 (PST) 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 TAA14629 for ; Wed, 4 Nov 1998 19:48:08 -0800 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 TAA21153 for ; Wed, 4 Nov 1998 19:48:07 -0800 (PST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0a) with SMTP id WAA12178; Wed, 4 Nov 1998 22:48:04 -0500 (EST) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA03783; Wed, 4 Nov 1998 22:48:04 -0500 Message-Id: <199811050348.AA03783@quarry.zk3.dec.com> To: Chris Harding Cc: ipng@sunroof.eng.sun.com, xnet@opengroup.org, bound@zk3.dec.com Subject: (IPng 6695) Re: Namespace Pollution and the IPv6 Basic API In-Reply-To: Your message of "Tue, 03 Nov 1998 21:44:48 GMT." <3.0.3.32.19981103214448.007b5370@mailhome.rdg.opengroup.org> Date: Wed, 04 Nov 1998 22:48:03 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Wrking Group colleagues this is my response to Chris Harding's input. Please respond by Nov 11th to the list if you support this spec or disagree with my response. Silence is acceptance we keep the spec as is and do not make these changes for this case. But I do ask implementors to please support not doing this if resultant mail frenzy begins. Based on the Working Group input on Nov 11th we will need to finish our last call (which is a week late now thanks to this very late input on the very last day of the last call) and move this spec forward to replace RFC 2133 Info RFC, if accepted by the Chairs. I do not believe these changes are warranted and our namespace has been tested in practice not theory. I do not see the value of causing this extra work for implementors of IPv6 and reject 98% of Chris's input. The name space has already proved pollution does not exist on our platforms from this WG. In addition I recommend if XNET in its standards arena wishes to produce an update to this work it may do so as part of its process. But it is up to this working group to decide. If you want these changes I will do the editing and it will take me probably sometime, but I will do it as expediently as possible if we have consensus. And in this case a rough consensus is simply not enough as it is too much work, as any who implement this stuff will tell you, and I am one who implements it too. >Namespace Usage in the Basic API >-------------------------------- > >The current draft of the Basic API to IPv6, >draft-ietf-ipngwg-bsd-api-new-03.txt, makes the following namespace use in >addition to that of P1003.1g. We do not reference P1003.1g in any manner and it is my highly educated and implementation recommendation to the IETF WG we not, except in the case of getaddrinfo/getnameinfo(), and that was a consession on this working groups part in the IETF as we don't own that spec. We did move to the datatypes for 1003.1 as a consensus but we have not adopted any mandatory reqs and all datatypes are examples in this spec. Many of our future implementations are not 1003.1 compliant nodes like Routers, Embedded Systems and Devices. 1003.1 also has not seen the light of day in the real world and most users and ISVs don't care who write code apps for TCP/IP. 1003.1 may have been important had TCP/IP lost the protocol wars cause then other standards bodies would have been more relevant to networking in the real world. Today they are not except at the datalink layer. I would claim that the work we have done here for the Basic API is bigger and more implemented than 1003.1 and POSIX itself. The reason is that the IETF implementors built this spec not a standards body. This is what we will use and have tested and interoperated against. It may not work in theory but it does in practice. Our Basic API has both rough consensus and running code. >Essential Changes >----------------- >The following changes should be made in order to correct incorrect >statements in or impressions given by the draft. > > i) On page 3, at the end of the first bullet in section 2, immediately > after "Simply put, the API changes for IPv6 should not break existing > programs." add "This will be achieved provided that the new symbols are > protected by Feature Test Macros as described in IEEE Std 1003.1. > (Such Feature Test Macros are not defined by this RFC.)" We do not need this and we should not add this language. Not all implementors need comply to 1003.1 nor are interested in all cases in doing so. Especially the use of a 1003.1 Feature Test Macro. My recommendation to the WG is to not accept this change request. > ii) On page 5, at the end of the first paragraph of section 2.4, after > "Additional, nonstandard members may also be defined by an > implementation" add ", provided that they are protected by Feature Test > Macros as described in IEEE Std 1003.1, or that user-defined macros >with > the same names as the nonstandard members can not interfere with the > correct interpretation of the program". Same as previous response. > iii) Either change all instances of the _ss_ prefix (eg to _Ss_ or __ss_) or > remove the statement in section 3.10 on page 13 "The implementation- > specific definitions and structure field names start with an > underscore to denote implementation private namespace" (For some >reason, > the ISO C standard [section 7.1.3] reserves identifiers beginning __ > or _[A-Z] for any use but only reserves other identifiers beginning >with > underscore for use in the ordinary identifier and tag namespaces.) We should adopt this input and fix section 3.10. >Changes to Improve Namespace Usage >---------------------------------- > >The following changes are not needed for correctness but would "clean up" the >API from a namespace point of view, making it easier to implement, easier to >use, and easier to enhance. These changes do not functionally affect the API >in any way, they are simply changes of names. My recommendation to the Working Group is to not support this change request and it is not needed or provides a 100% gurantee that we will have no name space pollution. Per the input below. Except for IFNAMSIZ which was a problem for one implementor we have already fixed it, as we have for all implementors. Also the WG discussed long ago the issue of having a separate in6.h and it was decided thru consensus that in6.h would not be called out in the discussions. An implementation can include an in6.h within in.h if it deems that appropriate. So I say "nay" to all requests except IFNAMSIZ. ========================================================= iv) Change all instances of "IN6ADDR_" to "IN6_ADDR_" v) Change all instances of "IPV6_" to "IN6_" vi) Change all instances of "in6addr_" to "in6_addr_" vii) Change "SIN6_LEN" to "IN6_SIN_LEN" viii) Change "INET_ADDRSTRLEN" to "IN_ADDRSTRLEN" and change "INET6_ADDRSTRLEN" to "IN6_ADDRSTRLEN". ix) Change "ipv6_mreq" to "in6_mreq". x) Change all instances of "ipv6mr_" to "in6_mr_" The effect of changes iv) through x) is that all new identifiers made visible by including would begin with IN6_, in6_, s6_, sin6_ or sockaddr_, which could be reserved prefixes. A further possible change in this area is change xi). xi) Define the new IN6_*, in6_*, s6_* and sin6_* symbols and sockaddr_in6 in a new header rather than in . xii) Change "IFNAMESIZ" to "IF_NAMESIZ" ("IF_" could then be a reserved prefix). ======================================= /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 Nov 4 20:23:26 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id UAA15923 for ipng-dist; Wed, 4 Nov 1998 20:20:23 -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 UAA15916 for ; Wed, 4 Nov 1998 20:20:11 -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 UAA19524 for ; Wed, 4 Nov 1998 20:20:11 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.9.1/8.9.1) with SMTP id UAA08048 for ; Wed, 4 Nov 1998 20:20:11 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA16795; Wed, 4 Nov 98 20:19:31 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id UAA07424; Wed, 4 Nov 1998 20:20:33 -0800 Date: Wed, 4 Nov 1998 20:20:33 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199811050420.UAA07424@feller.mentat.com> To: c.harding@opengroup.org, bound@zk3.dec.com Subject: (IPng 6696) Re: Namespace Pollution and the IPv6 Basic API Cc: ipng@sunroof.eng.sun.com, xnet@opengroup.org X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > I do not believe these changes are warranted and our namespace has been > tested in practice not theory. I do not see the value of causing this > extra work for implementors of IPv6 and reject 98% of Chris's input. > The name space has already proved pollution does not exist on our > platforms from this WG. > > In addition I recommend if XNET in its standards arena wishes to produce > an update to this work it may do so as part of its process. > > But it is up to this working group to decide. If you want these changes > I will do the editing and it will take me probably sometime, but I will > do it as expediently as possible if we have consensus. And in this case > a rough consensus is simply not enough as it is too much work, as any > who implement this stuff will tell you, and I am one who implements it > too. > I agree that most of these cosmetic name changes are unnecessary. I am personally pretty tired of changing the names of constants back and forth. My only concern and it should be a concern to you as well is that XNET will unilaterally make these changes to the XNET documents. This would be real bad for implementors that need X/Open branding. If someone deploys using the current draft and then they need to get X/Open branding in the future it will require a new second name for almost everything related to IPv6. That would be real bad. What I would like to know from Chris is what are the consequences if this group gives his requests the thumbs down. Will X/Open then turn around and make the changes unilaterally thus putting folks who need X/Open branding squarely between a rock and a hard place in terms of the namespace problem. No matter what X/Open does the problem is solvable via appropriate pre- processor conditionals however it sure would be nice not to have two defines for the same constant toggled based on whether the application is trying to be X/Open or IETF "compliant". So what is the word Chris? Tim Hartrick Mentat 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 Thu Nov 5 04:13:10 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA16156 for ipng-dist; Thu, 5 Nov 1998 04:09:04 -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 EAA16149 for ; Thu, 5 Nov 1998 04:08:53 -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 EAA11542 for ; Thu, 5 Nov 1998 04:08:51 -0800 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 EAA10580; Thu, 5 Nov 1998 04:08:51 -0800 (PST) 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 VAA24755; Thu, 5 Nov 1998 21:08:33 +0900 (JST) To: nordmark@sun.com, narten@raleigh.ibm.com, bsimpson@MorningStar.com cc: ipng@sunroof.eng.sun.com Subject: (IPng 6697) discovery-v2-03 questions (neighbor cache handling) 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 From: Jun-ichiro itojun Itoh Date: Thu, 05 Nov 1998 21:08:33 +0900 Message-ID: <24751.910267713@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I got several questions related to ND6 protocol spec, namely discovery-v2-03. In the following, "lladdr" means "link-layer address", such as ethernet MAC address. I would like to know opinions from implementers, how UNH interop test understands the spec, and so forth. Thanks, itojun@kame.net itojun@iijlab.net jun-ichiro itoh 1. neighbor cache processing rule when no lladdr is attached. ============================================================= ND6 specification defines the following conditions for src/dst lladdr option, for each ND6 packet type: RS: medium w/o lladdr: not needed (can't attach) medium with lladdr: source lladdr option SHOULD be included, if lladdr is known RA: medium w/o lladdr: not needed (can't attach) medium with lladdr: router MAY attach source lladdr option, MAY omit it for load balancing NS: medium w/o lladdr: not needed (can't attach) medium with lladdr: source lladdr option MUST be attached for multicast solicitation, SHOULD be attached for unicast solicitation redirect: medium w/o lladdr: not needed (can't attach) medium with lladdr: target lladdr option SHOULD be included if known. (ATM) MUST be included on some medium. As seen in the above list, it is not rare to see RS/RA/NS/redirect packet, WITHOUT source/target lladdr option. However, the following sections in discovery-v2-03 assume that source/target lladdr is attached to ND packet: 6.2.6(RS) 6.3.4(RA) 7.2.3(NS) 8.3(redirect) appendix C, second state transition chart (p87 to p88) must be clarified for the following 3 cases: medium without lladdr medium with lladdr, packet with lladdr medium with lladdr, packet without lladdr This should be fixed. Also, 6.2.6, 6.3.4, 7.2.3 and 8.3 has almost the same textual description for neighbor cache updates. I believe these duplicates should be merged into one section somewhere. It is not very trivial to clarify. Choices might be: 1. do not make neighbor cache if there's no lladdr, or 2. make neighbor cache with some state. However, these ways do not work very well. 1. If you do not make neighbor cache entry: You cannot record IsRouter flag, and you will have chances for stale entry on default router list. For example, the following list of event will create a stale entry: router X transmits RA without lladdr. Host Y will install default router list entry for X. No neighbor cache entry created. router X becomes host. host X (previously router X) transmits NS with lladr. Default router list entry for X remains on the host Y. Neighbor cache entry will be created, with IsRouter 0, based on NS processing rule. Now, you got a problem. If you try to send a packet to off-link destination, you will be sending packet to host X. If host Y ignores "RA without lladdr", there will be no stale default router list entry. However, in this case, router X can never achieve load balancing among the routers by sending "RA without lladdr" from routers. The source of the problem is recaped in the second question, "neighbor cache entry and default router list". See the last part of the email. What should on medium without lladdr? It is still unclear for us. 2a. If you make neighbor cache entry with INCOMPLETE state: INCOMPLETE state does not really fit this situation. INCOMPLETE is defined as: Address resolution is in progress and the link-layer address of the neighbor has not yet been determined. However, we have never performed address resolution for this entry. It is not good to require address resolution for every "RA without lladdr". 2b. If you make neighbor cache entry with some state other than INCOMPLETE If there is an entry with non-INCOMLETE state, it is assumed that the entry once has lladdr for the target in the past. Therefore, it is not very suitable for this situation. If you set the state to STALE you have a big problem --- DELAY state will defer your future address resolution. Here are solutions we came up with. Solution 1: (from jinmei@kame.net) If a node receives ND packet without lladdr, do not make neighbor cache. If node is about to send a pacet to off-link destination, and router X is chosen from default router list, and there is no neighbor cache entry for router X, node should perform the following. - make neighbor cache entry - set it INCOMPLETE - set IsRouter bit for the entry - perform neighbor discovery - transmit packet if ND completed /* * new entry: neighbor cache entrys is created * olladdr: neighbor cache entry got old lladdr * lladdr: packet contains lladdr option * llchange: olladdr != lladdr * * newentry olladdr lladdr llchange (*=record lladdr) * 0 n n -- (1) * 0 y n -- (2) * 0 n y -- (3) * set state to STALE * 0 y y n (4) * * 0 y y y (5) * set state to STALE * 1 -- n -- (6) (don't create entry) * 1 -- y -- (7) * set state to STALE */ Solution 2: (from itojun@kame.net) Define a new neighbor cache state, PASSIVE. PASSIVE entry will be made when a node received ND packets without lladdr. If a node received RA/RS/NS/redirect without lladdr option, 1. create neighbor cache entry, 2. make it PASSIVE state, and 3. set IsRouter flag properly. You MUST NOT remove neighbor cache entry for node A, if node A is listed in default router list. The above rule still works if there's no lladdr defined for the medium. /* * new entry: neighbor cache entrys is created * olladdr: neighbor cache entry got old lladdr * lladdr: packet contains lladdr option * llchange: olladdr != lladdr * * newentry olladdr lladdr llchange (*=record lladdr) * 0 n n -- (1) * 0 y n -- (2) * 0 n y -- (3) * set state to STALE * 0 y y n (4) * * 0 y y y (5) * set state to STALE * 1 -- n -- (6) set state to PASSIVE * 1 -- y -- (7) * set state to STALE */ /* * ICMP6 type dependent behavior. * * NS: clear IsRouter if new entry * RS: clear IsRouter * RA: set IsRouter if there's lladdr * redir: clear IsRouter if new entry * * newentry olladdr lladdr llchange NS RS RA redir * 0 n n -- (1) c s? * 0 y n -- (2) c s * 0 n y -- (3) c s * 0 y y n (4) c s * 0 y y y (5) c s * 1 -- n -- (6) c c s? c * 1 -- y -- (7) c c s c * * (c=clear s=set) */ Clarification 1: To make implementations easy, rules for source/target lladdr option for ND packets should be: - on medium with lladdr: MUST attach one - on medium w/o lladdr: not needed (and cannot attach) 2. neighbor cache entry and default router list =============================================== Rules for IsRouter bit is "edge trigger" in nature. Therefore, IsRouter rule works only if the following statement is satisfied: For a node that is listed onto default router list, there always be a neighbor cache entry. This must be clearly stated somewhere in document. (What happens on medium ithout lladdr?? We still need to make neighbor cache entry just for IsRouter bit) IsRouter bit must be revisited, really. -------------------------------------------------------------------- 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 Nov 5 06:11:32 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA16216 for ipng-dist; Thu, 5 Nov 1998 06:08:32 -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 GAA16209 for ; Thu, 5 Nov 1998 06:08:23 -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 GAA21712 for ; Thu, 5 Nov 1998 06:08:21 -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 GAA28951 for ; Thu, 5 Nov 1998 06:06:08 -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 PAA24062 for ; Thu, 5 Nov 1998 15:05:45 +0100 (MET) Received: (from ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.8.8) id PAA27646; Thu, 5 Nov 1998 15:06:06 +0100 (MET) Message-ID: <19981105150604.A27087@cs.uni-bonn.de> Date: Thu, 5 Nov 1998 15:06:04 +0100 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Subject: (IPng 6698) ARCnet over IPv6: MTU text. 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 Hello, it was suggested to me that the MTU should be defined in a more binding way, to ensure interoperability. I agree. My new text changes this: --- draft-souvatzis-ipv6-arcnet-04.ms 1998/11/05 13:30:00 1.5 +++ draft-souvatzis-ipv6-arcnet-04.ms 1998/11/05 13:51:33 @@ -90,8 +90,7 @@ implementations on a given ARCnet network should agree on a smaller value. -Implementations SHOULD support an MTU of 9072 octets and MUST support -the minimum MTU required by [IPV6]. +The default MTU for IPv6 [IPV6] packets on an ARCnet is 9072 octets. In the presence of a router, this size MAY be changed by a Router Advertisement [DISC] containing an MTU option. If a Router The full text is available as http://www.rhein.de/~is/arcipv6.04d. Comments to me, or maybe the list. -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 Thu Nov 5 07:04:43 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA16255 for ipng-dist; Thu, 5 Nov 1998 06:55:58 -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 GAA16248 for ; Thu, 5 Nov 1998 06:55:50 -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 GAA28666 for ; Thu, 5 Nov 1998 06:55:47 -0800 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 GAA25134 for ; Thu, 5 Nov 1998 06:55:47 -0800 (PST) Received: from flume.zk3.dec.com (yflume.zk3.dec.com [16.140.16.14]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0a) with SMTP id JAA08872; Thu, 5 Nov 1998 09:55:42 -0500 (EST) Received: from brywasted.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA06926; Thu, 5 Nov 1998 09:55:42 -0500 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id JAA0000016184; Thu, 5 Nov 1998 09:55:42 -0500 (EST) From: Jim Bound Message-Id: <199811051455.JAA0000016184@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: thartric@mentat.com (Tim Hartrick) Cc: c.harding@opengroup.org, bound@zk3.dec.com, ipng@sunroof.eng.sun.com, xnet@opengroup.org Subject: (IPng 6699) Re: Namespace Pollution and the IPv6 Basic API In-Reply-To: Your message of "Wed, 04 Nov 1998 20:20:33 PST." <199811050420.UAA07424@feller.mentat.com> Date: Thu, 05 Nov 1998 09:55:42 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, I agree with your concerns and the WG should consider it. I agree also what is Chris's intention, we need to here? ALso there are other datapoints: 1. Not all implementations are 1003.1 compliant so that wording in this spec should never happen regardless of what XNET does. 2. XNET is not what it was yesterday. I am not sure anyone cares about XNET or TOG in the market. This should be verified though. 3. Representatives for XNET is a closed body as far as meetings etc. The members I am aware of now are (and Chris correct me if I miss someone): Compaq Sun HP IBM I for one from Compaq will put on my company hat if our spec is accepted as is to sugggest to other members of XNET we leave the IETF Base API spec in place, and not change it. If Sun, HP, and IBM do the same Chris's proposal would not see the light of day in XNET. 4. Lastly it is not up to Chris and it is up to the XNET members and I am on that mail list too. So the question may be will Sun, IBM, HP, and Compaq vote for this not being supported by XNET and leaving the spec as is. On this mail list I am wearing my individual hat not my company hat as best I can. I for one don't like the idea the more I think about it 4 (or a few more) vendors controling what this API does or does not do. I think that is bogus as a standards participant and if this WG does not believe the changes are needed they should not be made. We should not change our spec because XNET changes it, the spec should just pass thru XNET without this change are my thoughts now. /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 Thu Nov 5 07:16:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA16277 for ipng-dist; Thu, 5 Nov 1998 07:12:35 -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 HAA16270 for ; Thu, 5 Nov 1998 07:12:21 -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 HAA01892 for ; Thu, 5 Nov 1998 07:12:15 -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 HAA06014 for ; Thu, 5 Nov 1998 07:12:01 -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 QAA24240; Thu, 5 Nov 1998 16:11:37 +0100 (MET) Received: (from ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.8.8) id QAA27771; Thu, 5 Nov 1998 16:11:58 +0100 (MET) Message-ID: <19981105161157.C27087@cs.uni-bonn.de> Date: Thu, 5 Nov 1998 16:11:57 +0100 From: Ignatios Souvatzis To: Ignatios Souvatzis , ipng@sunroof.eng.sun.com Subject: (IPng 6700) Re: ARCnet over IPv6: MTU text. References: <19981105150604.A27087@cs.uni-bonn.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2i In-Reply-To: <19981105150604.A27087@cs.uni-bonn.de>; from Ignatios Souvatzis on Thu, Nov 05, 1998 at 03:06:04PM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk oops. make that subject: IPv6 over ARCnet -------------------------------------------------------------------- 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 Nov 5 09:29:26 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA16489 for ipng-dist; Thu, 5 Nov 1998 09:24:57 -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 JAA16479 for ; Thu, 5 Nov 1998 09:24:43 -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 JAA05318 for ; Thu, 5 Nov 1998 09:24:39 -0800 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 JAA08535 for ; Thu, 5 Nov 1998 09:24:37 -0800 (PST) Received: by mailgate.rdg.opengroup.org; id AA15840; Thu, 5 Nov 1998 17:26:23 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 ; Thu Nov 05 17:26 GMT 1998 Message-Id: <3.0.3.32.19981105171613.007d7100@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 05 Nov 1998 17:16:13 +0000 To: ipng@sunroof.eng.sun.com From: Chris Harding Subject: (IPng 6701) Re: Namespace Pollution and the IPv6 Basic API 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 - Let me try to reply to Jim's and Tim's comments in one message. First, regarding the Feature Test Macros. These comments are largely a matter of preciseness of language. The Basic API as per the draft is unlikely to break existing applications. But you can't _guarantee_ this without Feature Test Macros, or some equivalent mechanism. So I suggested that they be mentioned - but not specified - in the basic API. It won't necessarily hurt if they are not mentioned because this is the sort of thing that can be added in a formal standard without overly disturbing implementations or applications, and perhaps a formal standard is the appropriate place to do this. For clarification, the specific reference I was suggesting be included in the Basic API is to IEEE Standard 1003.1 - the main POSIX Standard that covers fork(), exec(), open(), close(), wait(), and about a thousand other well-known operating system primitives - rather than to P1003.1g which is the draft extension to it for networking services. I also listed the namespace reservations made by P1003.1g, but purely as background to the proposed name changes. Actually, I care a lot more about the proposed name changes than about the Feature Test Macros, because they will make the API easier to use. If IPv6 and the Basic API to it are successful, there will be many more programmers using the API than implementing it. And while an implementor may spend several working years on what goes behind the API, and know every wrinkle, the main concerns of the user are typically elsewhere. A user will want to spend as little time as possible understanding a service API, and API designers will do well to make things easy for users. There are cases where the complexity of protocol APIs have inhibited their take-up and have inhibited use of the protocols. But I would not advocate, and I don't think that any of the present members of XNET would advocate, changing the names after they have been agreed in the IETF. I (and I think they) fully agree with Jim and Tim that this would not be the right road to go down. It would confuse matters at what will be a crucial time for deployment of IPv6. That is why I make the proposal, in the IETF forum, at this time. I do so in the belief that the ipng is the body responsible for the design of the Basic API, and will accept the implications of that responsibility. These include giving thought to usability of the API, and to compatibility with related standards produced by the wider API community. Finally, in view of Jim's most recent mail, I have a question for the IETF. I have been to several IETF meetings now, and attended working group meetings that filled their rooms and overflowed into the corridors, but at which fewer people spoke than normally do at meetings of XNET, which as Jim points out are much more sparsely attended. I have then been to Plenary sessions at which someone complains about this situation and stresses the need for wider input. So I have to ask, is the IETF an open forum in which comments made by anyone will be given due consideration, provided they are made in due form, or is there a closed circle of the "chosen few" who welcome outside participation only when it gives them rubber stamp approval? 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 Thu Nov 5 12:47:54 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA16897 for ipng-dist; Thu, 5 Nov 1998 12:42:48 -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 MAA16890 for ; Thu, 5 Nov 1998 12:42:40 -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 MAA16323 for ; Thu, 5 Nov 1998 12:41:51 -0800 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 MAA29146 for ; Thu, 5 Nov 1998 12:41:45 -0800 (PST) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Thu, 5 Nov 1998 12:41:32 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81607@RED-MSG-50> From: Richard Draves To: "'Jun-ichiro itojun Itoh'" , nordmark@Sun.COM, narten@raleigh.ibm.com, bsimpson@MorningStar.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6702) RE: discovery-v2-03 questions (neighbor cache handlin g) Date: Thu, 5 Nov 1998 12:41:30 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Our MSR IPv6 implementation follows your second suggested solution. Our INCOMPLETE state has two flavors, one which corresponds to your PASSIVE state (no soliciting) and one in which we are actively soliciting to resolve the address. So for the case of receiving an RA without a source link-layer address option, the end result is that we create an NCE in the "passive" INCOMPLETE state with IsRouter = TRUE. If we should try to send to that neighbor, then we start soliciting at that point. As you suggest, we also keep permanently NCEs corresponding to routers on the default router list. This is done with a reference count - we only reclaim NCEs that have zero references, and the default router list holds a reference for the corresponding NCEs. However this appears to me to be an implementation choice. Rich > -----Original Message----- > From: Jun-ichiro itojun Itoh [mailto:itojun@iijlab.net] > Sent: Thursday, November 05, 1998 4:09 AM > To: nordmark@Sun.COM; narten@raleigh.ibm.com; bsimpson@MorningStar.com > Cc: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 6697) discovery-v2-03 questions (neighbor > cache handling) > > > I got several questions related to ND6 protocol spec, namely > discovery-v2-03. In the following, "lladdr" means "link-layer > address", such as ethernet MAC address. > > I would like to know opinions from implementers, how UNH interop > test understands the spec, and so forth. Thanks, > > itojun@kame.net > itojun@iijlab.net > jun-ichiro itoh > > > 1. neighbor cache processing rule when no lladdr is attached. > ============================================================= > ND6 specification defines the following conditions for > src/dst lladdr option, > for each ND6 packet type: > RS: medium w/o lladdr: not needed (can't attach) > medium with lladdr: source lladdr option SHOULD be included, > if lladdr is known > RA: medium w/o lladdr: not needed (can't attach) > medium with lladdr: router MAY attach source lladdr option, > MAY omit it for load balancing > NS: medium w/o lladdr: not needed (can't attach) > medium with lladdr: > source lladdr option MUST be attached for multicast > solicitation, SHOULD be attached for > unicast solicitation > redirect: > medium w/o lladdr: not needed (can't attach) > medium with lladdr: > target lladdr option SHOULD be included if known. > (ATM) MUST be included on some medium. > > As seen in the above list, it is not rare to see RS/RA/NS/redirect > packet, WITHOUT source/target lladdr option. > > However, the following sections in discovery-v2-03 assume > that source/target > lladdr is attached to ND packet: > 6.2.6(RS) > 6.3.4(RA) > 7.2.3(NS) > 8.3(redirect) > appendix C, second state transition chart (p87 to p88) must be > clarified for the following 3 cases: > medium without lladdr > medium with lladdr, packet with lladdr > medium with lladdr, packet without lladdr > This should be fixed. Also, 6.2.6, 6.3.4, 7.2.3 and 8.3 has almost > the same textual description for neighbor cache updates. I believe > these duplicates should be merged into one section somewhere. > > It is not very trivial to clarify. Choices might be: > 1. do not make neighbor cache if there's no lladdr, or > 2. make neighbor cache with some state. > However, these ways do not work very well. > > > 1. If you do not make neighbor cache entry: > You cannot record IsRouter flag, and you will have chances for > stale entry on default router list. > For example, the following list of event will create a > stale entry: > router X transmits RA without lladdr. > Host Y will install default router list > entry for X. > No neighbor cache entry created. > router X becomes host. > host X (previously router X) transmits NS with lladr. > Default router list entry for X remains > on the host Y. > Neighbor cache entry will be created, > with IsRouter 0, > based on NS processing rule. > Now, you got a problem. If you try to send a packet to off-link > destination, you will be sending packet to host X. > > If host Y ignores "RA without lladdr", there will be no > stale default > router list entry. However, in this case, router X can > never achieve > load balancing among the routers by sending "RA without lladdr" > from routers. > > The source of the problem is recaped in the second question, > "neighbor cache entry and default router list". See the last > part of the email. > > What should on medium without lladdr? It is still > unclear for us. > > 2a. If you make neighbor cache entry with INCOMPLETE state: > INCOMPLETE state does not really fit this situation. > INCOMPLETE is > defined as: > Address resolution is in progress and the link-layer > address of the neighbor has not yet been determined. > However, we have never performed address resolution for > this entry. > > It is not good to require address resolution for every > "RA without > lladdr". > > 2b. If you make neighbor cache entry with some state other > than INCOMPLETE > If there is an entry with non-INCOMLETE state, it is assumed > that the entry once has lladdr for the target in the past. > Therefore, it is not very suitable for this situation. > If you set the state to STALE you have a big problem > --- DELAY state > will defer your future address resolution. > > > Here are solutions we came up with. > Solution 1: (from jinmei@kame.net) > If a node receives ND packet without lladdr, do not > make neighbor > cache. > > If node is about to send a pacet to off-link > destination, and router X > is chosen from default router list, and there is no > neighbor cache > entry for router X, node should perform the following. > - make neighbor cache entry > - set it INCOMPLETE > - set IsRouter bit for the entry > - perform neighbor discovery > - transmit packet if ND completed > > /* > * new entry: neighbor cache entrys is created > * olladdr: neighbor cache entry got old lladdr > * lladdr: packet contains lladdr option > * llchange: olladdr != lladdr > * > * newentry olladdr lladdr llchange (*=record lladdr) > * 0 n n -- (1) > * 0 y n -- (2) > * 0 n y -- (3) * set state to STALE > * 0 y y n (4) * > * 0 y y y (5) * set state to STALE > * 1 -- n -- (6) (don't > create entry) > * 1 -- y -- (7) * set state to STALE > */ > > Solution 2: (from itojun@kame.net) > Define a new neighbor cache state, PASSIVE. PASSIVE > entry will be > made when a node received ND packets without lladdr. > If a node received RA/RS/NS/redirect without lladdr option, > 1. create neighbor cache entry, > 2. make it PASSIVE state, and > 3. set IsRouter flag properly. > You MUST NOT remove neighbor cache entry for node A, if > node A is > listed in default router list. > > The above rule still works if there's no lladdr defined > for the medium. > > /* > * new entry: neighbor cache entrys is created > * olladdr: neighbor cache entry got old lladdr > * lladdr: packet contains lladdr option > * llchange: olladdr != lladdr > * > * newentry olladdr lladdr llchange (*=record lladdr) > * 0 n n -- (1) > * 0 y n -- (2) > * 0 n y -- (3) * set state to STALE > * 0 y y n (4) * > * 0 y y y (5) * set state to STALE > * 1 -- n -- (6) set state > to PASSIVE > * 1 -- y -- (7) * set state to STALE > */ > /* > * ICMP6 type dependent behavior. > * > * NS: clear IsRouter if new entry > * RS: clear IsRouter > * RA: set IsRouter if there's lladdr > * redir: clear IsRouter if new entry > * > * newentry olladdr lladdr llchange NS RS RA redir > * 0 n n -- (1) c s? > * 0 y n -- (2) c s > * 0 n y -- (3) c s > * 0 y y n (4) c s > * 0 y y y (5) c s > * 1 -- n -- (6) c c s? c > * 1 -- y -- (7) c c s c > * > * (c=clear s=set) > */ > > Clarification 1: > To make implementations easy, rules for source/target > lladdr option > for ND packets should be: > - on medium with lladdr: MUST attach one > - on medium w/o lladdr: not needed (and cannot attach) > > > 2. neighbor cache entry and default router list > =============================================== > Rules for IsRouter bit is "edge trigger" in nature. > Therefore, IsRouter > rule works only if the following statement is satisfied: > > For a node that is listed onto default router list, > there always be a neighbor cache entry. > > This must be clearly stated somewhere in document. (What > happens on medium > ithout lladdr?? We still need to make neighbor cache entry just for > IsRouter bit) > > IsRouter bit must be revisited, really. > -------------------------------------------------------------------- > 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 Thu Nov 5 13:33:09 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA16960 for ipng-dist; Thu, 5 Nov 1998 13:29:07 -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 NAA16953 for ; Thu, 5 Nov 1998 13:28:58 -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 NAA02289 for ; Thu, 5 Nov 1998 13:28:55 -0800 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 NAA02971 for ; Thu, 5 Nov 1998 13:28:54 -0800 (PST) Received: from flume.zk3.dec.com (yflume.zk3.dec.com [16.140.16.14]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0a) with SMTP id QAA05375; Thu, 5 Nov 1998 16:28:50 -0500 (EST) Received: from brywasted.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA17045; Thu, 5 Nov 1998 16:28:48 -0500 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id QAA0000027813; Thu, 5 Nov 1998 16:28:48 -0500 (EST) From: Jim Bound Message-Id: <199811052128.QAA0000027813@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Chris Harding Cc: ipng@sunroof.eng.sun.com, xnet@opengroup.org, bound@zk3.dec.com Subject: (IPng 6703) Re: Namespace Pollution and the IPv6 Basic API In-Reply-To: Your message of "Thu, 05 Nov 1998 17:16:13 GMT." <3.0.3.32.19981105171613.007d7100@mailhome.rdg.opengroup.org> Date: Thu, 05 Nov 1998 16:28:48 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Chris, >First, regarding the Feature Test Macros. These comments are largely a >matter of preciseness of language. The Basic API as per the draft is >unlikely to break existing applications. But you can't _guarantee_ this >without Feature Test Macros, or some equivalent mechanism. So I suggested >that they be mentioned - but not specified - in the basic API. It won't >necessarily hurt if they are not mentioned because this is the sort of >thing that can be added in a formal standard without overly disturbing >implementations or applications, and perhaps a formal standard is the >appropriate place to do this. We believe we will not break existing apps. Mentioning 1003.1 is OK. But that is not what was proposed. Let me suggest to you some alternate wording in another thread later. >For clarification, the specific reference I was suggesting be included in >the Basic API is to IEEE Standard 1003.1 - the main POSIX Standard that >covers fork(), exec(), open(), close(), wait(), and about a thousand other >well-known operating system primitives - rather than to P1003.1g which is >the draft extension to it for networking services. I also listed the >namespace reservations made by P1003.1g, but purely as background to the >proposed name changes. As one whose name is on 1003.1 from many years ago I understand fully the jist of 1003.1. My issue is that a non-Host normal stack may be used for IP, and even the most basic 1003.1 forms may not exist like exec/fork paradigm. >Actually, I care a lot more about the proposed name changes than about the >Feature Test Macros, because they will make the API easier to use. If IPv6 >and the Basic API to it are successful, there will be many more programmers >using the API than implementing it. And while an implementor may spend >several working years on what goes behind the API, and know every wrinkle, >the main concerns of the user are typically elsewhere. A user will want to >spend as little time as possible understanding a service API, and API >designers will do well to make things easy for users. There are cases where >the complexity of protocol APIs have inhibited their take-up and have >inhibited use of the protocols. I for one understand that and your intentions. >But I would not advocate, and I don't think that any of the present members >of XNET would advocate, changing the names after they have been agreed in >the IETF. I (and I think they) fully agree with Jim and Tim that this would >not be the right road to go down. It would confuse matters at what will be >a crucial time for deployment of IPv6. That is why I make the proposal, in >the IETF forum, at this time. I do so in the belief that the ipng is the >body responsible for the design of the Basic API, and will accept the >implications of that responsibility. These include giving thought to >usability of the API, and to compatibility with related standards produced >by the wider API community. I agree with that too and I would claim we did give thought to that too. But I will respond more after your last paragraph. >Finally, in view of Jim's most recent mail, I have a question for the IETF. >I have been to several IETF meetings now, and attended working group >meetings that filled their rooms and overflowed into the corridors, but at >which fewer people spoke than normally do at meetings of XNET, which as Jim >points out are much more sparsely attended. I have then been to Plenary >sessions at which someone complains about this situation and stresses the >need for wider input. So I have to ask, is the IETF an open forum in which >comments made by anyone will be given due consideration, provided they are >made in due form, or is there a closed circle of the "chosen few" who >welcome outside participation only when it gives them rubber stamp approval? Of course the IETF welcomes all participation of a technical nature which the proposed name space clearly is for this discussion. But we also face that this API has been in process for a long time so any changes have to be deemed as pretty important to be done and accepted at this point in time. I think the changes you propose are essentially cosmetic and don't add any new value to warrant all the implementors changing their implementations. That was my individual input. Now we need to hear from others so give it a chance. We have until next Wednesday to decide (11/11). I clearly stated that if the WG wants this proposed change I will start editing the document. So the process is working for you. Yes I am a formiddable person who does not support your view and I have that right and am voicing it. But I always go with WG consensus and have many times, when I disagreed with it. What you have to accept is your proposal may be rejected not just by me but by this process. If that happens it does not mean we did not listen or even we think it is a bad idea. Had you provided your excellent proposal awhile ago long before running code existed I think it would have been accepted. Now your proposal is up against a lot of running code and most likely being integrated into product level base line releases. The question now is adding your suggested change important enough to take a hit in time to make the change. I think it is not. But the forum is open to tell me I am wrong, or your idea is very important to incorporate. I have had one very strong implementor and proponent of IPv6 send me private mail that this change is unacceptable fyi. There is no closed chosen few for this particular event. I will not speak or answer for all the IETF as I can't. But this API has been completely open. But, running code has a place in this standards body that it really doesn't quite have in other standards body. Running code has a status almost like its own veto power in some cases. To avoid that veto power ideas have to pretty good and needed. Running code means we need to listen to the implementors as a group of people. So they are a faction for the lack of better words right now. Yes that faction has some weight for any of us in the IETF. In this case I sit in that faction. In other cases in the IETF I am not in that faction but am very glad they are there across the board usually in this community. So yes your input is up against that faction and the fact that IPv6 deployment is in process and your change will affect time to market and costs of IPv6 development for the API. At the plenary this next IETF 43 I have a new issue and it is happening here and elsewhere in the IETF. That is input that is too late and then holds up the processes. We have to have a penalty or somethign for input that is too late. There is absolutely no reason why your input could not have come right after 2133 started to be rechecked earlier this year in the spring of 1998 at the L.A. meeting. All the way back at draft-01-new version. ipv6mr, sin6, etc have been around long before RFC 2133 let alone the 3 drafts prior to the present 03 draft. That is the problem you face now, not that the IETF is not fair or operates in a closed system, but that your very very late with this input for this API. 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 Nov 6 08:20:10 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA17892 for ipng-dist; Fri, 6 Nov 1998 08:17:24 -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 IAA17885 for ; Fri, 6 Nov 1998 08:17:15 -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 IAA16335 for ; Fri, 6 Nov 1998 08:17:13 -0800 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 IAA27198 for ; Fri, 6 Nov 1998 08:17:13 -0800 (PST) Received: by mailgate.rdg.opengroup.org; id AA17921; Fri, 6 Nov 1998 16:15:15 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 ; Fri Nov 06 16:15 GMT 1998 Message-Id: <3.0.3.32.19981106160519.007da7f0@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 06 Nov 1998 16:05:19 +0000 To: Jim Bound From: Chris Harding Subject: (IPng 6706) Re: Namespace Pollution and the IPv6 Basic API Cc: ipng@sunroof.eng.sun.com, xnet@opengroup.org In-Reply-To: <199811052128.QAA0000027813@wasted.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Jim, Thanks for your reply. All that I am asking is that my comment be considered on its merits. Of course I don't expect it to be accepted just because XNET asked me to make it. I hope it will be accepted because it makes good sense. That's how it looks to me, but if the consensus is otherwise, so be it. As to the timing, I do take your point that it would have been better to make this comment earlier (I did in fact make a similar one some time ago on the draft Advanced API). But - perhaps I am misunderstanding the process - I thought that "last call" defined the point after which a comment would be too late. Perhaps this is something that rightly should be raised in plenary, so that a proper understanding can be established if there is in fact an earlier cut-off point. I hope that we now understand each other. For my part, I will now leave the discussion up to other members of the group (unless someone raises a technical point on the comment that I need to elucidate). >Chris, > >>First, regarding the Feature Test Macros. These comments are largely a >>matter of preciseness of language. The Basic API as per the draft is >>unlikely to break existing applications. But you can't _guarantee_ this >>without Feature Test Macros, or some equivalent mechanism. So I suggested >>that they be mentioned - but not specified - in the basic API. It won't >>necessarily hurt if they are not mentioned because this is the sort of >>thing that can be added in a formal standard without overly disturbing >>implementations or applications, and perhaps a formal standard is the >>appropriate place to do this. > >We believe we will not break existing apps. Mentioning 1003.1 is OK. >But that is not what was proposed. Let me suggest to you some alternate >wording in another thread later. > >>For clarification, the specific reference I was suggesting be included in >>the Basic API is to IEEE Standard 1003.1 - the main POSIX Standard that >>covers fork(), exec(), open(), close(), wait(), and about a thousand other >>well-known operating system primitives - rather than to P1003.1g which is >>the draft extension to it for networking services. I also listed the >>namespace reservations made by P1003.1g, but purely as background to the >>proposed name changes. > >As one whose name is on 1003.1 from many years ago I understand fully >the jist of 1003.1. My issue is that a non-Host normal stack may be used >for IP, and even the most basic 1003.1 forms may not exist >like exec/fork paradigm. > >>Actually, I care a lot more about the proposed name changes than about the >>Feature Test Macros, because they will make the API easier to use. If IPv6 >>and the Basic API to it are successful, there will be many more programmers >>using the API than implementing it. And while an implementor may spend >>several working years on what goes behind the API, and know every wrinkle, >>the main concerns of the user are typically elsewhere. A user will want to >>spend as little time as possible understanding a service API, and API >>designers will do well to make things easy for users. There are cases where >>the complexity of protocol APIs have inhibited their take-up and have >>inhibited use of the protocols. > >I for one understand that and your intentions. > >>But I would not advocate, and I don't think that any of the present members >>of XNET would advocate, changing the names after they have been agreed in >>the IETF. I (and I think they) fully agree with Jim and Tim that this would >>not be the right road to go down. It would confuse matters at what will be >>a crucial time for deployment of IPv6. That is why I make the proposal, in >>the IETF forum, at this time. I do so in the belief that the ipng is the >>body responsible for the design of the Basic API, and will accept the >>implications of that responsibility. These include giving thought to >>usability of the API, and to compatibility with related standards produced >>by the wider API community. > >I agree with that too and I would claim we did give thought to that too. >But I will respond more after your last paragraph. > >>Finally, in view of Jim's most recent mail, I have a question for the IETF. >>I have been to several IETF meetings now, and attended working group >>meetings that filled their rooms and overflowed into the corridors, but at >>which fewer people spoke than normally do at meetings of XNET, which as Jim >>points out are much more sparsely attended. I have then been to Plenary >>sessions at which someone complains about this situation and stresses the >>need for wider input. So I have to ask, is the IETF an open forum in which >>comments made by anyone will be given due consideration, provided they are >>made in due form, or is there a closed circle of the "chosen few" who >>welcome outside participation only when it gives them rubber stamp approval? > >Of course the IETF welcomes all participation of a technical nature >which the proposed name space clearly is for this discussion. But we >also face that this API has been in process for a long time so any >changes have to be deemed as pretty important to be done and accepted at >this point in time. I think the changes you propose are essentially >cosmetic and don't add any new value to warrant all the implementors >changing their implementations. That was my individual input. Now we >need to hear from others so give it a chance. We have until next >Wednesday to decide (11/11). I clearly stated that if the WG wants this >proposed change I will start editing the document. So the process is >working for you. Yes I am a formiddable person who does not support >your view and I have that right and am voicing it. But I always go with >WG consensus and have many times, when I disagreed with it. > >What you have to accept is your proposal may be rejected not just by me >but by this process. If that happens it does not mean we did not listen >or even we think it is a bad idea. > >Had you provided your excellent proposal awhile ago long before running >code existed I think it would have been accepted. Now your proposal is >up against a lot of running code and most likely being integrated into >product level base line releases. The question now is adding your >suggested change important enough to take a hit in time to make the >change. I think it is not. But the forum is open to tell me I am >wrong, or your idea is very important to incorporate. > >I have had one very strong implementor and proponent of IPv6 send me >private mail that this change is unacceptable fyi. > >There is no closed chosen few for this particular event. I will not >speak or answer for all the IETF as I can't. But this API has >been completely open. But, running code has a place in this standards >body that it really doesn't quite have in other standards body. Running >code has a status almost like its own veto power in some cases. To >avoid that veto power ideas have to pretty good and needed. Running >code means we need to listen to the implementors as a group of people. >So they are a faction for the lack of better words right now. Yes that >faction has some weight for any of us in the IETF. In this case I sit >in that faction. In other cases in the IETF I am not in that faction >but am very glad they are there across the board usually in this >community. So yes your input is up against that faction and the fact >that IPv6 deployment is in process and your change will affect time to >market and costs of IPv6 development for the API. > >At the plenary this next IETF 43 I have a new issue and it is happening >here and elsewhere in the IETF. That is input that is too late and then >holds up the processes. We have to have a penalty or somethign for >input that is too late. There is absolutely no reason why your input >could not have come right after 2133 started to be rechecked earlier >this year in the spring of 1998 at the L.A. meeting. All the way back >at draft-01-new version. ipv6mr, sin6, etc have been around long before >RFC 2133 let alone the 3 drafts prior to the present 03 draft. That is >the problem you face now, not that the IETF is not fair or operates in a >closed system, but that your very very late with this input for this >API. > >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 >-------------------------------------------------------------------- > > 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 Fri Nov 6 08:58:48 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA17992 for ipng-dist; Fri, 6 Nov 1998 08:54:46 -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 IAA17985 for ; Fri, 6 Nov 1998 08:54:33 -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 IAA29414 for ; Fri, 6 Nov 1998 08:54:32 -0800 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 IAA23866 for ; Fri, 6 Nov 1998 08:54:30 -0800 (PST) Received: from flume.zk3.dec.com (flume.zk3.dec.com [16.140.112.3]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0a) with SMTP id LAA30735; Fri, 6 Nov 1998 11:53:37 -0500 (EST) Received: from brywasted.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA07403; Fri, 6 Nov 1998 11:53:32 -0500 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id LAA0000021742; Fri, 6 Nov 1998 11:53:32 -0500 (EST) From: Jim Bound Message-Id: <199811061653.LAA0000021742@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Chris Harding Cc: ipng@sunroof.eng.sun.com, xnet@opengroup.org Subject: (IPng 6707) Re: Namespace Pollution and the IPv6 Basic API In-Reply-To: Your message of "Fri, 06 Nov 1998 16:05:19 GMT." <3.0.3.32.19981106160519.007da7f0@mailhome.rdg.opengroup.org> Date: Fri, 06 Nov 1998 11:53:32 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Chris, Thanks for the mail. I am out of it too. For what it is worth the proprosal is sound and a good piece of work. I can't get past the shipping of the IPv6 API though. I feel bad about it but I have to do this often in my job too. Not fun for sure. thanks again for your hard work on this effort, lets see what folks say. /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 Nov 6 12:12:50 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA18338 for ipng-dist; Fri, 6 Nov 1998 12:02:55 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id MAA18331 for ; Fri, 6 Nov 1998 12:02:43 -0800 (PST) Received: from strat (strat [129.146.85.177]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id MAA15483; Fri, 6 Nov 1998 12:02:42 -0800 (PST) Message-Id: <199811062002.MAA15483@jurassic.eng.sun.com> Date: Fri, 6 Nov 1998 12:01:26 -0800 (PST) From: Sebastien Roy Reply-To: Sebastien Roy Subject: (IPng 6708) Cthon 99 Registration Open To: ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au Cc: audrey@vanb.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: nGDIpQoz+org5RWWMDLGDg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPv6 implementors, Plans for Connectathon 99 are already under way! The 13th annual Connectathon event, an interoperability testing event for engineers only, will be held March 4-11, 1999, in San Jose, California. Connectathon, sponsored by Sun Microsystems, Inc., hosts over 40 companies annually in an effort to test and debug source code which utilize the following technologies and protocols: NFS versions 2, 3 and 4 NFS over TCP WebNFS Lock Manager NIS/NIS+/DNS TI-RPC Kerberos Automounter IPv6 IPsec DHCP Network Computers LDAP Service Location Protocol Gigabit Ethernet Y2K Compatibility Based on demand, in addition we are considering to offer: Fiber Channel Attached Loop ATM If you are interested in testing FCAL or ATM, please send a note to Cthon@Sun.COM and we'll gauge interest. Or if you have a suggestion for another technology, feel free to contact us as well. Testing continues 24 hours per day. Technology testing coordinators will organize testing procedures and test suite material. In addition, there will be seminars with speakers addressing various topics. The registration deadline is February 14, 1999. An Early Bird Discount on booth fees is available to those who register and pay by December 18, 1998. For registration information, please see our web site at http://www.connectathon.org. If you have any questions, please feel free to contact Audrey Van Belleghem at audrey@vanb.com or (408) 358-9598. We look forward to seeing you at the 13th annual Connectathon event! Audrey Van Belleghem Connectathon Manager -------------------------------------------------------------------- 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 Nov 8 08:01:12 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA19712 for ipng-dist; Sun, 8 Nov 1998 07:58:09 -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 HAA19705 for ; Sun, 8 Nov 1998 07:58:01 -0800 (PST) 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 HAA16763 for ; Sun, 8 Nov 1998 07:58:00 -0800 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 HAA00684 for ; Sun, 8 Nov 1998 07:58:00 -0800 (PST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0a) with SMTP id KAA20176 for ; Sun, 8 Nov 1998 10:57:59 -0500 (EST) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA32473; Sun, 8 Nov 1998 10:57:59 -0500 Message-Id: <199811081557.AA32473@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: (IPng 6712) DEAD CODE in Addrconf DOS Algortim Prevention Date: Sun, 08 Nov 1998 10:57:59 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, We need to fix this and I propose a fix below. I don't know if folks have put this in their addrconf code but I just got around to it and found a problem. Here is the algorithm for DOS at present in addrconf 5.5.3. draft-ietf-ipngwg-addrconf-v2-02.txt 1) If the received Lifetime is greater than 2 hours or greater | than StoredLifetime, update the stored Lifetime of the | corresponding address. | 2) If the StoredLifetime is less than or equal to 2 hours and the | received Lifetime is less than or equal to StoredLifetime, | ignore the prefix, unless the Router Advertisement from which | this Prefix Information option was obtained has been | authenticated (e.g., via IPSec [RFC1826]). If the Router | Advertisment was authenticated, the StoredLifetime should be | set to the Lifetime in the received option. | 3) Otherwise, reset the stored Lifetime in the corresponding | address to two hours. | Here is the scenario: Lets say Valid Lifetime from last Rtr Advertisement was 3600 (seconds) StoredLifetime = 1700 (Note seconds and less than two hours) This really represents the time remaining on the Valid Lifetime since the last Router Advertisement was received. I address that this algorithm needs a wordsmith fix too below. Rtr Adv: Valid Life = 1750 Part 1) above will permit updating the valid liftime because the second OR conditon will execute. ergo 1750 > 1700. Because the first OR condition will fail. ergo 1750 > 2HOURS, which will be FALSE. In this case Valid Lifetime will become 1750, Part 2) and Part 3) will not execute. But lets take another Rtr Adv with same Stored Life as above: Valid Lifetime = 1680 Part 1) will fail for both OR conditions and execute the second test Part 2): StoredLife <= 2HOURS && Recvd Valid Life <= Storedlife 1700 7200 1680 1700 In this case we just ignore the prefx per Part 2) unless IPsec = TRUE. In the algorithm Part 2) the second test can never be not true because if it was it would always be caught in Part 1), thus, making Part 3) DEAD CODE and not needed in the algorithm. If Stored Life was 1701....++++ Part 1) would update the Valid Lifetime and in Part 2) if Stored Life was -----........1700 the prefix would be ingored. The second part of the AND condition in Part 2) is the same test as the second OR condition in Part 1) in essence. Part 1) second OR condition: Rcvd Valid Lifetime > Stored Lifetime 1680 1700 NOW GO TO Part 2) as this FAILS: Part 2) second AND condition: Rcvd Valid Lifetime <= Stored Lifetime 1680 1700 This is true and PASSES so ignore the prefix. There is no case where Part 3) can happen and is dead code for that final else condition if you wrote the code with an if-else construct. In addition Part 2) is really not needed in the algorithm, and the prefix can be ignored in Part 1). The algorithm should be changed as follows: 1) If the received Valid Lifetime is greater than 2 hours or greater than Stored Lifetime, update the Valid Lifetime of the corresponding address, else ignore the prefix, unless the Router Advertisement from which this Prefix Information option was obtained has been authenticated (e.g., via IPSec [RFC1826]). If the Router Advertisment was authenticated, the Valid Lifetime should be set to the Valid Lifetime in the received option. Also note there is an error in the wording of the algorithm at present if the Rtr Adv was authenticated. And in Part 3) at present. We cannot set the Stored Lifetime as that is really the remaining time (ticks) for the Valid Lifetime, what has to be set is the Valid Lifetime and what implementations will have to do is take a new timestamp when a new Valid Life time is accepted. Likewise in Part 1) you cannot update the StoredLifetime but the Valid Lifetime. But this also permits implementations that are running a continuous decrement of the Valid Lifetime in a Realtime implementation (Embedded System, or Toaster using IPv6) to treat the Stored Lifetime and Valid Lifetime in this spec as synonomous semantically. This is much simpler, removes dead code, and does not change the result of the algorithm, intended by the ipng working group. We also should define StoredLifetime as follows: StoredLifetime - The StoredLifetime is the time remaining for the Valid Lifetime since it was received by a Router Advertisement. The result of this algorithm remains that a Router cannot send a Valid Lifetime that is less than the remaining lifetime for the Valid Lifetime of the Host processing ND Addrconf Router Advertisements. Which is what the present algorithm does but makes the wording so folks don't write all this dead and uneeded code from the spec. It also makes the spec clearer, hence, implementation easier and less costly. I consider this an editorial fix to addrconf and wordsmithing to make it more clear. /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 Nov 9 11:10:07 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA20699 for ipng-dist; Mon, 9 Nov 1998 10:58:13 -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 KAA20692 for ; Mon, 9 Nov 1998 10:58:05 -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 KAA19500 for ; Mon, 9 Nov 1998 10:57:17 -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 KAA09625 for ; Mon, 9 Nov 1998 10:35:05 -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 KAA10978; Mon, 9 Nov 1998 10:33:18 -0800 (PST) Message-Id: <3.0.5.32.19981109103014.00a1f620@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 09 Nov 1998 10:30:14 -0800 To: narten@raleigh.ibm.com, Jeffrey Burgan From: Bob Hinden Subject: (IPng 6713) Request to Advance "Reserved IPv6 Subnet Anycast Addresses" 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 : 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 A working group last call for this document was completed on November 3, 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 Tue Nov 10 06:19:35 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA22664 for ipng-dist; Tue, 10 Nov 1998 06:16:21 -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 GAA22657 for ; Tue, 10 Nov 1998 06:16:13 -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 GAA07733 for ; Tue, 10 Nov 1998 06:16:10 -0800 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 GAA03408 for ; Tue, 10 Nov 1998 06:16:07 -0800 (PST) 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 XAA26998 for ; Tue, 10 Nov 1998 23:16:05 +0900 (JST) To: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 6715) IPv6 numeric address in URL Date: Tue, 10 Nov 1998 23:16:04 +0900 Message-ID: <26994.910707364@coconut.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm very sorry about dumb question, what was the consensus on embedding IPv6 numeric address into URL? Pointer (name of draft) would be helpful. I checked the email archive and found no clear result. I remember several candidates but have no reference to i-d: http://[3ffe:0501::1]/foo.html http://3ffe-0501--1.ipv6/foo.html Thanks, jun-ichiro itojun itoh itojun@itojun.org -------------------------------------------------------------------- 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 Nov 10 08:24:25 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA22760 for ipng-dist; Tue, 10 Nov 1998 08:21:09 -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 IAA22753 for ; Tue, 10 Nov 1998 08:21:00 -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 IAA29493 for ; Tue, 10 Nov 1998 08:20:58 -0800 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 IAA10573 for ; Tue, 10 Nov 1998 08:20:49 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id QA29574; Wed, 11 Nov 1998 03:20:35 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Jun-ichiro itojun Itoh Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6716) Re: IPv6 numeric address in URL In-Reply-To: Your message of "Tue, 10 Nov 1998 23:16:04 +0900." <26994.910707364@coconut.itojun.org> Date: Wed, 11 Nov 1998 03:20:34 +1100 Message-Id: <28095.910714834@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 10 Nov 1998 23:16:04 +0900 From: Jun-ichiro itojun Itoh Message-ID: <26994.910707364@coconut.itojun.org> | I'm very sorry about dumb question, what was the consensus on | embedding IPv6 numeric address into URL? I don't think there has been one, yet. 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 Tue Nov 10 09:43:26 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA22880 for ipng-dist; Tue, 10 Nov 1998 09:36:09 -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 JAA22873 for ; Tue, 10 Nov 1998 09:35:56 -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 JAA21405 for ; Tue, 10 Nov 1998 09:35:53 -0800 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 JAA00780 for ; Tue, 10 Nov 1998 09:35:51 -0800 (PST) Received: by INET-IMC-05 with Internet Mail Service (5.5.2232.9) id ; Tue, 10 Nov 1998 09:35:49 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81664@RED-MSG-50> From: Richard Draves To: "'bound@zk3.dec.com'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6717) RE: DEAD CODE in Addrconf DOS Algortim Prevention Date: Tue, 10 Nov 1998 09:35:47 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 1) If the received Lifetime is greater than 2 hours or greater | than StoredLifetime, update the stored Lifetime of the | corresponding address. | 2) If the StoredLifetime is less than or equal to 2 hours and the | received Lifetime is less than or equal to StoredLifetime, | ignore the prefix, unless the Router Advertisement from which | this Prefix Information option was obtained has been | authenticated (e.g., via IPSec [RFC1826]). If the Router | Advertisment was authenticated, the StoredLifetime should be | set to the Lifetime in the received option. | 3) Otherwise, reset the stored Lifetime in the corresponding | address to two hours. | When I implemented this, I translated this directly into code. The only change was in part 2 - the clause "and the received Lifetime is less than or equal to StoredLifetime" is redundant (always true by the time you get there because part 1 checks for that condition). I don't see any other redundancy. I found this specification to be clear and easy to implement. Part 3 will execute (for example) if the stored lifetime is 3 hours and the received lifetime is 1 hour. Then part 3 says to set the stored lifetime to 2 hours. I perform this processing independently for both the valid & preferred lifetimes. (I convinced myself that if my address's stored lifetimes already satisfied the invariant that preferred lifetime <= valid lifetime, and the received lifetimes satisfy that condition, then after the above processing the invariant would still hold.) 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 Tue Nov 10 09:56:01 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA22908 for ipng-dist; Tue, 10 Nov 1998 09:50:13 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA22901 for ; Tue, 10 Nov 1998 09:50:02 -0800 (PST) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id JAA07410; Tue, 10 Nov 1998 09:49:48 -0800 (PST) Date: Tue, 10 Nov 1998 09:49:52 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6718) Site prefixes? To: ipng@sunroof.eng.sun.com Cc: nordmark@jurassic.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In the lull after the last IETF I submitted this draft: Site Prefixes in Neighbor Discovery This is supposed to be controversial stuff - yet I've seen no comments on the mailing list (yet)! The idea is to store site-local addresses in the global DNS and using information advertized in Router Advertisements to determine if the site-local addresses should be ignored or preferred over the global addresses. So please read the draft and comment. Hopefully we can then make progress on this on the mailing list. If there aren't any comments I'll have to ask the chairs to do a WG last call. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 10 15:08:35 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA23647 for ipng-dist; Tue, 10 Nov 1998 15:04:44 -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 PAA23640 for ; Tue, 10 Nov 1998 15:04:32 -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 PAA23840 for ; Tue, 10 Nov 1998 15:04:30 -0800 Received: from onoe2.sm.sony.co.jp (onoe2.sm.sony.co.jp [133.138.10.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA09890 for ; Tue, 10 Nov 1998 15:04:30 -0800 (PST) Received: from duplo.sm.sony.co.jp (onoe@localhost) by onoe2.sm.sony.co.jp (8.9.0/3.7W) with ESMTP id IAA07312 for ; Wed, 11 Nov 1998 08:04:27 +0900 (JST) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.8.8/8.8.8) id IAA02913; Wed, 11 Nov 1998 08:03:25 +0900 (JST) Date: Wed, 11 Nov 1998 08:03:25 +0900 (JST) From: Atsushi Onoe Message-Id: <199811102303.IAA02913@duplo.sm.sony.co.jp> To: ipng@sunroof.eng.sun.com Subject: (IPng 6719) Re: IPv6 numeric address in URL In-Reply-To: Your message of "Tue, 10 Nov 1998 23:16:04 +0900" <26994.910707364@coconut.itojun.org> References: <26994.910707364@coconut.itojun.org> X-Mailer: Cue version 0.2 (981014-1301/onoe) 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 remember several candidates but have no reference to i-d: > http://[3ffe:0501::1]/foo.html > http://3ffe-0501--1.ipv6/foo.html The latter is used in draft-ietf-svrloc-ipv6-05.txt for service: scheme, which is in IETF last call period. Atsushi -------------------------------------------------------------------- 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 Nov 10 18:47:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id SAA24079 for ipng-dist; Tue, 10 Nov 1998 18:41:24 -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 SAA24072 for ; Tue, 10 Nov 1998 18:41:15 -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 SAA28979; Tue, 10 Nov 1998 18:41:13 -0800 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 SAA09060; Tue, 10 Nov 1998 18:41:14 -0800 (PST) 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 LAA05442; Wed, 11 Nov 1998 11:41:11 +0900 (JST) To: Erik Nordmark cc: ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Tue, 10 Nov 1998 09:49:52 PST. 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 6720) Re: Site prefixes? Date: Wed, 11 Nov 1998 11:41:11 +0900 Message-ID: <5438.910752071@coconut.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >This is supposed to be controversial stuff - yet I've seen >no comments on the mailing list (yet)! > >The idea is to store site-local addresses in the global DNS and using >information advertized in Router Advertisements to determine if >the site-local addresses should be ignored or preferred over the >global addresses. > >So please read the draft and comment. Hopefully we can then make progress >on this on the mailing list. >If there aren't any comments I'll have to ask the chairs to do a WG last call. From the abstract: >> This protocol requires that all IPv6 implementations, even those that >> do not implement this protocol, ignore all site-local addresses that >> they retrieve from the DNS. I believe this requirement expects too much to existing IPv6 implementation... (how many new MUST requirements will be added to IPv6 implementations? there should be "router requirement" and "host rqeuirement" document...) Use of site-local address is local matter to a site, and should not bother outsiders. Requiring two-faced DNS to a site that uses site-local address is much easier to implement. If two-faced DNS is a common practice, someone may implement a tool that makes it easier to deploy. (example: bind8 is much useful than bind4 for firewall border) itojun -------------------------------------------------------------------- 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 Nov 10 21:58:56 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id VAA24208 for ipng-dist; Tue, 10 Nov 1998 21:51:03 -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 VAA24201 for ; Tue, 10 Nov 1998 21:50:54 -0800 (PST) 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 VAA27037 for ; Tue, 10 Nov 1998 21:50:53 -0800 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 VAA19292 for ; Tue, 10 Nov 1998 21:50:54 -0800 (PST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0a) with SMTP id AAA29926; Wed, 11 Nov 1998 00:50:53 -0500 (EST) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA07717; Wed, 11 Nov 1998 00:50:52 -0500 Message-Id: <199811110550.AA07717@quarry.zk3.dec.com> To: Richard Draves Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 6721) Re: DEAD CODE in Addrconf DOS Algortim Prevention In-Reply-To: Your message of "Tue, 10 Nov 1998 09:35:47 PST." <4D0A23B3F74DD111ACCD00805F31D8100AF81664@RED-MSG-50> Date: Wed, 11 Nov 1998 00:50:52 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, >When I implemented this, I translated this directly into code. The only >change was in part 2 - the clause "and the received Lifetime is less than or >equal to StoredLifetime" is redundant (always true by the time you get there >because part 1 checks for that condition). I don't see any other redundancy. >I found this specification to be clear and easy to implement. I did the same. But I found the algorithm too psuedo for a DOS issue of importance, and not specified in detail so that it would be acceptable to something like a POSIX 1003.1 conformance test suite. So I don't agree that it is clear. Each test is an assertion and I find the assertions vague. The terms are ill defined too for the assertions. >Part 3 will execute (for example) if the stored lifetime is 3 hours and the >received lifetime is 1 hour. Then part 3 says to set the stored lifetime to >2 hours. Good point. I just tested this. My unit tests for stored were all under 2 hours and why I did not set the 2hours. Code works though. The first AND condition will fail and the else will execute yes. >I perform this processing independently for both the valid & preferred >lifetimes. (I convinced myself that if my address's stored lifetimes already >satisfied the invariant that preferred lifetime <= valid lifetime, and the >received lifetimes satisfy that condition, then after the above processing >the invariant would still hold.) I only do it for valid. I do not recall any discussion for preferred for the algorithm or spec on the mail list. I think both of these should have been defined clearly and the definition of storedlifetime. We can just let this slide this is at Draft Standard now and we will all make it work, and prevent deletion of addresses with a valid lifetime of zero unless IPsec is set, which was the point of this algorithm. >From now on in the IETF if the author is not an implementor I will implement test code for all algorithms before a last call. My lesson learned here, and shame on me. 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 Nov 11 05:54:15 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA24461 for ipng-dist; Wed, 11 Nov 1998 05:50:17 -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 FAA24454 for ; Wed, 11 Nov 1998 05:50:06 -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 FAA13931 for ; Wed, 11 Nov 1998 05:50:03 -0800 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 FAA22260 for ; Wed, 11 Nov 1998 05:50:03 -0800 (PST) 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 NAA20292; Wed, 11 Nov 1998 13:50:01 GMT 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 NAA21522; Wed, 11 Nov 1998 13:50:00 GMT Message-ID: <364995DA.FC2B1FEF@hursley.ibm.com> Date: Wed, 11 Nov 1998 13:49:14 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Atsushi Onoe CC: ipng@sunroof.eng.sun.com Subject: (IPng 6723) Re: IPv6 numeric address in URL References: <26994.910707364@coconut.itojun.org> <199811102303.IAA02913@duplo.sm.sony.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If so, svrloc has a big problem as there is no consensus for this solution (especially not for the pseudo-domain). Brian Atsushi Onoe wrote: > > > I remember several candidates but have no reference to i-d: > > http://[3ffe:0501::1]/foo.html > > http://3ffe-0501--1.ipv6/foo.html > > The latter is used in draft-ietf-svrloc-ipv6-05.txt for service: scheme, > which is in IETF last call period. > > Atsushi > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 11 05:54:29 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA24445 for ipng-dist; Wed, 11 Nov 1998 05:48:10 -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 FAA24436 for ; Wed, 11 Nov 1998 05:47:52 -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 FAA13714 for ; Wed, 11 Nov 1998 05:47:44 -0800 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 FAA21247 for ; Wed, 11 Nov 1998 05:47:44 -0800 (PST) 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 NAA47164; Wed, 11 Nov 1998 13:47:41 GMT 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 NAA22058; Wed, 11 Nov 1998 13:47:36 GMT Message-ID: <3649954B.359096C3@hursley.ibm.com> Date: Wed, 11 Nov 1998 13:46:51 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Robert Elz CC: Jun-ichiro itojun Itoh , ipng@sunroof.eng.sun.com Subject: (IPng 6722) Re: IPv6 numeric address in URL References: <28095.910714834@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Correct. We don't have a solution. Brian Robert Elz wrote: > > Date: Tue, 10 Nov 1998 23:16:04 +0900 > From: Jun-ichiro itojun Itoh > Message-ID: <26994.910707364@coconut.itojun.org> > > | I'm very sorry about dumb question, what was the consensus on > | embedding IPv6 numeric address into URL? > > I don't think there has been one, yet. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 Nov 11 06:54:28 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA24674 for ipng-dist; Wed, 11 Nov 1998 06:49:40 -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 GAA24659 for ; Wed, 11 Nov 1998 06:49:27 -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 GAA21560 for ; Wed, 11 Nov 1998 06:49:24 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA19541 for ; Wed, 11 Nov 1998 06:49:24 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA01031; Wed, 11 Nov 1998 09:49:19 -0500 (EST) Message-Id: <199811111449.JAA01031@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 6724) I-D ACTION:draft-ietf-ipngwg-router-renum-06.txt Date: Wed, 11 Nov 1998 09:49:19 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart Note: This revision reflects comments received during the last call period. 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 : Router Renumbering for IPv6 Author(s) : M. Crawford Filename : draft-ietf-ipngwg-router-renum-06.txt Pages : 23 Date : 10-Nov-98 IPv6 Neighbor Discovery and Address Autoconfiguration conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes. This document defines a mechanism called Router Renumbering ('RR') which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site. 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-router-renum-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.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-router-renum-06.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: <19981110180633.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-router-renum-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-router-renum-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981110180633.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 Wed Nov 11 15:06:31 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA26156 for ipng-dist; Wed, 11 Nov 1998 15:01:57 -0800 (PST) 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 PAA26144 for ; Wed, 11 Nov 1998 15:01:44 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id PAA20432; Wed, 11 Nov 1998 15:01:34 -0800 (PST) Date: Wed, 11 Nov 1998 15:00:45 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6725) Re: Site prefixes? To: Jun-ichiro itojun Itoh Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <5438.910752071@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> This protocol requires that all IPv6 implementations, even those that > >> do not implement this protocol, ignore all site-local addresses that > >> they retrieve from the DNS. > > I believe this requirement expects too much to existing IPv6 > implementation... (how many new MUST requirements will be added to > IPv6 implementations? there should be "router requirement" > and "host rqeuirement" document...) Use of site-local address is > local matter to a site, and should not bother outsiders. I agree this is a new requirement which is why it is "flagged" in the abstract. It would be nice if the requirement wasn't needed but as far as I can tell that would require a two-faced DNS instead. > Requiring two-faced DNS to a site that uses site-local address is > much easier to implement. If two-faced DNS is a common practice, > someone may implement a tool that makes it easier to deploy. > (example: bind8 is much useful than bind4 for firewall border) Others have argued strongly against requiring a two-faced DNS for every site. True that they might not be too hard to administer for large sites (like large corporations) but I don't see small sites (like households) ever doing this. So how can we resolve this issue? Any good ideas out there? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 11 18:45:48 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id SAA26845 for ipng-dist; Wed, 11 Nov 1998 18:37:45 -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 SAA26838 for ; Wed, 11 Nov 1998 18:37:35 -0800 (PST) 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 SAA21062 for ; Wed, 11 Nov 1998 18:37:32 -0800 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 SAA00930 for ; Wed, 11 Nov 1998 18:37:34 -0800 (PST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0a) with SMTP id VAA09273; Wed, 11 Nov 1998 21:37:33 -0500 (EST) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA02523; Wed, 11 Nov 1998 21:37:32 -0500 Message-Id: <199811120237.AA02523@quarry.zk3.dec.com> To: hinden@ipsilon.com, deering@cisco.com Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 6726) Base API Last Call Edits Date: Wed, 11 Nov 1998 21:37:32 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob/Steve, Just submitted the 04 version of the API to the ID dirs. This should be put forth to replace RFC 2133 as an updated Informational RFC. The cut-off date for drafts before Orlando is Nov 18th so this is plenty of time to get draft 04 into the ID dir. The draft concludes our work for the Base API and there can be no more changes that would break binary compatibility at this point is the consensus of the WG and by the IPv6 implementors for this API. IPv6 is now being used by customers and in process. The changes to RFC 2133 did cause pain in the market. Any further change would be devasting to the credibility of IPv6, and to vendor IPv6 products. The only noteworthy editing changes to the 03 draft were as follows: 1) added IEEE 1003.1 note to section 2 Design Considerations in the first bullet. 2) added IEEE 1003.1 note to Section 2.4 Structures. Both of the above do not require anything of an implementation but are nomenclature for a user of the API. 3) In section 3.10 added "__" to all lowercase ss variables to make these ISO C compliant. 4) In section 4.2 Index-to-Name changed IFNAMSIZE to IF_NAMESIZE and in Section 7 summary of definitions. As the IFNAMSIZE broke a vendor implementation. 5) In section 4.4 Free memory for index removed the #include as it is not needed. 6) In section 6.1 added wording from WG mail list to note the change in error value diaognostics for getipnodebyname. 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 Nov 11 20:01:33 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA26988 for ipng-dist; Wed, 11 Nov 1998 19:57:52 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id TAA26981 for ; Wed, 11 Nov 1998 19:57:47 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id TAA22903 for ; Wed, 11 Nov 1998 19:57:41 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id TAA01597 for ipng@sunroof.eng.sun.com; Wed, 11 Nov 1998 19:57:29 -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 TAA26895 for ; Wed, 11 Nov 1998 19:03:06 -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 TAA26439 for ; Wed, 11 Nov 1998 19:03:04 -0800 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by earth.sun.com (8.9.1/8.9.1) with SMTP id TAA13101 for ; Wed, 11 Nov 1998 19:03:06 -0800 (PST) Received: from hugo.usc.edu (hugo.usc.edu [128.125.51.40]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id TAA01528 for ; Wed, 11 Nov 1998 19:03:05 -0800 Received: from hugo (localhost [127.0.0.1]) by hugo.usc.edu (8.8.5/8.6.9) with ESMTP id SAA01309 for ; Wed, 11 Nov 1998 18:56:50 -0800 (PST) Message-Id: <199811120256.SAA01309@hugo.usc.edu> To: ipng@sunroof.eng.sun.com Subject: (IPng 6728) AS# space for IPv6? Date: Wed, 11 Nov 1998 18:56:49 -0800 From: Pavlin Ivanov Radoslavov Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Currently BGP is using 16 bits AS# space. Could you tell me what is (planned to be) the AS space for IPv6. 16 bits, 32 bits, or something else? Thanks, Pavlin -------------------------------------------------------------------- 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 Nov 11 21:41:46 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id VAA27202 for ipng-dist; Wed, 11 Nov 1998 21:38: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 VAA27192 for ; Wed, 11 Nov 1998 21:38:32 -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 VAA20395 for ; Wed, 11 Nov 1998 21:38:31 -0800 Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA14393 for ; Wed, 11 Nov 1998 21:38:26 -0800 (PST) Received: from jimmy.trumpet.com.au (jimmy.trumpet.com.au [203.5.119.2]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id QAA02591 for ; Thu, 12 Nov 1998 16:38:24 +1100 (EST) (envelope-from pete@trumpet.com.au) To: ipng@sunroof.eng.sun.com From: pete@trumpet.com.au (Peter R. Tattam) Subject: (IPng 6729) DNS implementation of IPv6 A6 and other new features Date: Thu, 12 Nov 1998 16:38:09 +1100 Message-ID: <3c4m4jj$1fj@jimmy.trumpet.com.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk These are some concerns that have been brewing over the last couple of weeks. Feel free to shoot me down in flames if I'm out of place or its all been discussed before. While browsing the draft about the revised method of doing name lookups, I became concerned about the A6 proposal (standard now?) The new A6 introduces some inefficiencies that could cause reliability problems as it can potentially require more than one query to resolve a host name. The initial AAAA only requires a single query which would be atomic but an A6 will require multiple queries or multiple responses to a query possibly in a recursive manner. Caching may help, but adds a layer of complexity and uncertainty into the resolvers. Many small stacks (like our own) do a fresh query for each name resolution. While adding the extra records to complete the full recursive lookup of the A6 results can be added in the DNS record, there is a risk of incomplete DNS records, and also of cache entries being stale causing havoc. Also, while compression and the regular DNS method of string handling will reduce the size of the queries it's likely to be larger than the equivalent AAAA entry for the address. For these reasons, I feel that the deprecation of AAAA records in favour of A6 records is a "bad thing". Basically, the issues boil down to increased network usage and reduction in reliability due to the increased complexity, and the added burden on TCP stacks and the bottom of the chain. Considering that resolution of names to addresses is one of the most fundamental operations in the use in the internet, this may make or break the adoption of IPv6 if it is insisted that we deply this system in favour of AAAA records. I propose that if you insist on keeping the A6 structure, that it be used for inter server communication and management while AAAA continue to be fully supported at leaf sites, with servers performing the necessary translations. I do agree however that the reverse lookups do need work as the existing system is indeed quite ugly, but again the adoption of a recursive style system in favour of a flat single entry style lookup suffers from the same design flaws as mentioned earlier. Finally, I must say that the implementation details aren't impossble or even difficult, but rather my concerns are primarily for performance reasons. Those of you who manage a busy ISP or network would understand that minor inefficiencies grow into large ones as the size of networks scales. I'm really puzzled that these issues weren't raised in the draft. Peter -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. Phone: +61-3-6245-0220 Fax: +61-3-6245-0210 -------------------------------------------------------------------- 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 Nov 11 22:12:04 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id WAA27241 for ipng-dist; Wed, 11 Nov 1998 22:04:53 -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 WAA27234 for ; Wed, 11 Nov 1998 22:04:19 -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 WAA23939 for ; Wed, 11 Nov 1998 22:04:17 -0800 Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id WAA25374 for ; Wed, 11 Nov 1998 22:04:12 -0800 (PST) Received: from jimmy.trumpet.com.au (jimmy.trumpet.com.au [203.5.119.2]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id RAA05345 for ; Thu, 12 Nov 1998 17:04:07 +1100 (EST) (envelope-from pete@trumpet.com.au) To: ipng@sunroof.eng.sun.com From: pete@trumpet.com.au (Peter R. Tattam) Subject: (IPng 6730) Re: DNS implementation of IPv6 A6 and other new features Date: Thu, 12 Nov 1998 17:03:52 +1100 Message-ID: <3c657lt$1fk@jimmy.trumpet.com.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <3c4m4jj$1fj@jimmy.trumpet.com.au> pete@trumpet.com.au (Peter R. Tattam) writes: ... >Basically, the issues boil down to increased network usage and reduction in >reliability due to the increased complexity, and the added burden on TCP >stacks and the bottom of the chain. This line should read ... "stacks at the bottom of the chain." Peter -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. Phone: +61-3-6245-0220 Fax: +61-3-6245-0210 -------------------------------------------------------------------- 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 Nov 12 06:16:37 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA27587 for ipng-dist; Thu, 12 Nov 1998 06:11:53 -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 GAA27580 for ; Thu, 12 Nov 1998 06:11:44 -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 GAA19363 for ; Thu, 12 Nov 1998 06:11:42 -0800 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 GAA28886 for ; Thu, 12 Nov 1998 06:11:41 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id OA04874; Fri, 13 Nov 1998 01:11:32 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: pete@trumpet.com.au (Peter R. Tattam) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6733) Re: DNS implementation of IPv6 A6 and other new features In-Reply-To: Your message of "Thu, 12 Nov 1998 16:38:09 +1100." <3c4m4jj$1fj@jimmy.trumpet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Nov 1998 01:11:31 +1100 Message-Id: <12764.910879891@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 12 Nov 1998 16:38:09 +1100 From: pete@trumpet.com.au (Peter R. Tattam) Message-ID: <3c4m4jj$1fj@jimmy.trumpet.com.au> | The initial AAAA only requires a single query which would be atomic Only if one presumes a dumb stub resolver using a smarter host to do the name resolution for it. If the resolver is going to do the entire resolution on its own, it will need be able to do multiple queries to chase the NS records from the root to the zone of interest. | Also, while compression and the regular DNS method of string handling will | reduce the size of the queries it's likely to be larger than the equivalent | AAAA entry for the address. I think this is likely to just the opposite where it matters. That is, for a minimal sized AAAA query, yes, it is possible that an A6 query might be larger. But you can't know that an AAAA query will result in a minimal sized answer, so you need to allow for more than that. Once the AAAA result starts getting potentially larger (that is, when there are multiple records to be returned), the likelihood is that the A6 result will actually be smaller than the AAAA response. It seems to me that this is a good result - what happens to small responses, for which more space needs to be allowed anyway isn't so important, but keeping large responses smaller, so they will keep fitting in a UDP response, is important. | Considering that resolution of names to addresses is one of the most | fundamental operations in the use in the internet, this may make or break | the adoption of IPv6 if it is insisted that we deply this system in | favour of AAAA records. You mean instead of AAAA records. All of these issues are judgement calls. Personally, I feel that the increased flexibility of A6, especially when a renumbering of a site is required, means that because A6 is used will make the whole thing practical in a reasonable way, especially for larger sites, and be one of the big selling points of IPv6 over IPv4. I know I would hate to think about renumbering our site (the DNS is under the control of a diverse group of people) under v4, but with v6, and A6, where we could all simply defer to a single instance of the base (upper bits) part of the address, the DNS changes would be the easiest part of any renumbering, instead of one of the harder parts. | I propose that if you insist on keeping the A6 structure, that it be used for | inter server communication and management while AAAA continue to be fully | supported at leaf sites, with servers performing the necessary translations. It isn't clear just what that would mean - DNS servers (as they are defined in the DNS) can't do it, for all kinds of reasons that we discovered when it was originally proposed that it be done exactly that way. However, I suspect that you really mean that the back end part of a stub-resolver / real-resolver split (the real resolver part) do the A6 processing (as they do NS chain chasing, CNAME handling, etc) and return just a synthesised AAAA record to the stub resolver. That might be a reasonable approach - the only difficulty is in having the back end part of the resolver knowing that the particular query it has received is for a stub resolver rather than a random query from some other source. As things are currently done, there is no difference - all queries look the same. Perhaps if TSIG is in use (which it ought be between stub resolvers and their back ends, in the future) then that mighht be enough (the TSIG association can be configured that way) to provide this info, and the back end would know to allow AAAA records to be synthesised out of A6 responses, and handed back complete. 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 Thu Nov 12 07:10:32 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA27638 for ipng-dist; Thu, 12 Nov 1998 07:02: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 HAA27631 for ; Thu, 12 Nov 1998 07:02:31 -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 HAA25641 for ; Thu, 12 Nov 1998 07:02:28 -0800 Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA24103 for ; Thu, 12 Nov 1998 07:02:28 -0800 (PST) Received: from lana-2.trumpet.com.au (lana-2.trumpet.com.au [203.5.119.82]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id CAA21277; Fri, 13 Nov 1998 02:02:25 +1100 (EST) (envelope-from pete@trumpet.com.au) To: Robert Elz From: pete@trumpet.com.au (Peter R. Tattam) Subject: (IPng 6734) Re: DNS implementation of IPv6 A6 and other new features Date: Fri, 13 Nov 1998 02:04:00 +1100 cc: ipng@sunroof.eng.sun.com Message-ID: <3c0c3c0$1n0@lana-2.trumpet.com.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <12764.910879891@munnari.OZ.AU> Robert Elz writes: >From: Robert Elz >To: pete@trumpet.com.au (Peter R. Tattam) >Cc: ipng@sunroof.Eng.Sun.COM >Subject: Re: (IPng 6729) DNS implementation of IPv6 A6 and other new features >Date: Fri, 13 Nov 1998 01:11:31 +1100 > Date: Thu, 12 Nov 1998 16:38:09 +1100 > From: pete@trumpet.com.au (Peter R. Tattam) > Message-ID: <3c4m4jj$1fj@jimmy.trumpet.com.au> > | The initial AAAA only requires a single query which would be atomic >Only if one presumes a dumb stub resolver using a smarter host to do the >name resolution for it. If the resolver is going to do the entire >resolution on its own, it will need be able to do multiple queries to chase >the NS records from the root to the zone of interest. Um, wouldn't the number of queries potentially increase or am I misunderstanding the A6 scheme. What's the relative percentage of dumb stub resolvers to smart ones out there. I would suspect that the major of leaf sites use a single DNS server with a recursive call to their nearest DNS server to do the job of resolution, especially when the RFC mentions that it's the correct way to do things. How well will existing DNS servers cope with the added demand from stub resolvers having to make repeated calls. The traffic is commonly UDP, and might get really slow over PPP links. In my resolver, I'm already doing repeated calls to cycle through the domain suffix list. I don't do caching because I have to control memory utilization, and stale records can be a pain. Best to let the DNS server handle that as it would do a better job. My concern is that in my experience, the weakest link in TCP/IP is the name services. If they slow down or break for any reason, they cause the most headaches. I've had misbehaving DNS servers cause significant problems for ISPing. Often you don't know there's a problem until other services start to break, or the customers start beating down your door. > | Also, while compression and the regular DNS method of string handling will > | reduce the size of the queries it's likely to be larger than the equivalent > | AAAA entry for the address. >I think this is likely to just the opposite where it matters. That is, >for a minimal sized AAAA query, yes, it is possible that an A6 query might >be larger. But you can't know that an AAAA query will result in a minimal >sized answer, so you need to allow for more than that. Once the AAAA result >starts getting potentially larger (that is, when there are multiple records >to be returned), the likelihood is that the A6 result will actually be smaller >than the AAAA response. It seems to me that this is a good result - what >happens to small responses, for which more space needs to be allowed anyway >isn't so important, but keeping large responses smaller, so they will keep >fitting in a UDP response, is important. Has there been some real life analysis of this? And how much CPU is the compression going to take, memory use to code the algorithm? These are important at the low end of the scale for smaller machines.. IPv6 is being touted for the appliance market don't forget. > | Considering that resolution of names to addresses is one of the most > | fundamental operations in the use in the internet, this may make or break > | the adoption of IPv6 if it is insisted that we deply this system in > | favour of AAAA records. >You mean instead of AAAA records. All of these issues are judgement calls. >Personally, I feel that the increased flexibility of A6, especially when a >renumbering of a site is required, means that because A6 is used will make the >whole thing practical in a reasonable way, especially for larger sites, and >be one of the big selling points of IPv6 over IPv4. I know I would hate to >think about renumbering our site (the DNS is under the control of a diverse >group of people) under v4, but with v6, and A6, where we could all simply defer >to a single instance of the base (upper bits) part of the address, the >DNS changes would be the easiest part of any renumbering, instead of one >of the harder parts. > | I propose that if you insist on keeping the A6 structure, that it be used for > | inter server communication and management while AAAA continue to be fully > | supported at leaf sites, with servers performing the necessary translations. >It isn't clear just what that would mean - DNS servers (as they are defined >in the DNS) can't do it, for all kinds of reasons that we discovered when it >was originally proposed that it be done exactly that way. >However, I suspect that you really mean that the back end part of a >stub-resolver / real-resolver split (the real resolver part) do the A6 >processing (as they do NS chain chasing, CNAME handling, etc) and return >just a synthesised AAAA record to the stub resolver. That might be >a reasonable approach - the only difficulty is in having the back end part of >the resolver knowing that the particular query it has received is for a >stub resolver rather than a random query from some other source. As things >are currently done, there is no difference - all queries look the same. >Perhaps if TSIG is in use (which it ought be between stub resolvers and >their back ends, in the future) then that mighht be enough (the TSIG >association can be configured that way) to provide this info, and the >back end would know to allow AAAA records to be synthesised out of A6 >responses, and handed back complete. Sorry, you'll have to enighten me on the acronym TSIG. >kre Your points are valid, and I fully understand the benefits of the A6 scheme from a management point of view. My concern is that should my gut feelings about this be confirmed, it could set back the deployment of IPv6 further. Just my extra 2 cents worth. Peter -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. Phone: +61-362-450220 Fax: +61-362-450210 -------------------------------------------------------------------- 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 Nov 12 07:25:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA27687 for ipng-dist; Thu, 12 Nov 1998 07:21:28 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id HAA27680 for ; Thu, 12 Nov 1998 07:21:19 -0800 (PST) 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 HAA29953; Thu, 12 Nov 1998 07:21:08 -0800 (PST) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.9.1b+Sun/8.9.1) id HAA17432; Thu, 12 Nov 1998 07:20:25 -0800 (PST) Date: Thu, 12 Nov 1998 07:20:25 -0800 (PST) From: Mukesh Kacker Message-Id: <199811121520.HAA17432@lucknow.eng.sun.com> To: c.harding@opengroup.org, bound@wasted.zk3.dec.com Subject: (IPng 6735) Re: Namespace Pollution and the IPv6 Basic API Cc: ipng@sunroof.eng.sun.com, xnet@opengroup.org X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would just like to add some personal comments/perspective on this issue since some of the discussions went more towards adding heat than light. (Just comments, no changes here so it is not important this didn't go out before yesterdays deadline :-)) What Jim has just submitted represents a good compromise/middle-ground of what was achievable in the namespace area without causing too much pain. In my view, the only significant thing not adopted is what Chris explained as a design principle in formal standards that standards should use a "minimalist" design principle and keep their list of reserved prefixes as brief as possible. In itself, that is a good goal for APIs that are developed from scratch. However that was in conflict in this case with another requirement of "Ease of portability of IPv4 applications". The IPv6 Socket API prefixes are a "logical extension" of the IPv4 Socket API prefixes which makes porting/extending applications easier. That design goal has represents more value BOTH to system vendors and application writers that whatever is achieved with a "minimal" prefix list. Having said that, I would like to thank Chris Harding for his proposal and Jim for adopting what was possible from that which would keep changes if/when these interfaces are added as formal standards to a minimum. Since a lot of "heat" was also part of the discussions, probably because a lot of us feel that formal standards have caused unnecessary pain in the past by adopting some gratuitous changes where the gains did not justify the pains or even made things worse towards usability of the interfaces. The best way to avoid that is to work towards a process more like how IETF protocol standards process works where implementations and field experience is required before full standardization and reviews are more open. And for developers to actively participate in reviews when they happen. However, formal standards do sometimes represent a forum where one can document these interfaces better, add language that reduces ambiguity, refine error codes and take into account any system specific differences which adds good value. In general, they make possible code that is not a pile of #ifdef (PRODUCT_NAME) which is hard to maintain in a portable manner and ideally take implementation experiences into account. If changes happen during formal standardization, I hope the developer community here will review the standards and give feedback and I hope the standards process will be open enough to make the widest possible review possible and balance the "gain" vs "pain" issue for any changes. -------------------------- -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 Thu Nov 12 08:06:44 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA27762 for ipng-dist; Thu, 12 Nov 1998 08:02:54 -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 IAA27755 for ; Thu, 12 Nov 1998 08:02:41 -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 IAA06482 for ; Thu, 12 Nov 1998 08:02:40 -0800 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 IAA26862 for ; Thu, 12 Nov 1998 08:02:37 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id QA06306; Fri, 13 Nov 1998 03:02:28 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: pete@trumpet.com.au (Peter R. Tattam) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6736) Re: DNS implementation of IPv6 A6 and other new features In-Reply-To: Your message of "Fri, 13 Nov 1998 02:04:00 +1100." <3c0c3c0$1n0@lana-2.trumpet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Nov 1998 03:02:28 +1100 Message-Id: <13254.910886548@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 13 Nov 1998 02:04:00 +1100 From: pete@trumpet.com.au (Peter R. Tattam) Message-ID: <3c0c3c0$1n0@lana-2.trumpet.com.au> | Um, wouldn't the number of queries potentially increase or am I | misunderstanding the A6 scheme. There might be more queries, in some cases, yes - but it is "more" that is important here, that it it isn't a change from a single query/response to a complicated process, but a slight potential expansion of an already complicated process (in general). In many typical cases, all the necessary data will be provided in exactly the same number of packets as occurs now (where the names used in A6 responses are in the same domain, or a domain served by the same server, as the name being sought). | I don't do caching because I have to control memory utilization, For something which is mostly over PPP, I think that's a mistake - memory is comparatively cheap these days, ppp bandwidth isn't - but that's an implementation choice. | Has there been some real life analysis of this? I'm not sure, it will certainly depend upon local configuration. | And how much CPU is the | compression going to take, memory use to code the algorithm? No, I think you miss the point. There are no new algorithms, or magic compressions. The savings come because to get a large response, you're getting multiple addresses (that's what makes the response larger than normal). For AAAA records, that means 128 bits of date for every address being returned. For A6, it will typically be 64 bits, an 8 bit count, plus a reference to a name. You'd normally expect that the names referenced would be largely similar, and so regular DNS name compression will allow the name part of the response to be quite short - with intelligent configuration it is likely that 4 bytes will be enough for most cases (32 bits). That means perhaps 104 bits per address (after the first perhaps) rather than 128 bits. Even better, if the reason for multiple addresses is that the site has multiple prefixes, rather than, or in addition to, the host having multiple interfaces (physical or logical), then there's an even bigger saving potential, as instead of having an interfaces by prefixes product of AAAA records, you end up with interfaces plus prefixes plus a couple A6 records - generating the multiples of addresses is done inside the resolver, insteaad of all being included in the packet. That is, the bigger the response would have been, the more likely it will be that A6 will generate packet space savings. | Sorry, you'll have to enighten me on the acronym TSIG. Proposed method of achieving authentication between stup resolvers and their back ends - if you consider that A6 is too comples for low end resolvers, go look at what is required to implement DNSSEC. It is going to be important that DNS responses be authenticated, DNSSEC is how that is done, but that is by no means trivial. TSIG is a proposal to make authentication for low end stub resolvers possible (the back end of the resolver does DNSSEC, and uses TSIG to the stub resolver). See draft-ietf-dnsind-tsig-06.txt - there are a couple of (comparatively minor) issues left to be resolved, then this is due to be sent to IETF last call - it is almost done. 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 Thu Nov 12 09:03:28 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA27860 for ipng-dist; Thu, 12 Nov 1998 08:58: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 IAA27853 for ; Thu, 12 Nov 1998 08:58:30 -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 IAA22888 for ; Thu, 12 Nov 1998 08:58:29 -0800 Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA02842 for ; Thu, 12 Nov 1998 08:58:27 -0800 (PST) Received: from lana-2.trumpet.com.au (lana-2.trumpet.com.au [203.5.119.82]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id DAA02328; Fri, 13 Nov 1998 03:58:24 +1100 (EST) (envelope-from pete@trumpet.com.au) To: ipng@sunroof.eng.sun.com From: pete@trumpet.com.au (Peter R. Tattam) Subject: (IPng 6737) Trumpet Winsock IPv6 Implementation for Windows NT. Date: Fri, 13 Nov 1998 03:59:58 +1100 cc: 6bone@isi.edu Message-ID: <3c2s1m0$1n1@lana-2.trumpet.com.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just posted this... Might be of interest to some people. From: peternews@trumpet.com.au (Peter R. Tattam) Newsgroups: trumpet.announce,alt.winsock.trumpet,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Trumpet Winsock 4.1 Beta 3 Available (Windows NT version, also IPv6 support) Date: Fri, 13 Nov 1998 03:07:05 +1100 This is the first version of Trumpet Winsock that supports Windows NT. It also has IPv6 support. At the moment, only NT 4.0 has been tested. Location ftp://ftp.trumpet.com/winsock/beta-4.1/twsk41b3.exe USA or ftp://ftp.trumpet.com.au/winsock/beta-4.1/twsk41b3.exe Aus Installation on either Windows NT or Windows 95. DISCLAIMER: PLEASE NOTE. THE NT VERSION IS BETA SYSTEM SOFTWARE, AND AS SUCH COULD CAUSE DAMAGE TO YOUR NT FILE SYSTEM. USE AT YOUR OWN RISK. WE WILL ACCEPT NO LIABILITY FOR LOSS OF DATA OR DAMAGE TO YOUR COMPUTER. Please contact me if there are difficulties in installation or uninstallation. While all due care has been taken to integrate the NT version into NT 4.0, there could still be some minor incompatibilities preventing some system applications from working. bug reports to Peter R. Tattam -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. Phone: +61-362-450220 Fax: +61-362-450210 -------------------------------------------------------------------- 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 Nov 12 10:49:24 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA28172 for ipng-dist; Thu, 12 Nov 1998 10:45:20 -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 KAA28165 for ; Thu, 12 Nov 1998 10:45:12 -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 KAA26976 for ; Thu, 12 Nov 1998 10:45:09 -0800 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.192.13]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA13087 for ; Thu, 12 Nov 1998 10:42:42 -0800 (PST) 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 KAA06033 for ; Thu, 12 Nov 1998 10:42:36 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Nov 1998 10:42:52 -0800 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 6738) Orlando meeting times Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We have been assigned the following meeting slots for ipngwg in Orlando: Thursday, December 10 at 1530-1730 other groups scheduled at that time: manet, qosmc-BOF Friday, December 11 at 0900-1130 other groups scheduled at that time: idr, navdec-BOF 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 Thu Nov 12 20:38:49 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id UAA29084 for ipng-dist; Thu, 12 Nov 1998 20:34:33 -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 UAA29077 for ; Thu, 12 Nov 1998 20:34:24 -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 UAA15147 for ; Thu, 12 Nov 1998 20:34:24 -0800 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA16190 for ; Thu, 12 Nov 1998 20:34:24 -0800 (PST) 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 UAA03466 for <@sgi.engr.sgi.com:ipng@sunroof.Eng.Sun.COM>; Thu, 12 Nov 1998 20:34:23 -0800 (PST) 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 UAA38033; Thu, 12 Nov 1998 20:34:22 -0800 (PST) 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 UAA37363; Thu, 12 Nov 1998 20:34:22 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199811130434.UAA37363@bossette.engr.sgi.com> Subject: (IPng 6740) scope_id questions To: ipng@sunroof.eng.sun.com Date: Thu, 12 Nov 1998 20:34:21 -0800 (PST) Cc: sm@cthulhu.engr.sgi.com 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 My view of the scope_id field in the sockaddr_in6 structure is as a kernel `cookie'; i.e. the kernel gives the value to userspace to identify a particular scope and applications pass it back to the kernel, right? So, now a few questions: 1) How is an operating system meant to assign scope_ids to different interfaces for multi-sited hosts? 2) How does a kernel, when configuring a site-local address on an interface, presumably due to a userland request, know which other site-local addresses on the same host (if any) share the same scope_id? 3) If the answer to the above questions is something like `This is user-specified, since the site-boundries are purely administrative boundries and therefore specified in a configuration file somewhere' does anybody have any ideas on how, exactly, scope_ids should be communicated _to_ the kernel during address configuration? Using scope_ids themselves seems bad, due to their ephemeral nature, but maybe with a slight shift in semantics of scope_ids, it would be okay for the user to specify it. It would then be the user's responibility to maintain the scope_id space (at least for site-locals). Has anyone already implemented this? Any answers 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 Nov 12 21:09:35 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id VAA29167 for ipng-dist; Thu, 12 Nov 1998 21:06:19 -0800 (PST) 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 VAA29160 for ; Thu, 12 Nov 1998 21:06:08 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id VAA19119; Thu, 12 Nov 1998 21:06:02 -0800 (PST) Date: Thu, 12 Nov 1998 21:05:13 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6741) Re: scope_id questions To: Sam Manthorpe Cc: ipng@sunroof.eng.sun.com, sm@cthulhu.engr.sgi.com In-Reply-To: "Your message with ID" <199811130434.UAA37363@bossette.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1) How is an operating system meant to assign scope_ids to > different interfaces for multi-sited hosts? Assuming it knows the which interfaces belong in which sites all it needs is to assign unique integers to the "site ids" much like it generates interface ids today. > 2) How does a kernel, when configuring a site-local address > on an interface, presumably due to a userland request, > know which other site-local addresses on the same host > (if any) share the same scope_id? It doesn't. But assuming the interfaces are configured automatically then the mechanisms in draft-ietf-ipngwg-site-prefixes-nn.txt can help. Once your "addrconf daemon" has the site-prefixes for each interface it can make intelligent guesses of how to determine which interfaces belong to the same site. Thus it can tell the kernel what site id to use for each autoconfigured interface. > 3) If the answer to the above questions is something like > `This is user-specified, since the site-boundries are > purely administrative boundries and therefore specified > in a configuration file somewhere' does anybody have > any ideas on how, exactly, scope_ids should be communicated > _to_ the kernel during address configuration? Using > scope_ids themselves seems bad, due to their ephemeral > nature, but maybe with a slight shift in semantics of scope_ids, > it would be okay for the user to specify it. It would > then be the user's responibility to maintain the scope_id > space (at least for site-locals). Has anyone already > implemented this? At some level it is user-specified but with the site-prefixes draft mechanism this would be done on the routers (or border routers if we extend the router renumbering protocol). Thus a router would now that "this site has the prefixes 1:2::0/48 and 2:4::0/48" and a router in another site would be configured with "site prefix 9:9::0/48". A host connected to both routers can determine that they are different sites since the site-prefixes are different. In terms of communicating this to the kernel I'm planning on adding SIOC{S,G}LIFSITEID much like SIOC{S,G}LIFINDEX for the interface index. But I'd expect these ioctls only be used by the "addrconf daemon". Thus the actual ids can be assigned serially at boot just like the interface indicies. BTW: A "link id" concept might also be useful down the road to deal with the cases when there are multiple interfaces (and interface indicies) that apply to the same link. 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 Nov 13 03:14:59 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id DAA29340 for ipng-dist; Fri, 13 Nov 1998 03:11:37 -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 DAA29333 for ; Fri, 13 Nov 1998 03:11:13 -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 DAA29693 for ; Fri, 13 Nov 1998 03:11:11 -0800 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 DAA16128 for ; Fri, 13 Nov 1998 03:11:10 -0800 (PST) Received: by mailgate.rdg.opengroup.org; id AA16322; Fri, 13 Nov 1998 11:13:10 GMT Received: from slip139-92-20-154.wk.uk.ibm.net [139.92.20.154] by mailgate.rdg.opengroup.org via smtpd V1.22 (98/10/13 10:26:28) for ; Fri Nov 13 11:13 GMT 1998 Message-Id: <3.0.3.32.19981113105120.007c5120@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 13 Nov 1998 10:51:20 +0000 To: ipng@sunroof.eng.sun.com From: Chris Harding Subject: (IPng 6742) Re: (c.harding 22333) Base API Last Call Edits In-Reply-To: <199811120237.AA02523@quarry.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi - As there has been no support on the ipng list for the bulk of the name changes that I proposed, I concur with the approach taken by Jim, and support the draft going to RFC. >The only noteworthy editing changes to the 03 draft were as follows: > >1) added IEEE 1003.1 note to section 2 Design Considerations in the > first bullet. > >2) added IEEE 1003.1 note to Section 2.4 Structures. > >Both of the above do not require anything of an implementation but are >nomenclature for a user of the API. > >3) In section 3.10 added "__" to all lowercase ss variables to make >these ISO C compliant. > >4) In section 4.2 Index-to-Name changed IFNAMSIZE to IF_NAMESIZE and in >Section 7 summary of definitions. As the IFNAMSIZE broke a vendor >implementation. > >5) In section 4.4 Free memory for index removed the #include >as it is not needed. > >6) In section 6.1 added wording from WG mail list to note the change in >error value diaognostics for getipnodebyname. > 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 Fri Nov 13 07:48:44 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA29433 for ipng-dist; Fri, 13 Nov 1998 07:45:21 -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 HAA29426 for ; Fri, 13 Nov 1998 07:45:10 -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 HAA03584 for ; Fri, 13 Nov 1998 07:45:09 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA28929 for ; Fri, 13 Nov 1998 07:45:08 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA11927; Fri, 13 Nov 1998 10:45:04 -0500 (EST) Message-Id: <199811131545.KAA11927@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 6743) I-D ACTION:draft-ietf-ipngwg-bsd-api-new-04.txt Date: Fri, 13 Nov 1998 10:45:03 -0500 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-04.txt Pages : 33 Date : 12-Nov-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-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-bsd-api-new-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.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-04.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: <19981112094734.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-new-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-bsd-api-new-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981112094734.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 Nov 13 13:38:17 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA29884 for ipng-dist; Fri, 13 Nov 1998 13:34:40 -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 NAA29877 for ; Fri, 13 Nov 1998 13:34:31 -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 NAA29720; Fri, 13 Nov 1998 13:34:28 -0800 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA23811; Fri, 13 Nov 1998 13:34:28 -0800 (PST) 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 NAA04765; Fri, 13 Nov 1998 13:34:26 -0800 (PST) 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 NAA83420; Fri, 13 Nov 1998 13:34:23 -0800 (PST) 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 NAA40790; Fri, 13 Nov 1998 13:34:23 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199811132134.NAA40790@bossette.engr.sgi.com> Subject: (IPng 6744) Re: scope_id questions To: Erik.Nordmark@Eng Date: Fri, 13 Nov 1998 13:34:23 -0800 (PST) Cc: ipng@sunroof.eng.sun.com, sm@cthulhu.engr.sgi.com In-Reply-To: from "Erik Nordmark" at Nov 12, 98 09:05:13 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 Erik, Thanks for the reply. I'm afraid I'm still a bit in the dark: > > 3) If the answer to the above questions is something like > > `This is user-specified, since the site-boundries are > > purely administrative boundries and therefore specified > > in a configuration file somewhere' does anybody have > > any ideas on how, exactly, scope_ids should be communicated > > _to_ the kernel during address configuration? Using > > scope_ids themselves seems bad, due to their ephemeral > > nature, but maybe with a slight shift in semantics of scope_ids, > > it would be okay for the user to specify it. It would > > then be the user's responibility to maintain the scope_id > > space (at least for site-locals). Has anyone already > > implemented this? > > At some level it is user-specified but with the site-prefixes draft mechanism > this would be done on the routers (or border routers if we extend the router > renumbering protocol). If we are considering a multi-sited host then aren't we actually talking about a router rather than a host? > Thus a router would now that "this site has the > prefixes 1:2::0/48 and 2:4::0/48" and a router in another site would > be configured with "site prefix 9:9::0/48". A host connected to both routers > can determine that they are different sites since the site-prefixes are > different. Okay, I'm confused. Are you saying that part or all of the subnet ID can be used to distinguish between sites? Surely not. I don't see any reason why the host connected to both sites can't receive exactly the same subnet IDs from both routers (using your scheme), even though they come from different sites. Surely, I, wearing my site-administrator hat, am allowed to allocate my subnet-ID address space however I chose, and my neighbouring site-admin is free to do the same. Taking your model (where a host is connected to multiple sites rather than a router being connected to multiple sites): site A site B |----------------| |-----------------| r1 ------------- h1 -------------- r2 if_0 if_1 fec0:0:0:1::1 fec0:0:0:1::2 Host h1 is connected to site A on interface if_0 and to site B on interface if_1. The subnet to which if_0 is connected has a subnet ID of 1 (on site A) and the subnet to which if_1 is connected also has a subnet ID of 1 (on site B), which is okay because each interface belongs to a different scope. Host h1, however, must be aware that the two belong to different sites. Among other things, it must not forward packets from site A to site B. If subnet IDs must be globally unique, as you are suggesting, then what's the difference between site-local and global addresses? > In terms of communicating this to the kernel I'm planning on adding > SIOC{S,G}LIFSITEID much like SIOC{S,G}LIFINDEX for the interface > index. But I'd expect these ioctls only be used by the "addrconf daemon". Sounds reasonable. This pushes the fundamental question out of the kernel into the "addrconf daemon", which I beleive is the correct place for it to be. So now, how does the "addrconf daemon" distinguish between sites? The conceptual model I have seems to be different to the one you have. I'm assuming that any node connected to more than one site is a router and so there's no question of receiving site prefixes or any other kind of config information from a router. The buck stops here, so to speak. > Thus the actual ids can be assigned serially at boot just like the > interface indicies. No, because that would force each interface to belong to a different site, which isn't what I want. The allocation of interface to site seems to me to be a sysadmin decision. > BTW: A "link id" concept might also be useful down the road to deal > with the cases when there are multiple interfaces (and interface indicies) that > apply to the same link. Agreed. -- 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 Mon Nov 16 02:01:58 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id BAA01743 for ipng-dist; Mon, 16 Nov 1998 01:58:08 -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 BAA01736 for ; Mon, 16 Nov 1998 01:57:57 -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 BAA01678 for ; Mon, 16 Nov 1998 01:57:56 -0800 Received: from outside2.enea.se ([192.36.1.249]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA08862 for ; Mon, 16 Nov 1998 01:57:56 -0800 (PST) Received: (from bin@localhost) by outside2.enea.se (8.9.0/8.9.0) id KAA21723 for ; Mon, 16 Nov 1998 10:45:41 +0100 X-Authentication-Warning: outside2.enea.se: bin set sender to using -f Received: from freja(172.16.1.3) by outside2.enea.se via smap (V2.1) id xma021717; Mon, 16 Nov 98 10:45:36 +0100 Received: from enea.se () by (8.8.5/8.8.0) with ESMTP id KAA28638 for ; Mon, 16 Nov 1998 10:54:54 +0100 (MET) Message-ID: <364FF68D.BAC11CCD@enea.se> Date: Mon, 16 Nov 1998 10:55:25 +0100 From: Martin Johnsson Reply-To: marj@enea.se X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 6748) delay measurements Content-Type: multipart/mixed; boundary="------------C316BCCC6E844D3185667C15" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------C316BCCC6E844D3185667C15 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Can anyone please tell me or give me some pointers about how one may achieve a simple method for measuring delay in IPv6. My reference is the the ICMPv4 timestamp message, and this has been removed in ICMPv6. Why? Thanks for any response in advance! Yours, Martin --------------C316BCCC6E844D3185667C15 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Description: Card for Martin Johnsson Content-Disposition: attachment; filename="vcard.vcf" Content-Transfer-Encoding: 7bit begin: vcard fn: Martin Johnsson n: Johnsson;Martin org: ENEA DATA, TransNet adr: Nytorpsvagen 5B;;;Taby;;18323;Sweden email;internet: martin@enea.se title: Senior Systems Analyst tel;work: +46-8-638-5000 tel;fax: +46-8-638-5050 x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------C316BCCC6E844D3185667C15-- -------------------------------------------------------------------- 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 Nov 16 02:30:08 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id CAA01779 for ipng-dist; Mon, 16 Nov 1998 02:27:45 -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 CAA01772 for ; Mon, 16 Nov 1998 02:27:36 -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 CAA03984 for ; Mon, 16 Nov 1998 02:27:35 -0800 Received: from turmeric.itojun.org (dhcp102.iijlab.net [202.232.15.102]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA25845 for ; Mon, 16 Nov 1998 02:27:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by turmeric.itojun.org (8.8.5/3.7W) with ESMTP id TAA12450 for ; Mon, 16 Nov 1998 19:27:27 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 6749) getaddrinfo() return value ai_canonname on errors 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 X-Mailer: comp (MHng project) version 1998/02/23 14:27:23, by Jun-ichiro Itoh MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-ID: Date: Mon, 16 Nov 1998 19:27:26 +0900 Message-ID: <12448.911212046@turmeric.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I have a tiny question about ai_canonname member in struct addrinfo. What is the value held in ai_canonname, when AI_CANONNAME is specified and canonical name (PTR record) is not found? From the textual description (quoted below) I believe this to be NULL. Is it correct? I'm curious about this because gethostbyname() puts the hostname specified by the caller into h_name member of struct hostent, when PTR record is not found. If ai_canonname is relevant to h_name, we may have to set the hostname specified by the caller to ai_canonname. itojun --- bsd-api-new-04 If the AI_CANONNAME bit is set in the ai_flags member of the hints structure, then upon successful return the ai_canonname member of the first addrinfo structure in the linked list will point to a null- terminated string containing the canonical name of the specified nodename. -------------------------------------------------------------------- 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 Nov 16 06:07:47 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA02100 for ipng-dist; Mon, 16 Nov 1998 06:04:37 -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 GAA02093 for ; Mon, 16 Nov 1998 06:04:29 -0800 (PST) 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 GAA20311 for ; Mon, 16 Nov 1998 06:04:26 -0800 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 GAA11610 for ; Mon, 16 Nov 1998 06:04:27 -0800 (PST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0a) with SMTP id JAA14863; Mon, 16 Nov 1998 09:04:25 -0500 (EST) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA21857; Mon, 16 Nov 1998 09:04:23 -0500 Message-Id: <199811161404.AA21857@quarry.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com, scoya@cnri.reston.va.us Subject: (IPng 6750) Re: Orlando meeting times In-Reply-To: Your message of "Thu, 12 Nov 1998 10:42:52 PST." Date: Mon, 16 Nov 1998 09:04:23 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, Friday is ridiculous. I won't be there then. there should NO IETF meetings on Fridays. It is the holiday season I won't let it affect mine one bit for this standards body. I have complained about this for two years to the IETF and the powers that be, I accept I am a minority. Hence, if a critical issue changes direction at a Friday meeting and I am not there for me it is not done and if I have issues and it involves last call docs I will bring them up on email following the meeting. I might be willing to be there on Fridays but at this time of the year it is totally unacceptable IMO. Friday is a travel day to get back home. I completely have given up the previous holiday season weekend for IETF and our standards business. I won't affect two of my weekends with my family. Again totally unacceptable. Also I fear you may loose others. Is IPv6 so unimportant to other things in the IETF that it is slipped out to a Friday meeting? It appears so to me. sincerely, /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 Nov 16 10:09:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA02457 for ipng-dist; Mon, 16 Nov 1998 10:04:45 -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 KAA02450 for ; Mon, 16 Nov 1998 10:04:32 -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 KAA23817 for ; Mon, 16 Nov 1998 10:04:29 -0800 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA25654 for ; Mon, 16 Nov 1998 10:04:29 -0800 (PST) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.1/8.9.1) with ESMTP id SAA03392; Mon, 16 Nov 1998 18:01:33 GMT Message-Id: <199811161801.SAA03392@inner.net> To: Jun-ichiro itojun Itoh cc: ipng@sunroof.eng.sun.com Subject: (IPng 6753) Re: getaddrinfo() return value ai_canonname on errors In-reply-to: Your message of "Mon, 16 Nov 1998 19:27:26 +0900." <12448.911212046@turmeric.itojun.org> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Sat, 01 Jan 2000 08:03:04 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <12448.911212046@turmeric.itojun.org>, you write: > What is the value held in ai_canonname, when AI_CANONNAME is specified > and canonical name (PTR record) is not found? I interpreted ai_canonname differently than you have. Remember that res_search() takes a name argument like "foo" and starts a loop of making it into a FQDN and querying that name for records, so you might have transactions like: foo.bar.foo.org. -> NXDOMAIN foo.foo.org. -> IN A 1.2.3.4, IN AAAA 3ffe:1234::42 From my read of the (POSIX) spec, I decided that it was allowable to simply take the query that succeeded and extract the resulting FQDN from it. So calling getaddrinfo on "foo" with AI_CANONNAME set will return ai_canonname being "foo.foo.org." This approach also saves a DNS transaction. If you want to get the reverse name (e.g., to do a forward/reverse DNS matching check), all you have to do is feed your result back into getnameinfo(). If AI_CANONNAME returned the reverse name, it seemed to me like this would be a less clean interface; getaddrinfo should be the forward lookup, and getnameinfo should be the reverse lookup, so a better approach would then be to eliminate AI_CANONNAME altogether. My definition gives both AI_CANONNAME and the sequence of calling getnameinfo() after getaddrinfo() reasonable meanings. -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 Nov 16 10:44:20 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA02571 for ipng-dist; Mon, 16 Nov 1998 10:39:30 -0800 (PST) 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 KAA02564 for ; Mon, 16 Nov 1998 10:39:25 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA27920 for ; Mon, 16 Nov 1998 10:39:20 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA05561 for ipng@sunroof.eng.sun.com; Mon, 16 Nov 1998 10:39:04 -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 HAA02204 for ; Mon, 16 Nov 1998 07:13:05 -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 HAA08245 for ; Mon, 16 Nov 1998 07:13:04 -0800 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 HAA27576 for ; Mon, 16 Nov 1998 07:13:02 -0800 (PST) Received: from alden ([10.128.1.82]) by dokka.maxware.no (8.8.7/8.8.7) with SMTP id QAA13937; Mon, 16 Nov 1998 16:11:08 +0100 Message-Id: <3.0.2.32.19981116161336.009edb80@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Mon, 16 Nov 1998 16:13:36 +0100 To: bound@zk3.dec.com, Steve Deering From: Harald Tveit Alvestrand Subject: (IPng 6754) Re: Orlando meeting times Cc: ipng@sunroof.eng.sun.com, scoya@cnri.reston.va.us In-Reply-To: <199811161404.AA21857@quarry.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Friday meetings are done at the request of the IETF members, as the better alternative to 8-10 parallell sessions. Every time this has been brought up in the plenary, a solid majority favours using Friday time for WG meetings. Harald (who would prefer IETFs to go Wednesday-Wednesday) -- 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 Mon Nov 16 10:44:17 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA02580 for ipng-dist; Mon, 16 Nov 1998 10:40:20 -0800 (PST) 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 KAA02573 for ; Mon, 16 Nov 1998 10:40:00 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA28010 for ; Mon, 16 Nov 1998 10:39:55 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA05589 for ipng@sunroof.eng.sun.com; Mon, 16 Nov 1998 10:39:39 -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 HAA02216 for ; Mon, 16 Nov 1998 07:13:28 -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 HAA08364 for ; Mon, 16 Nov 1998 07:13:26 -0800 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 HAA27820 for ; Mon, 16 Nov 1998 07:13:26 -0800 (PST) Received: from alden ([10.128.1.82]) by dokka.maxware.no (8.8.7/8.8.7) with SMTP id QAA13934; Mon, 16 Nov 1998 16:11:07 +0100 Message-Id: <3.0.2.32.19981116160907.009ea180@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Mon, 16 Nov 1998 16:09:07 +0100 To: Robert Elz , pete@trumpet.com.au (Peter R. Tattam) From: Harald Tveit Alvestrand Subject: (IPng 6755) Re: DNS implementation of IPv6 A6 and other new features Cc: ipng@sunroof.eng.sun.com In-Reply-To: <12764.910879891@munnari.OZ.AU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 01:11 13.11.98 +1100, Robert Elz wrote: > | I propose that if you insist on keeping the A6 structure, that it be used for > | inter server communication and management while AAAA continue to be fully > | supported at leaf sites, with servers performing the necessary translations. > >It isn't clear just what that would mean - DNS servers (as they are defined >in the DNS) can't do it, for all kinds of reasons that we discovered when it >was originally proposed that it be done exactly that way. could you rehash the reasons, please? This wasn't mentioned when the AAAA/A6 coexistence/transition was being muttered about (too few messages to call a debate :-) in NGTRANS. (detecting the difference between a dumb stub and a smart resolver: stubs ask for AAAA. Smart resolvers ask for A6 (and AAAA, just in case there are old systems. I think.) Harald -- 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 Tue Nov 17 03:40:54 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id DAA03524 for ipng-dist; Tue, 17 Nov 1998 03:37:36 -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 DAA03517 for ; Tue, 17 Nov 1998 03:37:27 -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 DAA07745 for ; Tue, 17 Nov 1998 03:37:25 -0800 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 DAA29198 for ; Tue, 17 Nov 1998 03:37:22 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id LA26603; Tue, 17 Nov 1998 22:36:58 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Harald Tveit Alvestrand Cc: pete@trumpet.com.au (Peter R. Tattam), ipng@sunroof.eng.sun.com Subject: (IPng 6757) Re: DNS implementation of IPv6 A6 and other new features In-Reply-To: Your message of "Mon, 16 Nov 1998 16:09:07 BST." <3.0.2.32.19981116160907.009ea180@dokka.maxware.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Nov 1998 22:36:57 +1100 Message-Id: <27565.911302617@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 16 Nov 1998 16:09:07 +0100 From: Harald Tveit Alvestrand Message-ID: <3.0.2.32.19981116160907.009ea180@dokka.maxware.no> | could you rehash the reasons, please? They largely relate to security, and how a DNS response that is generated by the server could possibly be signed (given that for some security the keys are not kept on line, zones are signed off line). | This wasn't mentioned when the AAAA/A6 coexistence/transition was being | muttered about (too few messages to call a debate :-) in NGTRANS. The issues are different when you're considering a short term transition issue (how we get from what we now have to where we want to be) - especially when the major problem with the approach is security, which we don't have working at all yet in any detectable way. When you're considering a permanent solution, then we have to look at how thing will work in the future, not just now - and for the future we have to assume that some kind of security is in place. If the (remote) server synthesises (128 bit) AAAA out of its components, it has to obtain, and verify, the signatures of the parts. Now we can assume that at least one part (typically the least significant part) will be owner by that server, for that part is easy, but the other components might need to be fetched from other servers in the worst cases. While verifying that the data is authentic is what dnssec is all about, so that should be possible, it is entirely reasonable to imagine security scenarios where the original client might have accepted (trusted) a response that the server doing the synthesising might not (or vice versa). That is, there would need to be a bunch of extra data passed around between the client (resolver) and the server to allow everyone to be aware of just what had been done. And all that is aside from the problem of how the server, once it has produced the AAAA, actually authenticates that to the resolver (if it signs it, assuming it can find its key somehow, then the client will believe that the server is guaranteeing that information, whereas what it is really doing is passing along information that it obtained from elsewhere). Even then, all that assumes that all of the data is signed - once you start mixing signed with unsigned (unauthenticated) data, things get even messier. The only reasonable solution to all of this is simply to give the end resolver all of the data, the parts of the final AAAA (the A6 records) and their signatures, and allow it to implement its own verification policy (which may vary anywhere from "I don't care, I see data, I loke it", to "I see a signature, it must be OK", all the way to "While I see a signature, that was signed by incompetant inc, and I dont' trust any signatures from them, so I will drop this data". | (detecting the difference between a dumb stub and a smart resolver: | stubs ask for AAAA. Smart resolvers ask for A6 (and AAAA, just in case | there are old systems. I think.) Yes, there may be something in having resolver parts (between themselves) do an AAAA query, and have the back end part of the resolver do A6 queries, signature verification, etc, and finally pass the "answer" back to the stub resolver. Dumb stub resolvers cause problems for authentication as well - if putting A6 processing (which is really pretty simple stuff) into your backend is considered too complex to deal with, then putting DNSSEC verification in there is going to be way out of the even conceivable. That's why TSIG is being developed - a much simpler authentication mechanism, but one which requires shared keys between the parties (and so is useless for general DNS work). The plan is that the dumb resolver uses TSIG to authenticate its communications with the back end resolver, which uses DNSSEC to verify the answers, and having done that, continuing with the TSIG communications, passes the results back to the stub resolver. If that's going to happen, it seems to me that it would also be reasonable to do A6->AAAA construction at the same point. The existance of TSIG (which involves a pre-established association) allows the back end resolver to understand that an AAAA query it receives is from a stub resolver, and so A6 responses should be reconstructed into an AAAA to return to the stub. We can't simply have that happening all the time, as, as you point out, for some time anyway we're going to have AAAA queries being made, just in case the server for the zone hasn't changed from AAAA to A6 in its zone files yet. With the current state of the universe, "back end resolvers" and "servers" are one and the same thing - and the queries they receive are indisinguishable. A way is needed to actually distinguish the two cases, so the server/resolver can determine in which role it is being queried. TSIG is the one thing on the horizon which just might permit that. The conclusion from all of this is that stub resolver implementors should certainly *all* be implementing TSIG (and somehow dealing with the issue of where the shared key information is to come from). That's likely to be true, regardless of what is finally done with AAAA / A6. TSIG is not yet an RFC, though it is close. The current draft draft-ietf-dnsind-tsig-06.txt should certainly be stable enough now for implementations to proceed upon it with confidence. You might also care to look at draft-skwan-gss-tsig-02.txt though I'm not sure that that one (alternate algorithm) has widespread support yet (when you get to talking about the details of security algorithms you go way out of my league, I don't pretend to understand what the issues are). 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 Wed Nov 18 04:37:53 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA04692 for ipng-dist; Wed, 18 Nov 1998 04:34:12 -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 EAA04685 for ; Wed, 18 Nov 1998 04:34:04 -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 EAA23605 for ; Wed, 18 Nov 1998 04:34:02 -0800 Received: from hcoss.uia.ac.be (hcoss.uia.ac.be [143.169.1.8]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA08241 for ; Wed, 18 Nov 1998 04:34:01 -0800 (PST) Received: from hcoss.uia.ac.be by hcoss.uia.ac.be; (8.8.6/1.1.8.2/22Feb95-0943AM) id NAA24963; Wed, 18 Nov 1998 13:33:34 +0100 (MET) Message-Id: <199811181233.NAA24963@hcoss.uia.ac.be> Date: Wed, 18 Nov 1998 13:33:34 +0100 (MET) From: "Benny.VanHoudt" Reply-To: "Benny.VanHoudt" Subject: (IPng 6760) receiving Neighbor Ads. To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XFgEJxsIOz22/cdnOSTXww== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I had a small question concerning the IETF-draft on Neighbor Discovery for IPv6. It concerns paragraph 7.2.5 on the receipt of Neighbor Advertisements. The last paragraph of this section (7.2.5) starts with "The above rules ensure that the cache is updated when the ..." and continues with "If none of the above apply, ..." My question is when does none of the above apply ? If I understood well (which I probably didn't) the Override flag is clear is such a case, the Target Link-layer address is present and differs from that one in the cache (and the reachability state differs from INCOMPLETE). This can't be correct because this case was dealt with in one of the paragraphs preceding the one quoted above. Can anyone help? B. ------------------------------------------------------------------- Benny Van Houdt, University of Antwerp Dept. Math. and Computer Science PATS - Performance Analysis of Telecommunication Systems Research Group Universiteitsplein, 1 B-2610 Antwerp Belgium email: vanhoudt@uia.ua.ac.be -------------------------------------------------------------------- -------------------------------------------------------------------- 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 Nov 18 22:11:45 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id VAA05567 for ipng-dist; Wed, 18 Nov 1998 21:59:07 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id VAA05555 for ; Wed, 18 Nov 1998 21:58:56 -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 VAA21225 for ; Wed, 18 Nov 1998 21:58:57 -0800 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 VAA21319 for ; Wed, 18 Nov 1998 21:58:57 -0800 (PST) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Wed, 18 Nov 1998 21:58:57 -0800 Message-ID: <4FD6422BE942D111908D00805F3158DF0722293E@RED-MSG-52> From: Brian Zill To: ipng@sunroof.eng.sun.com Subject: (IPng 6762) Problem with "smart" layer 2 switches Date: Wed, 18 Nov 1998 21:58:56 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a FYI about a problem we ran into recently that I thought might interest others on this list. It's likely to pose a problem with some IPv6 deployments. Our facilities folks just put in a "smart" 10/100 BaseT ethernet switch to service our building. It has a feature that's intended to reduce unnecessary multicast traffic on the individual segments. When this feature is enabled, it doesn't propagate packets for ethernet multicast addresses to all ports on the switch. Instead, it snoops all the incoming ports for IGMP (v4) join messages and only then enables multicast traffic for the port it saw the join on (and even then I believe it only enables traffic to that specific multicast address). Needless to say, this breaks Neighbor Discovery for IPv6. We had a representative from the switch vendor onsite yesterday (an engineer, not a sales/marketing guy), and this was the first he had ever heard of IPv6's multicast requirements. I explained the issue to him, so at least one vendor of such devices is now aware of it. Fortunately, this feature can be disabled on our switch. In talking with our facilities people, I got the impression that these sort of IPv4 centric features are becoming more common on layer 2 switches. So this is one more potential problem to look for when deploying v6. I suppose it could even be a barrier to deployment in environments where the local network manager has become attached to this sort of feature. --Brian -------------------------------------------------------------------- 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 Nov 19 01:35:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id BAA05674 for ipng-dist; Thu, 19 Nov 1998 01:32:53 -0800 (PST) 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 BAA05667 for ; Thu, 19 Nov 1998 01:32:45 -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 BAA23345 for ; Thu, 19 Nov 1998 01:32:43 -0800 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA03972 for ; Thu, 19 Nov 1998 01:32:43 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id KAA23981; Thu, 19 Nov 1998 10:32:41 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id KAA13614; Thu, 19 Nov 1998 10:32:41 +0100 (MET) Message-Id: <199811190932.KAA13614@givry.inria.fr> From: Francis Dupont To: Brian Zill cc: ipng@sunroof.eng.sun.com Subject: (IPng 6763) Re: Problem with "smart" layer 2 switches In-reply-to: Your message of Wed, 18 Nov 1998 21:58:56 PST. <4FD6422BE942D111908D00805F3158DF0722293E@RED-MSG-52> Date: Thu, 19 Nov 1998 10:32:41 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: This is a FYI about a problem we ran into recently that I thought might interest others on this list. It's likely to pose a problem with some IPv6 deployments. Our facilities folks just put in a "smart" 10/100 BaseT ethernet switch to service our building. It has a feature that's intended to reduce unnecessary multicast traffic on the individual segments. When this feature is enabled, it doesn't propagate packets for ethernet multicast addresses to all ports on the switch. Instead, it snoops all the incoming ports for IGMP (v4) join messages and only then enables multicast traffic for the port it saw the join on (and even then I believe it only enables traffic to that specific multicast address). => it is a correct behavior (we asked for it two years ago) but of course only for 1:0:5e:xx:yy:zz with xx < 80 only. Needless to say, this breaks Neighbor Discovery for IPv6. We had a representative from the switch vendor onsite yesterday (an engineer, not a sales/marketing guy), and this was the first he had ever heard of IPv6's multicast requirements. => perhaps it was the first time he has ever heard of something else than IPv4 on Ethernet... I explained the issue to him, so at least one vendor of such devices is now aware of it. Fortunately, this feature can be disabled on our switch. => you (we?) should explain that IGMP spoofing is a good (smart :-) feature but it must be correctly implemented. Do we need an information RFC about it ? In talking with our facilities people, I got the impression that these sort of IPv4 centric features are becoming more common on layer 2 switches. So this is one more potential problem to look for when deploying v6. I suppose it could even be a barrier to deployment in environments where the local network manager has become attached to this sort of feature. => there are new versions of IGMP in the pipe and perhaps MLD spoofing will be nice then this issue is important... Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- 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 Nov 19 06:48:08 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA05896 for ipng-dist; Thu, 19 Nov 1998 06:44:28 -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 GAA05889 for ; Thu, 19 Nov 1998 06:44:14 -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 GAA21751 for ; Thu, 19 Nov 1998 06:44:11 -0800 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 GAA21402 for ; Thu, 19 Nov 1998 06:44:13 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA09843; Thu, 19 Nov 1998 08:42:45 -0600 (CST) Message-Id: <199811191442.IAA09843@gungnir.fnal.gov> To: Brian Zill Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" X-Mailer: Microsoft Outlook98 Subject: (IPng 6764) Re: Problem with "smart" layer 2 switches In-reply-to: Your message of Wed, 18 Nov 1998 21:58:56 PST. <4FD6422BE942D111908D00805F3158DF0722293E@RED-MSG-52> Date: Thu, 19 Nov 1998 08:42:45 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If the "smart" switch filters multicast packets which aren't IP(v4), it's already broken, with or without IPv6 present on the network. Think of Appletalk, DECNET, and all the other protocols which do multicasts. Matt Crawford "We break more code before 8 AM than most people write all day." -------------------------------------------------------------------- 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 Nov 19 08:12:08 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA05979 for ipng-dist; Thu, 19 Nov 1998 08:02:19 -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 IAA05972 for ; Thu, 19 Nov 1998 08:02: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 IAA29047 for ; Thu, 19 Nov 1998 08:02:06 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA07659 for ; Thu, 19 Nov 1998 08:02:02 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA11303; Thu, 19 Nov 1998 11:01:24 -0500 (EST) Message-Id: <199811191601.LAA11303@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 6765) I-D ACTION:draft-ietf-ipngwg-iana-tla-00.txt Date: Thu, 19 Nov 1998 11:01:24 -0500 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 : Initial IPv6 Sub-TLA ID Assignments Author(s) : B. Hinden, S. Deering, R. Fink, T. Hain Filename : draft-ietf-ipngwg-iana-tla-00.txt Pages : 5 Date : 17-Nov-98 This document proposes initial assignments of IPv6 Sub-TLA Aggregation Identifiers (Sub-TLA ID) to the Address Registries and continued management of the IP6.INT domain. It is intended as input to the IANA from the IETF IP Next Generation (IPNG) and Next Generation Transition (NGTRANS) working groups as an aid in starting the process of allocating IPv6 addresses. It is not intended for any official IETF status. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-iana-tla-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-iana-tla-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.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-iana-tla-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: <19981118090909.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-iana-tla-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-iana-tla-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981118090909.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 Thu Nov 19 12:25:21 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA06466 for ipng-dist; Thu, 19 Nov 1998 12:10:55 -0800 (PST) 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 MAA06459 for ; Thu, 19 Nov 1998 12:10:42 -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 MAA21852 for ; Thu, 19 Nov 1998 12:10:38 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.9.1/8.9.1) with SMTP id MAA03555 for ; Thu, 19 Nov 1998 12:10:39 -0800 (PST) Received: from feller.mentat.com by mentat.com (SMI-8.6/SMI-4.1) id MAA20552; Thu, 19 Nov 1998 12:10:02 -0800 Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id MAA18298; Thu, 19 Nov 1998 12:11:29 -0800 Date: Thu, 19 Nov 1998 12:11:29 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199811192011.MAA18298@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 6766) Re: Problem with "smart" layer 2 switches X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > > In talking with our facilities people, I got the impression that these sort > of IPv4 centric features are becoming more common on layer 2 switches. So > this is one more potential problem to look for when deploying v6. I suppose > it could even be a barrier to deployment in environments where the local > network manager has become attached to this sort of feature. > At one time it was suggested that IGMPv6/MLD be used for all IPv6 multicast addresses. That is, registrations for the all-nodes, all-routers and solicited node multicast address all be required to send group report messages so that boxes of this sort could get a clue about IPv6. At a minimum it would seem that a report for the solicited nodes multicast address would be required in order for these boxes to get a clue. What makes IPv6 different than other protocols like AppleTalk is that the solicited nodes multicast address is not well known. These boxes can have special rules that deal with well known addresses. That won't work for solicited node multicast addresses since they are derived from the link token. As an alternative to using MLD I suppose these boxes could use 33:33:ff prefix of the link-layer address associated with the solicited nodes multicast as an indicator that it should switch the packet onto all segments. The ability to do this type of address specific switching might already exist in some of these boxes today. Tim Hartrick Mentat 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 Mon Nov 23 04:25:35 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA09022 for ipng-dist; Mon, 23 Nov 1998 04:21:05 -0800 (PST) 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 EAA09015 for ; Mon, 23 Nov 1998 04:20:57 -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 EAA02939 for ; Mon, 23 Nov 1998 04:20:55 -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 EAA07395 for ; Mon, 23 Nov 1998 04:20:54 -0800 (PST) Received: from cauchy.cs.uni-bonn.de (cauchy.cs.uni-bonn.de [131.220.4.169]) by theoryx.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id NAA24307 for ; Mon, 23 Nov 1998 13:20:50 +0100 (MET) Received: (from ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.8.8) id NAA11606; Mon, 23 Nov 1998 13:20:50 +0100 (MET) Message-ID: <19981123132048.E11178@cs.uni-bonn.de> Date: Mon, 23 Nov 1998 13:20:48 +0100 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Subject: (IPng 6770) ARCnet: progress report 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 Hello, I would have sent this earlier if I wasn't ill for a week: We'll get a separate ARCnet protocol id for IPng today (in the time zone of some Datapoint building in the USA). I'll rework the draft, hopefully some time tomorrow central European time and publish it afterwards. [It is not possible to create a version with a symbol instead of the protocol ID, as some of that protocol ID space uses sub-ids, and we might get a 2-byte ID... this will also require adjustment of the MTU stuff.] Regards, Ignatios Souvatzis -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- 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 Nov 23 15:06:38 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA09647 for ipng-dist; Mon, 23 Nov 1998 15:01:20 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA09637 for ; Mon, 23 Nov 1998 15:01:05 -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 PAA20183 for ; Mon, 23 Nov 1998 15:01:04 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA29568 for ; Mon, 23 Nov 1998 15:01:03 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA04862; Mon, 23 Nov 1998 18:00:51 -0500 (EST) Message-Id: <199811232300.SAA04862@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 6771) I-D ACTION:draft-ietf-ipngwg-esd-analysis-03.txt Date: Mon, 23 Nov 1998 18:00:51 -0500 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 : Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 Author(s) : M. Crawford, A. Mankin, T. Narten, J. Stewart, L. Zhang Filename : draft-ietf-ipngwg-esd-analysis-03.txt Pages : 50 Date : 20-Nov-98 On February 27-28, 1997, the IPng Working Group held an interim meeting in Palo Alto, California to consider adopting Mike O'Dell's 'GSE - An Alternate Addressing Architecture for IPv6' proposal [GSE]. In GSE, 16-byte IPv6 addresses are split into distinct portions for global routing, local routing and end-point identification. GSE includes the feature of configuring a node internal to a site with only the local routing and end-point identification portions of the address, thus hiding the full address from the node. When such a node generates a packet, only the low-order bytes of the source address are specified; the high-order bytes of the address are filled in by a border router when the packet leaves the site. There is a long history of a vague assertion in certain circles that IPv4 'got it wrong' by treating its addresses simultaneously as locators and identifiers. Despite these claims, however, there was never a complete proposal for a scaleable network protocol which separated the functions. As a result, it wasn't possible to do a serious analysis comparing and contrasting a 'separated' architecture and an 'overloaded' architecture. The GSE proposal serves as a vehicle for just such an analysis, and that is the purpose of this paper. We conclude that an architecture that clearly separates locators and identifiers in addresses introduces new issues and problems that do not have an easy or clear solution. Indeed, the alleged disadvantages of overloading addresses turn out to provide some significant benefits over the non-overloaded approach. 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-esd-analysis-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-esd-analysis-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.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-esd-analysis-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: <19981120173332.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-esd-analysis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-esd-analysis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981120173332.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 Nov 24 11:43:39 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA10603 for ipng-dist; Tue, 24 Nov 1998 11:39:40 -0800 (PST) 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 LAA10596 for ; Tue, 24 Nov 1998 11:39:32 -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 LAA10437 for ; Tue, 24 Nov 1998 11:39:30 -0800 Received: from ux6.sp.cs.cmu.edu (UX6.SP.CS.CMU.EDU [128.2.181.250]) by earth.sun.com (8.9.1/8.9.1) with SMTP id LAA10616 for ; Tue, 24 Nov 1998 11:39:29 -0800 (PST) Received: from localhost by ux6.sp.cs.cmu.edu id aa21604; 24 Nov 98 14:38 EST To: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com From: Dave Johnson Reply-To: Dave Johnson Subject: (IPng 6774) New version of Mobile IPv6 draft Date: Tue, 24 Nov 1998 14:38:37 -0500 Message-ID: <21600.911936317@ux6.sp.cs.cmu.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Last week before the deadline, I submitted a new version of the Internet-Draft for Mobile IP for IPv6 (draft-ietf-mobileip-ipv6-07.txt). Here is the abstract of the draft: This document specifies the operation of mobile computers using IPv6. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines four new IPv6 destination options, including one that MUST be supported in packets received by any node, whether mobile or stationary. I haven't seen an official announcement of the draft yet, but it does appear to now be in the standard IETF directories (at least it looks like its there on ftp.ietf.org). It is also available on my web server for the Monarch Project at CMU. A link to the draft is available from http://www.monarch.cs.cmu.edu/ietf.html . Dave -------------------------------------------------------------------- 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 Nov 24 13:05:26 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA10692 for ipng-dist; Tue, 24 Nov 1998 12:55:09 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id MAA10685 for ; Tue, 24 Nov 1998 12:55:05 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA09991 for ; Tue, 24 Nov 1998 12:54:59 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id MAA15108 for ipng@sunroof.eng.sun.com; Tue, 24 Nov 1998 12:54:37 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA10669 for ; Tue, 24 Nov 1998 12:47:25 -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 MAA27209 for ; Tue, 24 Nov 1998 12:47:25 -0800 Received: from panther.cs.ucla.edu (Panther.CS.UCLA.EDU [131.179.132.23]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA01377 for ; Tue, 24 Nov 1998 12:47:24 -0800 (PST) Received: from rain (Rain.CS.UCLA.EDU [131.179.96.164]) by panther.cs.ucla.edu (8.8.8/UCLACS-4.0) with SMTP id MAA19693 for ; Tue, 24 Nov 1998 12:47:29 -0800 (PST) Date: Tue, 24 Nov 1998 12:47:23 -0800 (PST) From: Yixin Jin X-Sender: yjin@rain To: ipng@sunroof.eng.sun.com Subject: (IPng 6776) IPv6 link local address Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi folks, In IPv6 spec, it only says that link local address should be unique on a single link. There is the possiblity that we can assign the same link-local address to 2 different interfaces in the same node. It really makes some porting work very hard since in IPv4 world, you can use IP address to identify an interface. In IPv6, since link local address is always assigned, it makes prefect sense to use link local address to identify the interface, just like IPv4 does. But if the same link local address is assigned to different interfaces, we have to choose other thing, like interface index/name, to identify the interface. Is there any reason not to force link local address be unqiue in the same node? Thanks a lot Yixin Jin UCLA, Computer Science Dept. -------------------------------------------------------------------- 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 Nov 24 17:06:15 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA10934 for ipng-dist; Tue, 24 Nov 1998 16:58:14 -0800 (PST) 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 QAA10927 for ; Tue, 24 Nov 1998 16:57:50 -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 QAA09641 for ; Tue, 24 Nov 1998 16:57:49 -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 QAA03663 for ; Tue, 24 Nov 1998 16:57:49 -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 QAA20539; Tue, 24 Nov 1998 16:57:47 -0800 (PST) Message-Id: <3.0.5.32.19981124165738.00ae42f0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 24 Nov 1998 16:57:38 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6778) Request for Agenda Topics for Orlando IETF IPng Sessions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPng working group will meet for two sessions at the Orlando IETF. The sessions are: Thursday, December 10 at 1530-1730 Friday, December 11 at 0900-1130 Please send Steve Deering and myself proposed agenda items including topic description and length of time required. Thanks, Bob Hinden / Steve Deering IPng 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 Tue Nov 24 18:58:42 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id SAA11041 for ipng-dist; Tue, 24 Nov 1998 18:55:57 -0800 (PST) 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 SAA11034 for ; Tue, 24 Nov 1998 18:55:48 -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 SAA25377 for ; Tue, 24 Nov 1998 18:55:47 -0800 Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA05442 for ; Tue, 24 Nov 1998 18:55:47 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:220:d8ff:fe00:6f2d]) by shuttle.wide.toshiba.co.jp (8.9.1+IPv6/8.9.0) with ESMTP id LAA06119; Wed, 25 Nov 1998 11:57:48 +0900 (JST) To: vanhoudt@hcoss.uia.ac.be Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6779) Re: receiving Neighbor Ads. In-Reply-To: Your message of "Wed, 18 Nov 1998 13:33:34 +0100 (MET)" <199811181233.NAA24963@hcoss.uia.ac.be> References: <199811181233.NAA24963@hcoss.uia.ac.be> X-Mailer: Mew version 1.93 on Emacs 20.3 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19981125115258R.jinmei@isl.rdc.toshiba.co.jp> Date: Wed, 25 Nov 1998 11:52:58 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-Dispatcher: imput version 980905(IM100) Lines: 26 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 18 Nov 1998 13:33:34 +0100 (MET), >>>>> "Benny.VanHoudt" said: > The last paragraph of this section (7.2.5) starts with > "The above rules ensure that the cache is updated when the ..." > and continues with > "If none of the above apply, ..." > My question is when does none of the above apply ? > If I understood well (which I probably didn't) the Override > flag is clear is such a case, the Target Link-layer address > is present and differs from that one in the cache (and the > reachability state differs from INCOMPLETE). > This can't be correct because this case was dealt with in > one of the paragraphs preceding the one quoted above. My understanding is that "If none of the above apply" is a negation of the condition at the first line of the same paragraph(i.e. either when the Neighbor...). So I think it does not contradict your understanding. JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Nov 24 21:33:20 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id VAA11118 for ipng-dist; Tue, 24 Nov 1998 21:30:07 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id VAA11111 for ; Tue, 24 Nov 1998 21:29:57 -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 VAA29973 for ; Tue, 24 Nov 1998 21:29:57 -0800 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 VAA10482 for ; Tue, 24 Nov 1998 21:29:58 -0800 (PST) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2448.0) id ; Tue, 24 Nov 1998 21:29:57 -0800 Message-ID: <4FD6422BE942D111908D00805F3158DF07222952@RED-MSG-52> From: Brian Zill To: ipng@sunroof.eng.sun.com Subject: (IPng 6780) RE: Problem with "smart" layer 2 switches Date: Tue, 24 Nov 1998 21:29:57 -0800 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, it now looks like I got worried without cause. Thanks everyone for your comments. The problem we observed is now believed to be a physical hardware problem with a particular switch. A replacement switch is working just fine with IPv6 even when its "IGMPv4 snooping" feature is enabled. As Francis points out, it's o.k. for a switch to do this IGMPv4 snooping trick so long as it only blocks multicast addresses in the range allocated to IPv4. The piece of information I had been missing was that the ethernet multicast address space is large enough to have distinct regions for v4 vs. v6 multicast (which it does). So my worry, which Tim also expressed in his followup, had been that the solicited node multicast address space would be too large to easily filter (or rather, NOT filter). The broken hardware we had was exhibiting the behavior of filtering ALL multicast addresses outside of the v4 ones it was explicitly allowing, which as Matt points out, would break a lot of other stuff besides IPv6 (but I suspect we don't run a whole lot of AppleTalk around here :-) So I retract my warning that I know of a vendor shipping a layer 2 switch with a feature that causes the switch to only work with IPv4. This isn't to say they aren't out there, but my existence proof went away. --Brian -----Original Message----- From: Brian Zill [mailto:bzill@microsoft.com] Sent: Wednesday, November 18, 1998 21:59 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 6762) Problem with "smart" layer 2 switches This is a FYI about a problem we ran into recently that I thought might interest others on this list. It's likely to pose a problem with some IPv6 deployments. Our facilities folks just put in a "smart" 10/100 BaseT ethernet switch to service our building. It has a feature that's intended to reduce unnecessary multicast traffic on the individual segments. When this feature is enabled, it doesn't propagate packets for ethernet multicast addresses to all ports on the switch. Instead, it snoops all the incoming ports for IGMP (v4) join messages and only then enables multicast traffic for the port it saw the join on (and even then I believe it only enables traffic to that specific multicast address). Needless to say, this breaks Neighbor Discovery for IPv6. We had a representative from the switch vendor onsite yesterday (an engineer, not a sales/marketing guy), and this was the first he had ever heard of IPv6's multicast requirements. I explained the issue to him, so at least one vendor of such devices is now aware of it. Fortunately, this feature can be disabled on our switch. In talking with our facilities people, I got the impression that these sort of IPv4 centric features are becoming more common on layer 2 switches. So this is one more potential problem to look for when deploying v6. I suppose it could even be a barrier to deployment in environments where the local network manager has become attached to this sort of feature. --Brian -------------------------------------------------------------------- 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 Nov 24 23:00:47 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id WAA11194 for ipng-dist; Tue, 24 Nov 1998 22:56:57 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id WAA11187 for ; Tue, 24 Nov 1998 22:56:45 -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 WAA05867 for ; Tue, 24 Nov 1998 22:56:46 -0800 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 WAA16555 for ; Tue, 24 Nov 1998 22:56:45 -0800 (PST) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W) with ESMTP id PAA22537 for ; Wed, 25 Nov 1998 15:56:44 +0900 (JST) To: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 6781) IETF terminal room IPv6 reachability Date: Wed, 25 Nov 1998 15:56:44 +0900 Message-ID: <22533.911977004@coconut.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just curious: We had IPv6 router in terminal room at the last IETF, which was really good to have. (thanks) Does anybody planning to bring IPv6 router to IETF Orlando? If nobody does, we can try getting some notebook for that. itojun, kame project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 25 00:55:37 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id AAA11319 for ipng-dist; Wed, 25 Nov 1998 00:52:54 -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 AAA11312 for ; Wed, 25 Nov 1998 00:52:41 -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 AAA17271 for ; Wed, 25 Nov 1998 00:52:38 -0800 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id AAA00906 for ; Wed, 25 Nov 1998 00:52:40 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id JAA22614; Wed, 25 Nov 1998 09:52:38 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id JAA19554; Wed, 25 Nov 1998 09:52:37 +0100 (MET) Message-Id: <199811250852.JAA19554@givry.inria.fr> From: Francis Dupont To: Yixin Jin cc: ipng@sunroof.eng.sun.com Subject: (IPng 6782) Re: IPv6 link local address In-reply-to: Your message of Tue, 24 Nov 1998 12:47:23 PST. Date: Wed, 25 Nov 1998 09:52:37 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: In IPv6 spec, it only says that link local address should be unique on a single link. There is the possiblity that we can assign the same link-local address to 2 different interfaces in the same node. It really makes some porting work very hard since in IPv4 world, you can use IP address to identify an interface. In IPv6, since link local address is always assigned, it makes prefect sense to use link local address to identify the interface, just like IPv4 does. But if the same link local address is assigned to different interfaces, we have to choose other thing, like interface index/name, to identify the interface. Is there any reason not to force link local address be unqiue in the same node? => even one can answer that with the new sin6_scope_id a sockaddr_in6 structure in the link-local scope is not ambiguous there are some places where an address alone (ie a struct in6_addr) is used, for instance in the DHCPv6 I-D. Then I agree: we should ban all usages of link local addresses without the interface (then the interface is enough) or make the use of the same link local address on more than one interface "not recommended" (or stronger negative statement). Francis.Dupont@inria.fr -------------------------------------------------------------------- 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 Nov 25 01:19:09 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id BAA11367 for ipng-dist; Wed, 25 Nov 1998 01:16:50 -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 BAA11360 for ; Wed, 25 Nov 1998 01:16:42 -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 BAA19976 for ; Wed, 25 Nov 1998 01:16:40 -0800 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 BAA09298 for ; Wed, 25 Nov 1998 01:16:40 -0800 (PST) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W) with ESMTP id SAA24045; Wed, 25 Nov 1998 18:16:18 +0900 (JST) To: Francis Dupont cc: ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Wed, 25 Nov 1998 09:52:37 +0100. <199811250852.JAA19554@givry.inria.fr> 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 6783) Re: IPv6 link local address Date: Wed, 25 Nov 1998 18:16:18 +0900 Message-ID: <24041.911985378@coconut.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In IPv6 spec, it only says that link local address should be unique on a > single link. There is the possiblity that we can assign the same > link-local address to 2 different interfaces in the same node. > > It really makes some porting work very hard since in IPv4 world, you can > use IP address to identify an interface. > > In IPv6, since link local address is always assigned, it makes prefect > sense to use link local address to identify the interface, just like IPv4 > does. But if the same link local address is assigned to different > interfaces, we have to choose other thing, like interface index/name, to > identify the interface. > > Is there any reason not to force link local address be unqiue in the same > node? >=> even one can answer that with the new sin6_scope_id a sockaddr_in6 >structure in the link-local scope is not ambiguous there are some places >where an address alone (ie a struct in6_addr) is used, for instance >in the DHCPv6 I-D. Then I agree: we should ban all usages of link local >addresses without the interface (then the interface is enough) or >make the use of the same link local address on more than one interface >"not recommended" (or stronger negative statement). Even if we make sure the above, we're in the trap if your node has two interfaces and incidentally same interface ID appears on the both side. We can't prevent this from happening by the above restriction. somehost1 | fe80::x <--- oops ==+=== | fe80::y your host | fe80::z ==+=== | fe80::x <--- oops somehost2 KAME implementation annotates link-local addresses by interface index, in the kernel structures only (such as routing tables), like: if ne0 interface has interface index of 3, then fe80::x on ne0 interface will appear as fe80:3::x on routing table. In this way there is no ambiguity in the addresses visible to the kernel code. somehost1 | fe80:1::x ==+=== | fe80:1::y ifindex=1 your host | fe80:2::z ifindex=2 ==+=== | fe80:2::x somehost2 Userland program sees standard link-local address (fe80::x) only. If userland program needs interface index, the program should use advanced API. Also, the embedded interface index will never appear on the wire. It is too hard to use sockaddr_in6 structure throughout the kernel, due to the following reasons: - It requires too many changes in the kernel... - We usually do not pass source and destination address to ip6_output() as separate argument. They are in the IPv6 header part, and there's no place to embed sockaddr_in6 structure in struct ip6_hdr. Interface index must be embedded somewhere in ip6->ip6_src. 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 Nov 25 01:46:55 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id BAA11424 for ipng-dist; Wed, 25 Nov 1998 01:43:52 -0800 (PST) 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 BAA11413 for ; Wed, 25 Nov 1998 01:43:39 -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 BAA23221 for ; Wed, 25 Nov 1998 01:43:38 -0800 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 BAA19333 for ; Wed, 25 Nov 1998 01:43:37 -0800 (PST) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W) with ESMTP id SAA24501 for ; Wed, 25 Nov 1998 18:43:36 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Wed, 25 Nov 1998 18:16:18 JST. <24041.911985378@coconut.itojun.org> 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 6784) Re: IPv6 link local address From: Jun-ichiro itojun Itoh Date: Wed, 25 Nov 1998 18:43:36 +0900 Message-ID: <24498.911987016@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>=> even one can answer that with the new sin6_scope_id a sockaddr_in6 >>structure in the link-local scope is not ambiguous there are some places >>where an address alone (ie a struct in6_addr) is used, for instance >>in the DHCPv6 I-D. Then I agree: we should ban all usages of link local >>addresses without the interface (then the interface is enough) or >>make the use of the same link local address on more than one interface >>"not recommended" (or stronger negative statement). Oops, forgot to mention this: You can safely guess the interface index for link-local address in dhcpv6 packet, by interface index for inbound interface. dhcpv6 server must use advanced API. (sorry if I'm mistaking something) itojun -------------------------------------------------------------------- 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 Nov 25 07:09:55 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA11750 for ipng-dist; Wed, 25 Nov 1998 06:58:16 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA11743 for ; Wed, 25 Nov 1998 06:58:02 -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 GAA02108 for ; Wed, 25 Nov 1998 06:58:01 -0800 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA27101 for ; Wed, 25 Nov 1998 06:57:59 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id PAA01498; Wed, 25 Nov 1998 15:57:56 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id PAA31912; Wed, 25 Nov 1998 15:57:56 +0100 (MET) Message-Id: <199811251457.PAA31912@givry.inria.fr> From: Francis Dupont To: Jun-ichiro itojun Itoh cc: ipng@sunroof.eng.sun.com Subject: (IPng 6785) Re: IPv6 link local address In-reply-to: Your message of Wed, 25 Nov 1998 18:43:36 +0900. <24498.911987016@coconut.itojun.org> Date: Wed, 25 Nov 1998 15:57:55 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Oops, forgot to mention this: You can safely guess the interface index for link-local address in dhcpv6 packet, by interface index for inbound interface. dhcpv6 server must use advanced API. (sorry if I'm mistaking something) => the problem is in the relay (but the address is "a non-link-local address of its interface" where the client is then it is not exactly the same problem (but still "an address gives not an interface" issue). Francis.Dupont@inria.fr -------------------------------------------------------------------- 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 Nov 25 08:29:33 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA11935 for ipng-dist; Wed, 25 Nov 1998 08:26:36 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA11928 for ; Wed, 25 Nov 1998 08:26:25 -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 IAA24335 for ; Wed, 25 Nov 1998 08:26:25 -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 IAA21496 for ; Wed, 25 Nov 1998 08:26:24 -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 IAA14228 for ; Wed, 25 Nov 1998 08:26:21 -0800 (PST) Message-Id: <3.0.5.32.19981125081734.035de6f0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 25 Nov 1998 08:17:34 -0800 To: ipng@sunroof.eng.sun.com From: The IESG (by way of Bob Hinden ) Subject: (IPng 6786) Protocol Action: IPv6 over Non-Broadcast Multiple Access (NBMA) networks to Proposed Standard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved publication of the following Internet-Drafts as Proposed Standards: o IPv6 over Non-Broadcast Multiple Access (NBMA) networks o IPv6 over ATM Networks These documents are the product of the Internetworking Over NBMA Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary The document "IPv6 over Non-Broadcast Multiple Access (NBMA) networks" provides a framework for how to run IPv6 over NBMA link types (e.g., ATM, Frame Relay, etc.). It provides a basis for companion documents (e.g., "IPv6 over ATM Networks") to define specific items that are by their nature link-layer specific. The first document also defines how a client can use use Neighbor Discovery to request NBMA shortcuts (i.e., to initiate NHRP services). The MARS model is assumed, allowing Neighbor Discovery to be used (Neighbor Discovery assumes multicast is available on a specific link-layer.) The two documents together define how to run IPv6 over ATM networks for both SVCs and PVCs. Working Group Summary There was consenus in the WG for this approach, and no issues were raised during the Last Call. Protocol Quality This specification has been reviewed for the IESG by Thomas Narten and Jeffrey Burgan. -------------------------------------------------------------------- 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 Nov 25 08:59:31 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA11999 for ipng-dist; Wed, 25 Nov 1998 08:56:20 -0800 (PST) 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 IAA11992 for ; Wed, 25 Nov 1998 08:56:11 -0800 (PST) From: Volsinians@aol.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 IAA26731 for ; Wed, 25 Nov 1998 08:56:08 -0800 Received: from imo12.mx.aol.com (imo12.mx.aol.com [198.81.17.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA12654 for ; Wed, 25 Nov 1998 08:56:05 -0800 (PST) Received: from Volsinians@aol.com by imo12.mx.aol.com (IMOv16.10) id PFUFa03115; Wed, 25 Nov 1998 11:55:29 -0500 (EST) Message-ID: <9d418154.365c3681@aol.com> Date: Wed, 25 Nov 1998 11:55:29 EST To: yjin@CS.UCLA.EDU Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6787) Re: IPv6 link local address Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 236 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 11/24/98 4:24:57 PM Eastern Standard Time, yjin@CS.UCLA.EDU writes: > In IPv6 spec, it only says that link local address should be unique on a > single link. There is the possiblity that we can assign the same > link-local address to 2 different interfaces in the same node. > It really makes some porting work very hard since in IPv4 world, you can > use IP address to identify an interface. > In IPv6, since link local address is always assigned, it makes prefect > sense to use link local address to identify the interface, just like IPv4 > does. But if the same link local address is assigned to different > interfaces, we have to choose other thing, like interface index/name, to > identify the interface. > Is there any reason not to force link local address be unqiue in the same > node? Then the addresses would not be link local but would rather perhaps be a species of node unique. In any case the implementation seems misarchitected, it might make perfect sense to have the exact same link local address on every network to which a host connects -- perhaps a resonably way to deal with resources that must be accessed before routing is turned on. It is incorrect to tailor a protocol specification to specific hardware or software inadequacies. Joachim Martillo Telford Tools, 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 Nov 25 09:02:46 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA12020 for ipng-dist; Wed, 25 Nov 1998 09:00:54 -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 JAA12013 for ; Wed, 25 Nov 1998 09:00:41 -0800 (PST) From: Volsinians@aol.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 JAA28262 for ; Wed, 25 Nov 1998 09:00:38 -0800 Received: from imo14.mx.aol.com (imo14.mx.aol.com [198.81.17.4]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA15616 for ; Wed, 25 Nov 1998 09:00:38 -0800 (PST) Received: from Volsinians@aol.com by imo14.mx.aol.com (IMOv16.10) id BINIa26092; Wed, 25 Nov 1998 11:59:53 -0500 (EST) Message-ID: <114befd0.365c3789@aol.com> Date: Wed, 25 Nov 1998 11:59:53 EST To: Francis.Dupont@inria.fr, yjin@cs.ucla.edu Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6788) Re: IPv6 link local address Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 236 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 11/25/98 4:11:43 AM Eastern Standard Time, Francis.Dupont@inria.fr writes: > => even one can answer that with the new sin6_scope_id a sockaddr_in6 > structure in the link-local scope is not ambiguous there are some places > where an address alone (ie a struct in6_addr) is used, for instance > in the DHCPv6 I-D. Then I agree: we should ban all usages of link local > addresses without the interface (then the interface is enough) or > make the use of the same link local address on more than one interface > "not recommended" (or stronger negative statement). About as wrong a suggestion as one could image. Joachim Martillo Telford Tools, 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 Nov 25 10:07:39 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA12192 for ipng-dist; Wed, 25 Nov 1998 09:58:17 -0800 (PST) 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 JAA12185 for ; Wed, 25 Nov 1998 09:58:06 -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 JAA08018 for ; Wed, 25 Nov 1998 09:58:05 -0800 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 JAA25139 for ; Wed, 25 Nov 1998 09:58:04 -0800 (PST) Received: by mail1.microsoft.com with Internet Mail Service (5.5.2448.0) id ; Wed, 25 Nov 1998 09:58:03 -0800 Message-ID: <4FD6422BE942D111908D00805F3158DF07222954@RED-MSG-52> From: Brian Zill To: ipng@sunroof.eng.sun.com Subject: (IPng 6789) RE: IPv6 link local address Date: Wed, 25 Nov 1998 09:58:01 -0800 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Yixin Jin [mailto:yjin@CS.UCLA.EDU] > > Is there any reason not to force link local address be unqiue in the same > node? Let me turn that around. Is there any reason TO force link local addresses to be unique in the same node? A specification such as this shouldn't be restrictive without a good reason. There are other (and more appropriate) ways to identify an interface (numbered ids, names, etc), so I don't see a need to make this restriction. If something isn't needed for interoperability or correct operation, than it should be left to implementation choice, I would think. --Brian -------------------------------------------------------------------- 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 Nov 25 11:27:53 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA12462 for ipng-dist; Wed, 25 Nov 1998 11:24:59 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA12455 for ; Wed, 25 Nov 1998 11:24:41 -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 LAA17652 for ; Wed, 25 Nov 1998 11:24:40 -0800 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA26369 for ; Wed, 25 Nov 1998 11:24:39 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id UAA06552; Wed, 25 Nov 1998 20:24:18 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id UAA30331; Wed, 25 Nov 1998 20:24:18 +0100 (MET) Message-Id: <199811251924.UAA30331@givry.inria.fr> From: Francis Dupont To: Volsinians@aol.com cc: yjin@cs.ucla.edu, ipng@sunroof.eng.sun.com Subject: (IPng 6790) Re: IPv6 link local address In-reply-to: Your message of Wed, 25 Nov 1998 11:55:29 EST. <9d418154.365c3681@aol.com> Date: Wed, 25 Nov 1998 20:24:18 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: In any case the implementation seems misarchitected, it might make perfect sense to have the exact same link local address on every network to which a host connects -- perhaps a resonably way to deal with resources that must be accessed before routing is turned on. It is incorrect to tailor a protocol specification to specific hardware or software inadequacies. => it is not the question. The problem is many existing applications make the wrong statement then an address can designate one interface. The link-local stuff makes it even more wrong then: - we can change the link-local stuff (but this can't fix the wrong assumption) - we can verify if APIs give the good tools (it is the real object of the discussion for me) - we can verify if the wrong assumption is not in some specs (I believe it is the case for a detail in DHCPv6) The result should be a recommendation about link-local stuff or better (because it can fix the deep problem) about how to designate an interface on and outside a node. I put the two "solutions" because I believe it is a real problem and a short sentence saying "no we'll keep the link-local as it" is not an answer (ie say no to a proposed solution not to the problem :-). Francis.Dupont@inria.fr -------------------------------------------------------------------- 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 Nov 25 12:41:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA12579 for ipng-dist; Wed, 25 Nov 1998 12:29:59 -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 MAA12572 for ; Wed, 25 Nov 1998 12:29:46 -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 MAA25546 for ; Wed, 25 Nov 1998 12:29:39 -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 MAA12039 for ; Wed, 25 Nov 1998 12:29:40 -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 MAA25760; Wed, 25 Nov 1998 12:29:38 -0800 (PST) Message-Id: <3.0.5.32.19981125122926.00b13dc0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 25 Nov 1998 12:29:26 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6791) Implementation report for Addressing Specifications Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It is time to start collecting implementation information for RFC2373 and RFC2374 in order to move them to Draft Standard. If you have an IPv6 implementation please fill this out and send it to me. I will combine the information. Thanks, Bob ____________cut here_________________________________________________ Implementation Report for RFC2373 IP Version 6 Addressing Architecture RFC2374 An Aggregatable Global Unicast Address Format ------------------------------------------------------------ Name of Implementation: Platform: Organization: Information from: Origin of Code: Features Implemented: All Nodes: Text Representation Unspecified Address Loopback Address EUI-64 Interface Identifiers Aggregatable Global Unicast Addresses Site-Local Addresses Link-Local Addresses All-Nodes Multicast Addresses Solicited-Node Multicast Address Routers only: Subnet-Router Anycast Address All-Routers Multicast Address Tested Interoperability by Feature: All Nodes: Text Representation Unspecified Address Loopback Address EUI-64 Interface Identifiers Aggregatable Global Unicast Addresses Site-Local Addresses Link-Local Addresses All-Nodes Multicast Addresses Solicited-Node Multicast Address Routers only: Subnet-Router Anycast Address All-Routers Multicast Address -------------------------------------------------------------------- -------------------------------------------------------------------- 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 Nov 25 12:59:18 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA12605 for ipng-dist; Wed, 25 Nov 1998 12:47:51 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA12598 for ; Wed, 25 Nov 1998 12:47:33 -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 MAA29292 for ; Wed, 25 Nov 1998 12:47:32 -0800 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA23207 for ; Wed, 25 Nov 1998 12:47:32 -0800 (PST) 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 MAA06655; Wed, 25 Nov 1998 12:47:23 -0800 (PST) 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 MAA93315; Wed, 25 Nov 1998 12:47:22 -0800 (PST) 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 MAA20256; Wed, 25 Nov 1998 12:47:21 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199811252047.MAA20256@bossette.engr.sgi.com> Subject: (IPng 6792) Re: IPv6 link local address To: Francis.Dupont@inria.fr (Francis Dupont) Date: Wed, 25 Nov 1998 12:47:21 -0800 (PST) Cc: Volsinians@aol.com, yjin@cs.ucla.edu, ipng@sunroof.eng.sun.com In-Reply-To: <199811251924.UAA30331@givry.inria.fr> from "Francis Dupont" at Nov 25, 98 08:24:18 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 Francis Dupont wrote: > => it is not the question. The problem is many existing applications > make the wrong statement then an address can designate one interface. But I believe a sockaddr_in6, as currently defined, _can_ uniquely designate one interface. > The link-local stuff makes it even more wrong then: > - we can change the link-local stuff (but this can't fix the > wrong assumption) > - we can verify if APIs give the good tools (it is the real object > of the discussion for me) > - we can verify if the wrong assumption is not in some specs > (I believe it is the case for a detail in DHCPv6) > The result should be a recommendation about link-local stuff or > better (because it can fix the deep problem) about how to designate > an interface on and outside a node. I put the two "solutions" because > I believe it is a real problem and a short sentence saying "no we'll > keep the link-local as it" is not an answer (ie say no to a proposed > solution not to the problem :-). Your argument also applies to site-local addresses, I think. I would also like to see more discussion on this topic. The whole question as to how one should identify sites on multi-sited nodes (and I'm not talking about scope_ids), remains a grey area for me. The naive questions I posted to this list on this subject a few weeks back met with deathly silence. I haven't yet worked out if they were simply too stupid to warrant a reply or if nobody knows the answers ;-) -- 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 Nov 25 15:28:49 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA12834 for ipng-dist; Wed, 25 Nov 1998 15:25:18 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id PAA12827 for ; Wed, 25 Nov 1998 15:25:07 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id PAA12076; Wed, 25 Nov 1998 15:25:01 -0800 (PST) Date: Wed, 25 Nov 1998 15:24:02 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6794) Re: IPv6 link local address To: Jun-ichiro itojun Itoh Cc: Francis Dupont , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <24041.911985378@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Userland program sees standard link-local address (fe80::x) only. > If userland program needs interface index, the program should use > advanced API. Also, the embedded interface index will never appear > on the wire. Presumably the userland program can use sin6_scope_id as well and you can have the kernel use the internal representation of your own choice. My point is that the advanced API shouldn't be required. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 25 15:29:21 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA12812 for ipng-dist; Wed, 25 Nov 1998 15:21:04 -0800 (PST) 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 PAA12805 for ; Wed, 25 Nov 1998 15:20:53 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id PAA11573; Wed, 25 Nov 1998 15:20:49 -0800 (PST) Date: Wed, 25 Nov 1998 15:19:50 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6793) Re: IPv6 link local address To: Yixin Jin Cc: ipng@sunroof.eng.sun.com 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 > In IPv6 spec, it only says that link local address should be unique on a > single link. There is the possiblity that we can assign the same > link-local address to 2 different interfaces in the same node. > > It really makes some porting work very hard since in IPv4 world, you can > use IP address to identify an interface. That isn't really true in the IPv4 world since many implementations support the notion of unnumbered pt-pt links. For example this is what I can have on Solaris: lo0: flags=1000849 mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 le0: flags=1000843 mtu 1500 index 2 inet 129.146.86.131 netmask ffffff00 broadcast 129.146.86.255 ipdptp0: flags=10028d1 mtu 8232 index 5 inet 129.146.86.131 --> 1.2.3.4 netmask ffff0000 ipdptp1: flags=10028d1 mtu 8232 index 6 inet 129.146.86.131 --> 2.3.4.5 netmask ffff0000 This is part of the reason the IPv6 API is using interface indicies to identify interfaces (for IPV6_MULTICAST_IF etc) since those are always unique. > In IPv6, since link local address is always assigned, it makes prefect > sense to use link local address to identify the interface, just like IPv4 > does. But if the same link local address is assigned to different > interfaces, we have to choose other thing, like interface index/name, to > identify the interface. Which is what the API already requires. Do you have an example of applications where this becomes terribly hard to do? > Is there any reason not to force link local address be unqiue in the same > node? That would require that all Ethernet cards on a machine have a unique MAC address which has not been true for all implementations. For instance, it is not until recently that Sun has started supplying unique MAC addresses for each card. Without rat-holing into the historical discussion, this is due to the Ethernet spec talking about "stations" having a unique Ethernet address and some early protocols (XNS I believe) assumed that all cards on a station had the same MAC address. Thus we don't want to require unique Ethernet addresses for all cards. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 25 15:47:08 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA12876 for ipng-dist; Wed, 25 Nov 1998 15:37:44 -0800 (PST) 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 PAA12869 for ; Wed, 25 Nov 1998 15:37:33 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id PAA13390; Wed, 25 Nov 1998 15:37:26 -0800 (PST) Date: Wed, 25 Nov 1998 15:36:28 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6795) Re: scope_id questions To: Sam Manthorpe Cc: Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com, sm@cthulhu.engr.sgi.com In-Reply-To: "Your message with ID" <199811132134.NAA40790@bossette.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry for the slow response. > If we are considering a multi-sited host then aren't we actually talking > about a router rather than a host? I don't think we want to require that all multi-sited nodes be routers. It might make sense to have large multihomed servers that actually serve multiple sites (for instance when a some service is outsourced to an ISP the ISP might run a single server for multiple sites.) > > > Thus a router would now that "this site has the > > prefixes 1:2::0/48 and 2:4::0/48" and a router in another site would > > be configured with "site prefix 9:9::0/48". A host connected to both routers > > can determine that they are different sites since the site-prefixes are > > different. > > Okay, I'm confused. Are you saying that part or all of the subnet ID > can be used to distinguish between sites? Surely not. I don't see > any reason why the host connected to both sites can't receive exactly > the same subnet IDs from both routers (using your scheme), even though > they come from different sites. Surely, I, wearing my site-administrator > hat, am allowed to allocate my subnet-ID address space however I chose, > and my neighbouring site-admin is free to do the same. Taking your model > (where a host is connected to multiple sites rather than a router being > connected to multiple sites): No, I'm saying that the first bits (often 48 of them in the current address allocation scheme: TLA + NLA(s)) of the global addresses can identify the sites - this is what I call the "site prefix" in the draft. Two different sites will have different TLA + NLA(s) prefixes. The site-local addresses can of course be the same. > > site A site B > |----------------| |-----------------| > > r1 ------------- h1 -------------- r2 > if_0 if_1 > fec0:0:0:1::1 fec0:0:0:1::2 Add global addrs: 1:2:0:1:1 2:4:0:1::2 > Host h1 is connected to site A on interface if_0 and to site B on > interface if_1. The subnet to which if_0 is connected has a subnet > ID of 1 (on site A) and the subnet to which if_1 is connected also > has a subnet ID of 1 (on site B), which is okay because each interface > belongs to a different scope. Host h1, however, must be aware that > the two belong to different sites. Among other things, it must > not forward packets from site A to site B. > > If subnet IDs must be globally unique, as you are suggesting, then > what's the difference between site-local and global addresses? I didn't suggest that. > > Thus the actual ids can be assigned serially at boot just like the > > interface indicies. > > No, because that would force each interface to belong to a different > site, which isn't what I want. The allocation of interface to site > seems to me to be a sysadmin decision. Sorry for being unclear. What I meant to say was that when the addrconf daemon detect (using the mechanism suggested in draft-ietf-ipngwg-site-prefixes) that it is connected to different sites it can pick serial numbers 1,2,3 etc to identify the sites. Thus initially all interfaces are considered to be in site id #1. When it detects that some interfaces have different site-prefixes it can declare those to be in site id #2. The point is that the site id is just a locally significant identifier that doesn't have to be stable across reboots (just like the interface index). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 25 17:38:25 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA13010 for ipng-dist; Wed, 25 Nov 1998 17:24:43 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id RAA13003 for ; Wed, 25 Nov 1998 17:24:39 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA24884 for ; Wed, 25 Nov 1998 17:24:36 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id RAA17089 for ipng@sunroof.eng.sun.com; Wed, 25 Nov 1998 17:24:12 -0800 (PST) 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 RAA12990 for ; Wed, 25 Nov 1998 17:19:55 -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 RAA11047; Wed, 25 Nov 1998 17:19:52 -0800 Received: from panther.cs.ucla.edu (Panther.CS.UCLA.EDU [131.179.132.23]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA23687; Wed, 25 Nov 1998 17:19:52 -0800 (PST) Received: from rain (Rain.CS.UCLA.EDU [131.179.96.164]) by panther.cs.ucla.edu (8.8.8/UCLACS-4.0) with SMTP id RAA05589; Wed, 25 Nov 1998 17:19:58 -0800 (PST) Date: Wed, 25 Nov 1998 17:19:51 -0800 (PST) From: Yixin Jin X-Sender: yjin@rain To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: (IPng 6797) Re: IPv6 link local address In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > That isn't really true in the IPv4 world since many implementations support > the notion of unnumbered pt-pt links. For example this is what I can > have on Solaris: > lo0: flags=1000849 mtu 8232 index 1 > inet 127.0.0.1 netmask ff000000 > le0: flags=1000843 mtu 1500 index 2 > inet 129.146.86.131 netmask ffffff00 broadcast 129.146.86.255 > ipdptp0: flags=10028d1 mtu 8232 > index 5 > inet 129.146.86.131 --> 1.2.3.4 netmask ffff0000 > ipdptp1: flags=10028d1 mtu 8232 > index 6 > inet 129.146.86.131 --> 2.3.4.5 netmask ffff0000 OK, it is a good example. Actually, gated with dvmrp is another example. Then it is dealing with physical interface, it uses IP address. But when it is dealing with tunnels, it uses index. > > Do you have an example of applications where this becomes terribly hard to > do? gated. I think the reason that there are many applications in IPv4 world using IP address identifying interface is that it works most of the time. But it won't be true in IPv6 world. Anyway, it just makes porting work harder, not for brand new applications. Thanks Yixin -------------------------------------------------------------------- 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 Nov 25 17:49:21 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA13049 for ipng-dist; Wed, 25 Nov 1998 17:37:41 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA13042 for ; Wed, 25 Nov 1998 17:37:25 -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 RAA05885; Wed, 25 Nov 1998 17:37:22 -0800 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 RAA10238; Wed, 25 Nov 1998 17:37:22 -0800 (PST) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W) with ESMTP id KAA05852; Thu, 26 Nov 1998 10:37:20 +0900 (JST) To: Erik Nordmark cc: ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Wed, 25 Nov 1998 15:24:02 PST. 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 6798) Re: IPv6 link local address Date: Thu, 26 Nov 1998 10:37:20 +0900 Message-ID: <5849.912044240@coconut.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Userland program sees standard link-local address (fe80::x) only. >> If userland program needs interface index, the program should use >> advanced API. Also, the embedded interface index will never appear >> on the wire. >Presumably the userland program can use sin6_scope_id as well and you can >have the kernel use the internal representation of your own choice. >My point is that the advanced API shouldn't be required. sin6_scope_id will be filled by our kernel too. sorry for many mistakes in the previous email. itojun -------------------------------------------------------------------- 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 Nov 28 10:16:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA14211 for ipng-dist; Sat, 28 Nov 1998 10:04:24 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA14204 for ; Sat, 28 Nov 1998 10:04:11 -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 KAA03912; Sat, 28 Nov 1998 10:04:09 -0800 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 KAA15240; Sat, 28 Nov 1998 10:04:06 -0800 (PST) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W) with ESMTP id DAA22362; Sun, 29 Nov 1998 03:03:49 +0900 (JST) To: Erik Nordmark cc: ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Wed, 11 Nov 1998 15:00:45 PST. 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 6801) Re: Site prefixes? Date: Sun, 29 Nov 1998 03:03:49 +0900 Message-ID: <22358.912276229@coconut.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry for delayed reply, >> Requiring two-faced DNS to a site that uses site-local address is >> much easier to implement. If two-faced DNS is a common practice, >> someone may implement a tool that makes it easier to deploy. >> (example: bind8 is much useful than bind4 for firewall border) >Others have argued strongly against requiring a two-faced DNS for every site. >True that they might not be too hard to administer for large sites (like >large corporations) but I don't see small sites (like households) >ever doing this. Really? I believe every firewalled sites (regardles from its size) does this. Some of them use pseudo top-level domain name (maintain "foo.com." and "foo.com.private." and add "private." to the search list in host in the site), but basically they manage to do this. >So how can we resolve this issue? Any good ideas out there? I feel two points are unsafe about the current draft: 1. requires all implementations to ignore site-local addresses on the DNS database. how about those product that has already been shipped? I believe Jim Bound has something to say about this...:-P 2. this draft is just for site local addresses. what about other scoped addresses that will be defined in the future? My alternative solutions are: a. Require two-faced DNS server for every site. Large sites with full-time admin person should be happy with this. b. Implement address filter functionality into named. For specific interfaces, filter out AAAA records that matches specific prefix. For example, "filter out fec0::/10 for interface le0" removes AAAA records that matches fec0::/10, from the result. By this way we can configure single named to behave as two-faced DNS server. Filtering function can also be implemented as separate program, of course. -> effects on cache? (it should be the same as two-faced DNS) c. Register (virtual) global address to DNS server. redistribute rewriting rule (from global to site-local) by using RA, just like site-prefix information option. For example: 3ffe:0501:0410::/48 -> fec0::/48 A node supporting this option should contact the addresses that have been rewrote first, then the address got from DNS server. If a node got the following record from DNS, foo.baa.com. IN AAAA 3ffe:0501:0410::x IN AAAA 3ffe:0501:0499::x the node should contact fec0::x first, then 3ffe:0501:0410::x 3ffe:0501:0499::x. By this way, no old implementations will be harmed. Old implementations will contact 3ffe:0501:0410::x or 3ffe:0501:0499::x, and will success or fail based on the topology/ configuration. It is a rewriting rule for prefix so it can be used for future (non-site) scoped address. This approach require global address prefixes to be (virtually) assigned to all subnets in the site. Virtually assigning global prefixes to a large site is hard, but large site will use approach (a). Small sites have no problem assigning global prefixes to subnets. If you think (c) to be possible, I'll investigate this approach in more detail. itojun@kame.net jun-ichiro itoh --- very basic "rewriting rule" option format (tentative) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime of mapping | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + rewrite-from prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + rewrite-to prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------------------------------------------------------------------- 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 Nov 29 18:52:28 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id SAA14551 for ipng-dist; Sun, 29 Nov 1998 18:39:58 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id SAA14544 for ; Sun, 29 Nov 1998 18:39:39 -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 SAA18880; Sun, 29 Nov 1998 18:39:32 -0800 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 SAA00165; Sun, 29 Nov 1998 18:39:32 -0800 (PST) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W) with ESMTP id LAA16168; Mon, 30 Nov 1998 11:39:20 +0900 (JST) To: Erik Nordmark , ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Sun, 29 Nov 1998 03:03:49 JST. <22358.912276229@coconut.itojun.org> 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 6802) Re: Site prefixes? From: Jun-ichiro itojun Itoh Date: Mon, 30 Nov 1998 11:39:20 +0900 Message-ID: <16165.912393560@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > c. Register (virtual) global address to DNS server. redistribute > rewriting rule (from global to site-local) by using RA, just > like site-prefix information option. For example: > 3ffe:0501:0410::/48 -> fec0::/48 I was wrong. the old draft (-00 and -01) used rewriting rule. like I wrote. Sorry for confusion. I personally prefer (1) two-faced DNS, or (2) use something like dnsind-local-names-06. itojun -------------------------------------------------------------------- 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 Nov 30 08:05:45 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA15219 for ipng-dist; Mon, 30 Nov 1998 07:57:12 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA15212 for ; Mon, 30 Nov 1998 07:57:04 -0800 (PST) From: trawick@us.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 HAA00219 for ; Mon, 30 Nov 1998 07:57:04 -0800 Received: from smtp4.ny.us.ibm.COM (smtp4.ny.us.ibm.com [198.133.22.43]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA25434 for ; Mon, 30 Nov 1998 07:56:58 -0800 (PST) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.117.200.23]) by smtp4.ny.us.ibm.COM (8.8.7/8.8.7) with ESMTP id KAA72860 for ; Mon, 30 Nov 1998 10:43:38 -0500 Received: from us.ibm.com (d54mta05.raleigh.ibm.com [9.67.228.37]) by northrelay03.pok.ibm.com (8.8.7/NCO v1.5) with SMTP id KAA129632 for ; Mon, 30 Nov 1998 10:56:30 -0500 Received: by us.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 852566CC.00578DFA ; Mon, 30 Nov 1998 10:56:19 -0500 X-Lotus-FromDomain: IBMUS To: ipng@sunroof.eng.sun.com Message-ID: <852566CC.00578A93.00@us.ibm.com> Date: Mon, 30 Nov 1998 10:56:03 -0500 Subject: (IPng 6805) IPv6 basic API draft (draft-ietf-ipngwg-bsd-api-new-04.txt) and AI_DEFAULT Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Shouldn't AI_DEFAULT be listed in "7. Summary of New Definitions" ? Can this minor editing change be made at this late date? Also, does anyone else know of stuff missing from the summary? Thanks and best wishes, Jeff Trawick trawick@us.ibm.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 Nov 30 09:37:41 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA15342 for ipng-dist; Mon, 30 Nov 1998 09:33:46 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA15335 for ; Mon, 30 Nov 1998 09:33:38 -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 JAA14388 for ; Mon, 30 Nov 1998 09:33:37 -0800 Received: from omriconceti.cmpe.boun.edu.tr (omriconceti.cmpe.boun.edu.tr [193.140.196.220]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA00508 for ; Mon, 30 Nov 1998 09:33:34 -0800 (PST) Received: from cmpe.boun.edu.tr (IDENT:1000@localhost [127.0.0.1]) by omriconceti.cmpe.boun.edu.tr (8.9.1/8.9.0) with ESMTP id TAA00749 for ; Mon, 30 Nov 1998 19:32:03 +0200 Message-ID: <3662D693.82417D51@cmpe.boun.edu.tr> Date: Mon, 30 Nov 1998 19:32:03 +0200 From: Emre Celebi Organization: Bogazici University X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.34 i586) X-Accept-Language: Turkish, tr MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 6806) ipng perf References: <199811301726.JAA15314@sunroof.eng.sun.com> Content-Type: multipart/alternative; boundary="------------3C203997233915F2F8A4EE39" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --------------3C203997233915F2F8A4EE39 Content-Type: text/plain; charset=iso-8859-9 Content-Transfer-Encoding: 7bit Does anyone know where I can find ipng performance results or ipv6/ipv4 performance comparison? Emre. -- Emre Celebi, Bogazici University CmpE Department Network Research Laboratories. Research assitant. Phone:+90 212 2631540 ext 2227 | Mobile: +90 532 4855536 http://yunus.cmpe.boun.edu.tr/~emre --------------3C203997233915F2F8A4EE39 Content-Type: text/html; charset=iso-8859-9 Content-Transfer-Encoding: 7bit  
Does anyone know where I can find ipng performance results or ipv6/ipv4 performance comparison?
Emre.

--

Emre Celebi, Bogazici University CmpE Department
Network Research Laboratories. Research assitant.
Phone:+90 212 2631540 ext 2227 | Mobile: +90 532 4855536
http://yunus.cmpe.boun.edu.tr/~emre

 

  --------------3C203997233915F2F8A4EE39-- -------------------------------------------------------------------- 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 Nov 30 10:40:59 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA15507 for ipng-dist; Mon, 30 Nov 1998 10:30:39 -0800 (PST) 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 KAA15500 for ; Mon, 30 Nov 1998 10:30:30 -0800 (PST) Received: (from danmcd@localhost) by kebe.eng.sun.com (8.9.1b+Sun/8.9.0) id KAA08169; Mon, 30 Nov 1998 10:30:11 -0800 (PST) From: Dan McDonald Message-Id: <199811301830.KAA08169@kebe.eng.sun.com> Subject: (IPng 6807) Re: ipng perf To: emre@cmpe.boun.edu.tr (Emre Celebi) Date: Mon, 30 Nov 1998 10:30:11 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3662D693.82417D51@cmpe.boun.edu.tr> from "Emre Celebi" at Nov 30, 98 07:32:03 pm 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 > Does anyone know where I can find ipng performance results or ipv6/ipv4 > performance comparison? > Emre. I can point you at the paper we did at NRL (back when I was at NRL). It's from the January, 1996 USENIX, and while it talks more about implementation, it does have some preliminary performance results: Atkinson, R. J., McDonald, D. L., Phan, B. G., Metz, C. W., Chin, K. C., "Implementation of IPv6 in 4.4 BSD," in Proceedings of the USENIX 1996 Annual Technical Conference, San Diego, January, 1996. Keep in mind, the numbers in that paper are preliminary, and I suspect that the difference between v4 and v6 has slimmed, especially with bigger cache lines, etc. that are in more recent machines. 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 Nov 30 11:11:25 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA15581 for ipng-dist; Mon, 30 Nov 1998 11:02:28 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA15574 for ; Mon, 30 Nov 1998 11:02:19 -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 LAA02414; Mon, 30 Nov 1998 11:02:12 -0800 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA03641; Mon, 30 Nov 1998 11:02:09 -0800 (PST) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.1/8.9.1) with ESMTP id SAA25313; Mon, 30 Nov 1998 18:50:41 GMT Message-Id: <199811301850.SAA25313@inner.net> To: Dan McDonald cc: emre@cmpe.boun.edu.tr, ipng@sunroof.eng.sun.com Subject: (IPng 6808) Re: ipng perf In-reply-to: Your message of "Mon, 30 Nov 1998 10:30:11 PST." <199811301830.KAA08169@kebe.eng.sun.com> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Mon, 30 Nov 1998 09:01:27 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199811301830.KAA08169@kebe.eng.sun.com>, you write: >> Does anyone know where I can find ipng performance results or ipv6/ipv4 >> performance comparison? >> Emre. > >I can point you at the paper we did at NRL (back when I was at NRL). It's >from the January, 1996 USENIX, and while it talks more about implementation, >it does have some preliminary performance results: ... >Keep in mind, the numbers in that paper are preliminary, and I suspect that >the difference between v4 and v6 has slimmed, especially with bigger cache >lines, etc. that are in more recent machines. Also, in that version of the implementation, as with most currently existing implementations, the current emphasis is on building something that works (maybe even correctly), not necessarily on building something that goes fast. Many people fail to realize that the IPv4 implementations we use today are the product of decades of optimizations and performance insights. IPv6 implementations are going to have to mature over time, just like IPv4 implementations had to. Of course, we hope that they will reach the current state of the art in a lot less time than it took us to come up with the current state of the art in the first place ;) In theory, it should be possible to build IPv6 implementations that go at least as fast as IPv4 implementations. The downside to IPv6 is you have to play with bigger addresses and the baggage that comes with that, but the upshot is that there's less overall work to be done per packet (because the IPv6 header checksum is gone and because the fragmentation stuff is moved out of the base header). -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 Nov 30 11:56:42 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA15622 for ipng-dist; Mon, 30 Nov 1998 11:47:36 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA15615 for ; Mon, 30 Nov 1998 11:47:13 -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 LAA13015 for ; Mon, 30 Nov 1998 11:47:12 -0800 Received: from exchsrv1.cs.washington.edu (exchsrv1.cs.washington.edu [128.95.3.128]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA06823 for ; Mon, 30 Nov 1998 11:47:12 -0800 (PST) Received: by exchsrv1.cs.washington.edu with Internet Mail Service (5.5.1960.3) id ; Mon, 30 Nov 1998 11:46:55 -0800 Message-ID: <055A195871E5D1119F8100A0C9499B5F4F972D@exchsrv1.cs.washington.edu> From: Marc Fiuczynski To: "'Craig Metz '" , "'Dan McDonald '" Cc: "'emre@cmpe.boun.edu.tr '" , "'ipng@sunroof.Eng.Sun.COM '" Subject: (IPng 6809) Re: ipng perf Date: Mon, 30 Nov 1998 11:46:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have made a few measurements between a pair of W/NT4.0 machines using IPv4 and IPv6 (the IPv6 stack is from Microsoft Research). These measurements were done back in April 1998, in the context of my IPv6/IPv4 Network Address and Protocol Translator work (published in 1998 USENIX). The performance measurements are available from the following URL http://www.cs.washington.edu/research/networking/napt/ and then click on the "Applications & Benchmarks" link. Note that my IPv6 measurements are for an earlier version of the MSRIPv6 stack. The performance of the MSRIPv6 stack has significantly improved. Richard Draves et. al. 1998 USENIX/NT paper provides more measurements. A version of their paper is available from http://www.research.microsoft.com/msripv6/usenixnt/paper.htm. Take a look in the performance section of the paper (section 6). Note that in my measurements I achieve better performance than reported in Richard Draves paper for IPv4 and IPv6 numbers on Ethernet, and for IPv4 onfast Ethernet. My belief is that the performance difference is mostly due to using different Ethernet NICs (I used 3COM 3c905 and they use SMC NICs) and drivers. In fact, for my experiments, using an older version of the 3COM driver achieves nearly 500Kbytes/sec better throughput on fast Ethernet W/NT4.0 than reported on my webpage. Consequently, the roughly 2% performance difference that one might expect to see due to IPv6 protocol overhead is just in the noise!!! It is much more important to get finely tuned drivers and networking hardware than worry about the small performance impact that IPv6 protocol overhead may introduce. Marc -------------------------------------------------------------------- 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 --------------------------------------------------------------------