From owner-ipng Fri Nov 1 10:12:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05677; Fri, 1 Nov 96 10:12:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05562; Fri, 1 Nov 96 06:52:02 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA27742; Fri, 1 Nov 1996 06:45:15 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA02741 for ; Fri, 1 Nov 1996 06:45:13 -0800 Received: from localhost by ietf.org id aa03486; 1 Nov 96 9:27 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: (IPng 2427) I-D ACTION:draft-ietf-ipngwg-ipv6-tunnel-04.txt Date: Fri, 01 Nov 1996 09:27:44 -0500 Message-Id: <9611010927.aa03486@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Generic Packet Tunneling in IPv6 Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-ipv6-tunnel-04.txt Pages : 35 Date : 10/31/1996 This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. The model and mechanisms can be applied to other protocol packets as well, such as AppleTalk, IPX, CLNP, or others. 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-ipv6-tunnel-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961031163102.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-tunnel-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961031163102.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 1 14:30:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05907; Fri, 1 Nov 96 14:30:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05901; Fri, 1 Nov 96 14:29:48 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA12416; Fri, 1 Nov 1996 14:22:24 -0800 Received: from basil.cdt.luth.se (basil.cdt.luth.se [130.240.64.67]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA01070 for ; Fri, 1 Nov 1996 14:22:12 -0800 Received: from scarpa (scarpa.cdt.luth.se [130.240.64.46]) by basil.cdt.luth.se (8.7.5/8.7.3) with ESMTP id XAA01882; Fri, 1 Nov 1996 23:19:50 +0100 (MET) Received: from scarpa (localhost [127.0.0.1]) by scarpa (SMI-8.6/8.6.12) with ESMTP id XAA14262; Fri, 1 Nov 1996 23:21:51 +0100 Message-Id: <199611012221.XAA14262@scarpa> X-Mailer: exmh version 1.6.7 5/3/96 To: ipng@sunroof.eng.sun.com Cc: micke@cdt.luth.se Subject: (IPng 2428) Parameters for v6hc Content-Transfer-Encoding: quoted-printable Date: Fri, 01 Nov 1996 23:21:51 +0100 From: Mikael Degermark Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am now finalizing the draft on header compression for IPv6 = for point-to-point links. Having a bit of initial negotiation = over such links (e.g., PPP) is not a big problem. When we want to do this for shared media, however, = for example wireless networks, there is a problem with determining header compression parameters. Especially in the presence of multicast. I would appreciate your input. Determining the value of these parameters is crucial for the = correct operation of header compression. If sender and receiver disagree on the values, a "black hole" = may be created and no packets will get through. The parameters in question are things like = - size of identifier space, and = - upper limit on how much header to compress. For systems with memory constraints, these things are important. Having 256 headers of a few KB each in store may not be feasible for all concievable end-systems. There are a number of possible ways to do this: 1) for each type of network over which header compression = may be used, define the values of the parameters in the = "IPv6 over foo" documents. - minimal flexibility. = 2) senders periodically transmit the values they use. - a little more flexibility but a receiver who cannot comply with the parameter loses. 3) define a negotiation procedure. = - this is the most flexible approach as receivers can have a say but it may be non-trivial to design. Especially in networks without a central node like a base-station and with new mobile users arriving and leaving. = Perhaps this information should be distributed with the same mechanisms by which the mobile gets an address? Comments as to what path to choose? Micke = ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Nov 3 10:15:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06471; Sun, 3 Nov 96 10:15:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06465; Sun, 3 Nov 96 10:15:05 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA12443; Sun, 3 Nov 1996 10:08:14 -0800 Received: from universe.digex.net (universe.digex.net [205.197.248.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA00387 for ; Sun, 3 Nov 1996 10:08:16 -0800 Received: (from boots@localhost) by universe.digex.net (8.6.12/8.6.12) id NAA19195; Sun, 3 Nov 1996 13:08:14 -0500 From: Art Boots Coleman Message-Id: <199611031808.NAA19195@universe.digex.net> Subject: (IPng 2429) Re: Parameters for v6hc To: ipng@sunroof.eng.sun.com (IPng List) Date: Sun, 3 Nov 1996 13:08:14 -0500 (EST) In-Reply-To: <199611012221.XAA14262@scarpa> from "Mikael Degermark" at Nov 1, 96 11:21:51 pm Reply-To: boots@universe.digex.net 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 Go for the Kitchen sink Use an octet (or two) that indicates a 'channel' number. Have a hard set range for each of these: 1) the predefined "IPv6 over foo" docs 2) senders periodically transmit the values they use 3) define a negotiation procedure 4) methods under development Or if 'range' is too confining, use 2 bits for a flag (the other 6 bits will be found work soon enough :-) Intranets would probable use #1, while mobiles would carry a suite of #3 methods. In general, there is no reason that I can see to believe one of the options precludes the others. Leave the options open. Art Coleman boots@universe.digex.net ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Nov 6 16:44:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02624; Wed, 6 Nov 96 16:44:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02617; Wed, 6 Nov 96 16:44:01 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA08826; Wed, 6 Nov 1996 16:37:06 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA04253 for ; Wed, 6 Nov 1996 16:37:03 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id TAA11358; Wed, 6 Nov 1996 19:27:47 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA19050; Wed, 6 Nov 1996 19:27:51 -0500 Message-Id: <9611070027.AA19050@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2430) IPv6 Technology Breakthrough Altavista Date: Wed, 06 Nov 96 19:27:51 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As many people use Altavista on the Internet you can now use it running IPv6 on the 6bone. /jim ------- Forwarded Message Return-Path: majordom@ISI.EDU Received: from flume.zk3.dec.com by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA21520; Tue, 5 Nov 1996 15:21:41 -0500 Received: from mail12.digital.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA01704; Tue, 5 Nov 1996 15:21:40 -0500 Received: from zephyr.isi.edu by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id PAA21527; Tue, 5 Nov 1996 15:10:52 -0500 (EST) Received: by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 5 Nov 1996 11:21:37 -0800 Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 5 Nov 1996 11:21:35 -0800 Received: from mail2.digital.com by venera.isi.edu (5.65c/5.61+local-25) id ; Tue, 5 Nov 1996 11:21:35 -0800 Received: from pobox1.pa.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA03117; Tue, 5 Nov 1996 11:19:30 -0800 Received: by pobox1.pa.dec.com; id AA10099; Tue, 5 Nov 96 11:19:29 -0800 Received: from localhost by nsl-too.pa.dec.com; (5.65v3.2/1.1.8.2/13Jul94-0558PM) id AA28314; Tue, 5 Nov 1996 11:19:29 -0800 Message-Id: <9611051919.AA28314@nsl-too.pa.dec.com> To: 6bone@ISI.EDU Cc: Stephen Stuart Subject: IPV6 web servers Date: Tue, 05 Nov 96 11:19:28 -0800 From: Stephen Stuart X-Mts: smtp Sender: owner-6bone@ISI.EDU Precedence: bulk Three of Digital's Palo Alto web servers are now IPV6-capable. Point your IPV6-capable web browser at any of the following URLs for the IPV6 versions of: http://altavista.ipv6.digital.com/ AltaVista http://www.ipv6.digital.com/ Digital's corporate WWW server http://ftp.ipv6.digital.com/ Search gatekeeper.dec.com's archive If you have IPV6-specific problems with any of these services, please contact me rather than the official support folks. Stephen - - ----- Stephen Stuart stuart@pa.dec.com Network Systems Laboratory Digital Equipment Corporation ------- End of Forwarded Message ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Nov 7 08:58:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03135; Thu, 7 Nov 96 08:58:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03095; Thu, 7 Nov 96 07:36:28 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA20069; Thu, 7 Nov 1996 07:29:34 -0800 Received: from lrcsuns.epfl.ch (lrcsuns.epfl.ch [128.178.156.24]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA28435 for ; Thu, 7 Nov 1996 07:29:29 -0800 Received: from lrc.epfl.ch (lrcsun13.epfl.ch [128.178.156.38]) by lrcsuns.epfl.ch (8.6.12/8.6.9) with ESMTP id QAA19367 for ; Thu, 7 Nov 1996 16:29:24 +0100 Message-Id: <199611071529.QAA19367@lrcsuns.epfl.ch> X-Mailer: exmh version 1.6.7 5/3/96 To: ipng@sunroof.eng.sun.com Subject: (IPng 2431) Boundaries of IPv6 Multicast Scopes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Nov 1996 16:29:24 +0100 From: Thorsten Kurz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As we see in RFC 1884 multicast groups in IPv6 can be limited to certain scopes. I would like to know how the boundaries of the organization-local scope are determined. Is this done by the network prefix? What about a company having departments spread all over the world it wants to reach by a multicast? Thanks, Thorsten ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Nov 10 08:03:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04896; Sun, 10 Nov 96 08:03:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04890; Sun, 10 Nov 96 08:03:45 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA00491; Sun, 10 Nov 1996 07:56:37 -0800 Received: from oberon.di.fc.ul.pt (oberon.di.fc.ul.pt [192.67.76.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA28906; Sun, 10 Nov 1996 07:56:42 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id PAA06413; Sun, 10 Nov 1996 15:50:56 GMT Date: Sun, 10 Nov 1996 15:50:56 GMT Message-Id: <199611101550.PAA06413@oberon.di.fc.ul.pt> From: Pedro Roque To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com, set@thumper.bellcore.com, gilligan@Eng Subject: (IPng 2432) BSD API - ipv6_mreq Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ------------------------------------------------------------------------------ [ This is a resend of a previous message that i believe got swallowed by sunroof's mailing list software since i didn't receive a copy in 24 hours. Now cc'ed to the draft authors ] ------------------------------------------------------------------------------ The BSD api draft v05 defines struct ipv6_mreq as: struct ipv6_mreq { /* IPv6 multicast address of group */ struct in6_addr ipv6mr_multiaddr; /* local IPv6 address of interface */ struct in6_addr ipv6mr_interface; }; As "local" addresses are not required to be unique (unless you actually use kre's iid draft) i would suggest changing this definition to: struct ipv6_mreq { /* IPv6 multicast address of group */ struct in6_addr ipv6mr_multiaddr; /* local IPv6 address of interface */ int ipv6mr_ifindex; }; This has the extra advantage, IMHO, of being more consistent with the advanced API draft. comments ? regards, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Nov 10 09:47:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05018; Sun, 10 Nov 96 09:47:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05012; Sun, 10 Nov 96 09:47:42 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA14818; Sun, 10 Nov 1996 09:40:34 -0800 Received: from oberon.di.fc.ul.pt (oberon.di.fc.ul.pt [192.67.76.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA13640 for ; Sat, 9 Nov 1996 10:12:18 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id SAA02644; Sat, 9 Nov 1996 18:06:38 GMT Date: Sat, 9 Nov 1996 18:06:38 GMT Message-Id: <199611091806.SAA02644@oberon.di.fc.ul.pt> From: Pedro Roque To: ipng@sunroof.eng.sun.com Subject: (IPng 2433) struct ipv6_mreq Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The bsd-api draft v05 defines struct ipv6_mreq as: struct ipv6_mreq { /* IPv6 multicast address of group */ struct in6_addr ipv6mr_multiaddr; /* local IPv6 address of interface */ struct in6_addr ipv6mr_interface; }; However, since "local" interface addresses might be duplicate and to be more consistent with the advanced API draft, i propose that this struct is changed to: struct ipv6_mreq { /* IPv6 multicast address of group */ struct in6_addr ipv6mr_multiaddr; /* local IPv6 address of interface */ int ipv6mr_ifindex; }; comments ? regards, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 11 07:59:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05403; Mon, 11 Nov 96 07:59:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05397; Mon, 11 Nov 96 07:59:12 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA24775; Mon, 11 Nov 1996 07:52:11 -0800 Received: from mailgate.aist-nara.ac.jp (fsb1.aist-nara.ac.jp [163.221.76.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA10577 for ; Mon, 11 Nov 1996 07:52:11 -0800 Received: from prince.aist-nara.ac.jp ([163.221.206.4]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with ESMTP id AAA18422; Tue, 12 Nov 1996 00:51:43 +0900 Received: from prince.aist-nara.ac.jp by prince.aist-nara.ac.jp (8.7.6/2.7W-AIST/1.3) id PAA00325; Mon, 11 Nov 1996 15:50:23 GMT Message-Id: <199611111550.PAA00325@prince.aist-nara.ac.jp> To: ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au Subject: (IPng 2434) WIDE IPv6 T-shirt X-Mailer: Mew version 1.06 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 12 Nov 1996 00:50:22 +0900 From: SUMIKAWA Munechika Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I'm a member of WIDE project in Japan. I will bring the "WIDE IPv6 T-shirt" to the next IETF meeting at San Jose. Its price will be $15 - $20. Since I would like to estimate how many T-shirts we have to prepare, Please send me your size(L or XL) if do you want it. You can see its design at: http://fukuda.aist-nara.ac.jp/~muneti-s/Tshirt/ --- SUMIKAWA Munechika @ NAra Institute of Science and Technology ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 11 10:01:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05873; Mon, 11 Nov 96 10:01:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05867; Mon, 11 Nov 96 10:01:40 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA13081; Mon, 11 Nov 1996 09:54:38 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA23587; Mon, 11 Nov 1996 09:54:34 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id MAA30231; Mon, 11 Nov 1996 12:42:36 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23033; Mon, 11 Nov 1996 12:42:33 -0500 Message-Id: <9611111742.AA23033@wasted.zk3.dec.com> To: Pedro Roque Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com, set@thumper.bellcore.com, gilligan@Eng Subject: (IPng 2435) Re: BSD API - ipv6_mreq In-Reply-To: Your message of "Sun, 10 Nov 96 15:50:56 GMT." <199611101550.PAA06413@oberon.di.fc.ul.pt> Date: Mon, 11 Nov 96 12:42:32 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pedro, >The BSD api draft v05 defines struct ipv6_mreq as: > > struct ipv6_mreq { > /* IPv6 multicast address of group */ > struct in6_addr ipv6mr_multiaddr; > > /* local IPv6 address of interface */ > struct in6_addr ipv6mr_interface; > }; >As "local" addresses are not required to be unique (unless you actually use >kre's iid draft) i would suggest changing this definition to: Note they are guranteed to be unique on the same link just not on different links. And I agree Kre's ID fixes this too. > struct ipv6_mreq { > /* IPv6 multicast address of group */ > struct in6_addr ipv6mr_multiaddr; > > /* local IPv6 address of interface */ > int ipv6mr_ifindex; I think this is really not different. The Advanced API spec provides a way to determine the xx_ifindex, which is different than the address. Are you saying send the packet to an "index of the interface" or the "address"? I would claim that if you do have duplicate link-local address on two links into your node then that is not the normal case unless you chose a bogus token. And that in these cases for multicast the implementation should recognize this situation in the routing table and send the message to both interfaces. Why complex the normal case? /jim }; This has the extra advantage, IMHO, of being more consistent with the advanced API draft. comments ? regards, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 11 10:21:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05976; Mon, 11 Nov 96 10:21:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05970; Mon, 11 Nov 96 10:21:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA16729; Mon, 11 Nov 1996 10:14:33 -0800 Received: from oberon.di.fc.ul.pt (oberon.di.fc.ul.pt [192.67.76.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA00948; Mon, 11 Nov 1996 10:14:08 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id SAA11231; Mon, 11 Nov 1996 18:07:45 GMT Date: Mon, 11 Nov 1996 18:07:45 GMT Message-Id: <199611111807.SAA11231@oberon.di.fc.ul.pt> From: Pedro Roque To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com, set@thumper.bellcore.com, gilligan@Eng Subject: (IPng 2436) Re: BSD API - ipv6_mreq In-Reply-To: <9611111742.AA23033@wasted.zk3.dec.com> References: <199611101550.PAA06413@oberon.di.fc.ul.pt> <9611111742.AA23033@wasted.zk3.dec.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Jim" == bound writes: Jim> Pedro, >> The BSD api draft v05 defines struct ipv6_mreq as: >> >> struct ipv6_mreq { /* IPv6 multicast address of group */ struct >> in6_addr ipv6mr_multiaddr; >> >> /* local IPv6 address of interface */ struct in6_addr >> ipv6mr_interface; }; >> As "local" addresses are not required to be unique (unless you >> actually use kre's iid draft) i would suggest changing this >> definition to: Jim> Note they are guranteed to be unique on the same link just Jim> not on different links. And I agree Kre's ID fixes this too. >> struct ipv6_mreq { /* IPv6 multicast address of group */ struct >> in6_addr ipv6mr_multiaddr; >> >> /* local IPv6 address of interface */ int ipv6mr_ifindex; Jim> I think this is really not different. The Advanced API spec Jim> provides a way to determine the xx_ifindex, which is Jim> different than the address. Jim> Are you saying send the packet to an "index of the interface" Jim> or the "address"? To select the interface on which you will join the mentioned multicast group. Jim> I would claim that if you do have duplicate link-local Jim> address on two links into your node then that is not the Jim> normal case unless you chose a bogus token. Not really. Some machines set the same hardware address on all it's interfaces i believe. Also, if you create interfaces for configured tunneling, you will have the same link token on all vifs. Jim> And that in Jim> these cases for multicast the implementation should recognize Jim> this situation in the routing table and send the message to Jim> both interfaces. This isn't the "normal" semantics of group join. Jim> Why complex the normal case? I don't think my proposal involves any increased complexity while it simplifies some cases (i.e. doesn't force you to implement kre's draft). regards, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 11 11:07:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06186; Mon, 11 Nov 96 11:07:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06180; Mon, 11 Nov 96 11:07:49 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA25223; Mon, 11 Nov 1996 11:00:46 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA22328 for ; Mon, 11 Nov 1996 11:00:48 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA08572; Mon, 11 Nov 1996 13:46:16 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA31401; Mon, 11 Nov 1996 13:46:21 -0500 Message-Id: <9611111846.AA31401@wasted.zk3.dec.com> To: Pedro Roque Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2437) Re: BSD API - ipv6_mreq In-Reply-To: Your message of "Mon, 11 Nov 96 18:07:45 GMT." <199611111807.SAA11231@oberon.di.fc.ul.pt> Date: Mon, 11 Nov 96 13:46:21 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim> I would claim that if you do have duplicate link-local Jim> address on two links into your node then that is not the Jim> normal case unless you chose a bogus token. >Not really. Some machines set the same hardware address on all it's >interfaces i believe. Also, if you create interfaces for configured >tunneling, you will have the same link token on all vifs. Well then that implementation has been doing the wrong thing for a long time and now its caught in its error via IPv6. Thats the way it goes. Jim> And that in Jim> these cases for multicast the implementation should recognize Jim> this situation in the routing table and send the message to Jim> both interfaces. >This isn't the "normal" semantics of group join. IPv6 link-local addresses change the "norm" for join. So the norm is no longer the norm. Sorry but that reality for IPv6. Jim> Why complex the normal case? >I don't think my proposal involves any increased complexity while it >simplifies some cases (i.e. doesn't force you to implement kre's >draft). You did not specify a solution? Just a name change. I was referring to carrying two paramenters for the join index+address. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 11 11:26:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06284; Mon, 11 Nov 96 11:26:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06278; Mon, 11 Nov 96 11:26:19 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA28773; Mon, 11 Nov 1996 11:19:19 -0800 Received: from oberon.di.fc.ul.pt (oberon.di.fc.ul.pt [192.67.76.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA29544 for ; Mon, 11 Nov 1996 11:19:12 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id TAA11478; Mon, 11 Nov 1996 19:12:52 GMT Date: Mon, 11 Nov 1996 19:12:52 GMT Message-Id: <199611111912.TAA11478@oberon.di.fc.ul.pt> From: Pedro Roque To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2438) Re: BSD API - ipv6_mreq In-Reply-To: <9611111846.AA31401@wasted.zk3.dec.com> References: <199611111807.SAA11231@oberon.di.fc.ul.pt> <9611111846.AA31401@wasted.zk3.dec.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Jim" == bound writes: Jim> I would claim that if you do have duplicate link-local Jim> address on two links into your node then that is not the Jim> normal case unless you chose a bogus token. >> Not really. Some machines set the same hardware address on all >> it's interfaces i believe. Also, if you create interfaces for >> configured tunneling, you will have the same link token on all >> vifs. Jim> Well then that implementation has been doing the wrong thing Jim> for a long time and now its caught in its error via IPv6. Jim> Thats the way it goes. I don't really consider to be an error to use the nodes IPv4 address as token for it's several tunnel interfaces. I'm of course fully open to corrections. Jim> And that in these cases for multicast the implementation Jim> should recognize this situation in the routing table and send Jim> the message to both interfaces. >> This isn't the "normal" semantics of group join. Jim> IPv6 link-local addresses change the "norm" for join. So the Jim> norm is no longer the norm. Sorry but that reality for IPv6. So you are saying that a group membership join in which the link local address (which is unique in the link) is not unique in the node will result in a group join to all the interfaces which have that link address ? If so i think that should be spelled out in the API draft. I would also like to hear the rational for this change as i cannot think of a reason to change the past behaviour. Jim> Why complex the normal case? >> I don't think my proposal involves any increased complexity >> while it simplifies some cases (i.e. doesn't force you to >> implement kre's draft). Jim> You did not specify a solution? Just a name change. I was Jim> referring to carrying two paramenters for the join Jim> index+address. Sorry, i cannot parse the above sentence. What do you mean by "just a name change" ? ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 11 12:27:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06443; Mon, 11 Nov 96 12:27:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06434; Mon, 11 Nov 96 12:27:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA09326; Mon, 11 Nov 1996 12:20:35 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA21504 for ; Mon, 11 Nov 1996 12:20:31 -0800 Received: from gungnir.fnal.gov ("port 33647"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IBQ0Z2F8AU003TCT@FNAL.FNAL.GOV>; Mon, 11 Nov 1996 14:20:27 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id OAA13316; Mon, 11 Nov 1996 14:18:39 -0600 Date: Mon, 11 Nov 1996 14:18:39 -0600 From: Matt Crawford Subject: (IPng 2439) Re: BSD API - ipv6_mreq In-Reply-To: "11 Nov 1996 12:42:32 EST." <"9611111742.AA23033"@wasted.zk3.dec.com> To: bound@zk3.dec.com Cc: Pedro Roque , ipng@sunroof.eng.sun.com Message-Id: <199611112018.OAA13316@gungnir.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Are you saying send the packet to an "index of the interface" or the > "address"? Of course you send the packet "to" an address, but I think he's saying that you send it "through" an interface, rather than an address, because the same address may belong to more than one of your interfaces. > I would claim that if you do have duplicate link-local address on two > links into your node then that is not the normal case unless you chose a > bogus token. I haven't looked it up for myself, but others have said that the original 802.3 concept of a node with multiple interfaces had the same MAC address on all. So this could be called a perfectly normal condition. > And that in these cases for multicast the implementation > should recognize this situation in the routing table and send the > message to both interfaces. No, no! Everyone in the scope of the destination address will get duplicates, if the two (or more) sending interfaces are in the same scope. As Jim and Pedro both said, using iid's in the link-local address disambiguates the interface addresses. The question is then, should multicast joins specify an interface index, or do iids become MANDATORY for multihomed nodes which potentially have the same MAC address on several interfaces? _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 11 14:51:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06640; Mon, 11 Nov 96 14:51:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06634; Mon, 11 Nov 96 14:51:39 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA02498; Mon, 11 Nov 1996 14:44:37 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA08675 for ; Mon, 11 Nov 1996 14:44:38 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id RAA30884; Mon, 11 Nov 1996 17:33:47 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA30129; Mon, 11 Nov 1996 17:33:52 -0500 Message-Id: <9611112233.AA30129@wasted.zk3.dec.com> To: Pedro Roque Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2440) Re: BSD API - ipv6_mreq In-Reply-To: Your message of "Mon, 11 Nov 96 19:12:52 GMT." <199611111912.TAA11478@oberon.di.fc.ul.pt> Date: Mon, 11 Nov 96 17:33:52 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pedro, >> Not really. Some machines set the same hardware address on all >> it's interfaces i believe. Also, if you create interfaces for >> configured tunneling, you will have the same link token on all >> vifs. Jim> Well then that implementation has been doing the wrong thing Jim> for a long time and now its caught in its error via IPv6. Jim> Thats the way it goes. >I don't really consider to be an error to use the nodes IPv4 address >as token for it's several tunnel interfaces. I'm of course fully open to >corrections. ^&[..a.b} ???? Why are you bringing tunnels up? Why are you bringing IPv4 up it does not have a low order 48bit token? For IPv6 you take a token and attach it to FE80::. If you use the MAC address most likely you will not get a duplicate address on a link. The IEEE does not hand them out in duplicates its evil people that change them in an inconsistent manner. But if someone for years has been using the ID of a disk drive to create unique tokens that is not going to be optimal for IPv6 link local addresses. So if you have an ID from the disk drive of 123456 and you use it for every link local address all of your link local addresses will be duplicated. Number 1 your not allowed to do that twice on a link. If you do it on different links then you will duplicate your link local address. So what I am saying is that if one has this strategy in your architecture in ones IP stack then its going to be painful for one in IPv6. The other option is to use the MAC address for example on Ethernet, which will be unique across links unless there is this one funny implementation on the network. Jim> And that in these cases for multicast the implementation Jim> should recognize this situation in the routing table and send Jim> the message to both interfaces. >> This isn't the "normal" semantics of group join. Jim> IPv6 link-local addresses change the "norm" for join. So the Jim> norm is no longer the norm. Sorry but that reality for IPv6. >So you are saying that a group membership join in which the link local address >(which is unique in the link) is not unique in the node will result in a >group join to all the interfaces which have that link address ? I am saying thats one implementation option, another would be to not do this? IMHO its an implementation problem not a standards problem. >If so i think that should be spelled out in the API draft. I would also >like to hear the rational for this change as i cannot think of a >reason to change the past behaviour. I have answer that above I think and why its the way it is specified. Jim> Why complex the normal case? >> I don't think my proposal involves any increased complexity >> while it simplifies some cases (i.e. doesn't force you to >> implement kre's draft). Jim> You did not specify a solution? Just a name change. I was Jim> referring to carrying two paramenters for the join Jim> index+address. >Sorry, i cannot parse the above sentence. What do you mean by "just a >name change" ? The present spec states: struct ipv6_mreq { /* IPv6 multicast address of group */ struct in6_addr ipv6mr_multiaddr; /* local IPv6 address of interface */ struct in6_addr ipv6mr_interface; }; You suggest: struct ipv6_mreq { /* IPv6 multicast address of group */ struct in6_addr ipv6mr_multiaddr; /* local IPv6 address of interface */ int ipv6mr_ifindex; }; This has the extra advantage, IMHO, of being more consistent with the advanced API draft. All you changed was to rename the IPv6 addr to an "int" and new defined type. I was assuming you wanted something like the following (from the advanced api spec): struct in6_pktinfo { int ipi6_ifindex; /* interface index */ struct in6_addr ipi6_addr; /* IPv6 address */ }; Is that clearer? If we do this that changes the behavior of how multicast apps are done today. It also prevents me from assuming an address for join will include multiple interfaces simply by the address per my implementation trickery or finess how ever you choose to speak of us captitalist pigs )->;. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 11 15:04:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06662; Mon, 11 Nov 96 15:04:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06653; Mon, 11 Nov 96 15:03:55 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA04583; Mon, 11 Nov 1996 14:56:53 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA12759 for ; Mon, 11 Nov 1996 14:56:28 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id RAA21005; Mon, 11 Nov 1996 17:49:31 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA32009; Mon, 11 Nov 1996 17:49:42 -0500 Message-Id: <9611112249.AA32009@wasted.zk3.dec.com> To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2441) Re: BSD API - ipv6_mreq In-Reply-To: Your message of "Mon, 11 Nov 96 14:18:39 CST." <199611112018.OAA13316@gungnir.fnal.gov> Date: Mon, 11 Nov 96 17:49:41 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Are you saying send the packet to an "index of the interface" or the >> "address"? >Of course you send the packet "to" an address, but I think he's >saying that you send it "through" an interface, rather than an >address, because the same address may belong to more than one of your >interfaces. Yep thats what I mean't by an index using an address for that set of interfaces. >> I would claim that if you do have duplicate link-local address on two >> links into your node then that is not the normal case unless you chose a >> bogus token. >I haven't looked it up for myself, but others have said that the >original 802.3 concept of a node with multiple interfaces had the >same MAC address on all. So this could be called a perfectly normal >condition. Yes that is true from many years ago of looking at it. But I think we have that covered because its my impression that 802.3 assumes that in the case of multiple interfaces with the same MAC address it also implies they are all on the same link. We need to check on that though? But in this case on the same link thats covered where we say they must be presented as a single interface to the IP layer in 1884? >> And that in these cases for multicast the implementation >> should recognize this situation in the routing table and send the >> message to both interfaces. >As Jim and Pedro both said, using iid's in the link-local address >disambiguates the interface addresses. The question is then, should >multicast joins specify an interface index, or do iids become >MANDATORY for multihomed nodes which potentially have the same MAC >address on several interfaces? Ah the question of the day..... we keep avoiding. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 11 15:24:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06703; Mon, 11 Nov 96 15:24:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06697; Mon, 11 Nov 96 15:24:45 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA08294; Mon, 11 Nov 1996 15:17:43 -0800 Received: from oberon.di.fc.ul.pt (oberon.di.fc.ul.pt [192.67.76.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA19612 for ; Mon, 11 Nov 1996 15:17:37 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id XAA12320; Mon, 11 Nov 1996 23:09:15 GMT Date: Mon, 11 Nov 1996 23:09:15 GMT Message-Id: <199611112309.XAA12320@oberon.di.fc.ul.pt> From: Pedro Roque To: bound@zk3.dec.com Cc: Pedro Roque , ipng@sunroof.eng.sun.com Subject: (IPng 2442) Re: BSD API - ipv6_mreq In-Reply-To: <9611112233.AA30129@wasted.zk3.dec.com> References: <199611111912.TAA11478@oberon.di.fc.ul.pt> <9611112233.AA30129@wasted.zk3.dec.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Jim" == bound writes: Jim> I am saying thats one implementation option, another would be Jim> to not do this? IMHO its an implementation problem not a Jim> standards problem. >From a standards problem, we don't currently assume (to my knowledge) that a link local address is unique on an host. The only problem that this "fact" raises is in terms of API, as kernels themselfs have proper means to identify interfaces. I believe that the Advanced API draft solves the interface identification problem for all other cases than the one we are discussing. So from a standards point of view i would like that the base API draft would solve the same identification problem for multicast membership. Note that what i'm advocating is relevant to the standards process since there is an iid draft on the table which implies changes to the DAD process to solve what is mainly an API problem. With all due respect to kre i believe that it would be better if we didn't need the iid spec. I think there are only two simple soluctions, from the standards point of view to the iid problem: 1) Assume, (and state it on the specs), that a interface token or the repective link local address must be unique on a node. 2) Change the field on ipv6_mreq. Jim> I was assuming you wanted something like the following (from Jim> the advanced api spec): Jim> struct in6_pktinfo { int ipi6_ifindex; /* interface Jim> index */ struct in6_addr ipi6_addr; /* IPv6 address */ }; You assume correctly. And i apologise for not being clearer on my initial message. regards, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 11 15:43:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06739; Mon, 11 Nov 96 15:43:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06733; Mon, 11 Nov 96 15:43:33 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA11211; Mon, 11 Nov 1996 15:36:31 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA25607 for ; Mon, 11 Nov 1996 15:36:33 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA12556; Mon, 11 Nov 96 15:35:37 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id PAA00406; Mon, 11 Nov 1996 15:36:26 -0800 Date: Mon, 11 Nov 1996 15:36:26 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199611112336.PAA00406@feller.mentat.com> To: bound@zk3.dec.com Subject: (IPng 2443) Re: BSD API - ipv6_mreq Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > I am saying thats one implementation option, another would be to not do > this? IMHO its an implementation problem not a standards problem. > I disagee. An API specification is useless unless it is clear what packets are going to be sent as a result of invoking a particular API primitive. If it is left up to each implementation then every platform will behave differently and portability is out the window. > > The present spec states: > > struct ipv6_mreq { > /* IPv6 multicast address of group */ > struct in6_addr ipv6mr_multiaddr; > > /* local IPv6 address of interface */ > struct in6_addr ipv6mr_interface; > }; > > You suggest: > > struct ipv6_mreq { > /* IPv6 multicast address of group */ > struct in6_addr ipv6mr_multiaddr; > > /* local IPv6 address of interface */ > int ipv6mr_ifindex; > }; > > This has the extra advantage, IMHO, of being more consistent with > the advanced API draft. > > All you changed was to rename the IPv6 addr to an "int" and new defined > type. > > I was assuming you wanted something like the following (from the > advanced api spec): > > struct in6_pktinfo { > int ipi6_ifindex; /* interface index */ > struct in6_addr ipi6_addr; /* IPv6 address */ > }; > > Is that clearer? > > If we do this that changes the behavior of how multicast apps are done > today. It also prevents me from assuming an address for join will > include multiple interfaces simply by the address per my implementation > trickery or finess how ever you choose to speak of us captitalist > pigs )->;. > What multicast apps are you refering to? They can't be IPv6 apps since this API is relatively new. I don't know of anyone who is arguing for a single join request refering to multiple physical interfaces. Claiming that changing the in6_pktinfo structure to use an address instead of an index would eliminate this as yet unrequested option is a bit misleading. I general I agree with Pedro that we ought to be shooting for consistency in these interfaces. Consistency with IPv4 interfaces as well as consistency within the IPv6 interfaces themselves would be ideal in my opinion. There has been significant disagreement in the past with regard to con- sistency with existing IPv4 interfaces. I hold out little hope that those inconsistencies can be resolved given the intransigence we have witnessed int the past. Hopefully we can achieve some consensus on the IPv6 only interfaces. Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 11 16:03:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06790; Mon, 11 Nov 96 16:03:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06784; Mon, 11 Nov 96 16:02:52 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA13987; Mon, 11 Nov 1996 15:55:50 -0800 Received: from merit.edu (merit.edu [35.1.1.42]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA01336 for ; Mon, 11 Nov 1996 15:55:48 -0800 Received: from herman.merit.edu (masaki@herman.merit.edu [198.108.60.143]) by merit.edu (8.7.6/merit-2.0) with SMTP id SAA02212; Mon, 11 Nov 1996 18:53:05 -0500 (EST) Message-Id: <199611112353.SAA02212@merit.edu> To: Matt Crawford Cc: bound@zk3.dec.com, Pedro Roque , ipng@sunroof.eng.sun.com Subject: (IPng 2444) Re: BSD API - ipv6_mreq In-Reply-To: Your message of "Mon, 11 Nov 1996 14:18:39 CST." <199611112018.OAA13316@gungnir.fnal.gov> Date: Mon, 11 Nov 1996 18:53:04 -0500 From: Masaki Hirabaru Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As Jim and Pedro both said, using iid's in the link-local address > disambiguates the interface addresses. The question is then, should > multicast joins specify an interface index, or do iids become > MANDATORY for multihomed nodes which potentially have the same MAC > address on several interfaces? I'd like to think about this question in connection with the extension to recvmsg(). I heard that the new BSD API draft would include an extension to recvmsg() which makes it possible to identify the interface a packet arrives on. If this extension returns a (unique) link-local address of the interface, I think we will continue to use an address to specify an interface. If we will introduce an index explicitly to identify an interface, my feeling is that it's valuable to reconsider other program interfaces to use an index instead of an address. Indeed, it was curious for me to specify an interface with its local side address even if the interface was p-to-p. In an IPv4 time, p-to-p links often use the same local address (unnumbered) and are identified by its remote address. Masaki ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 11 17:17:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06895; Mon, 11 Nov 96 17:17:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06889; Mon, 11 Nov 96 17:17:11 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA24341; Mon, 11 Nov 1996 17:10:10 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA20828 for ; Mon, 11 Nov 1996 17:10:10 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id UAA30366; Mon, 11 Nov 1996 20:00:14 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14099; Mon, 11 Nov 1996 20:00:19 -0500 Message-Id: <9611120100.AA14099@wasted.zk3.dec.com> To: Pedro Roque Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2445) Re: BSD API - ipv6_mreq In-Reply-To: Your message of "Mon, 11 Nov 96 23:09:15 GMT." <199611112309.XAA12320@oberon.di.fc.ul.pt> Date: Mon, 11 Nov 96 20:00:18 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pedro, You convinced me its a problem. I prefer we do something to make all link-local addresses unique. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 11 17:30:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06925; Mon, 11 Nov 96 17:30:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06919; Mon, 11 Nov 96 17:30:39 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA26132; Mon, 11 Nov 1996 17:23:39 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA23941 for ; Mon, 11 Nov 1996 17:23:39 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id UAA09214; Mon, 11 Nov 1996 20:11:17 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14163; Mon, 11 Nov 1996 20:11:23 -0500 Message-Id: <9611120111.AA14163@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2446) Re: BSD API - ipv6_mreq In-Reply-To: Your message of "Mon, 11 Nov 96 15:36:26 PST." <199611112336.PAA00406@feller.mentat.com> Date: Mon, 11 Nov 96 20:11:23 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, >> >> I am saying thats one implementation option, another would be to not do >> this? IMHO its an implementation problem not a standards problem. >> >I disagee. An API specification is useless unless it is clear what packets >are going to be sent as a result of invoking a particular API primitive. >If it is left up to each implementation then every platform will behave >differently and portability is out the window. If the API works on all systems and they interoperate then the API is in fact portable. How you make it work underneath is an implementation issue. In Pedro's last mail he stated its an API problem but I maintain the problem is that we have not made sure the link-local address is unique all the time on a node which Kre's draft in fact does. > I was assuming you wanted something like the following (from the > advanced api spec): > > struct in6_pktinfo { > int ipi6_ifindex; /* interface index */ > struct in6_addr ipi6_addr; /* IPv6 address */ > }; > > Is that clearer? > > If we do this that changes the behavior of how multicast apps are done > today. It also prevents me from assuming an address for join will > include multiple interfaces simply by the address per my implementation > trickery or finess how ever you choose to speak of us captitalist > pigs )->;. > >What multicast apps are you refering to? They can't be IPv6 apps since >this API is relatively new. DHCPv6 is one. But thats a cheap shot at me. Take any IPv4 Multicast app today and port it to use bigger addresses and its a done deal. But if we do the above then its a change. Not that big of a change though. >I don't know of anyone who is arguing for a single join request refering >to multiple physical interfaces. Claiming that changing the in6_pktinfo >structure to use an address instead of an index would eliminate this as >yet unrequested option is a bit misleading. Another cheap shot. #1 no one stated we should change the in6_pktinfo so I don't know what your talking about. #2 if you want to join a multicast group and as a side effect your implementation does it on multiple interfaces "on different links" then thats not bad. #3 the question is should the in6_pktinfo be used is on the table? So I am not sure how you ended up on the above thread? >I general I agree with Pedro that we ought to be shooting for consistency >in these interfaces. Consistency with IPv4 interfaces as well as consistency >within the IPv6 interfaces themselves would be ideal in my opinion. Can you say that in more detail and be specific? I think I agree with you but I am not sure? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 11 18:32:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07005; Mon, 11 Nov 96 18:32:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06999; Mon, 11 Nov 96 18:32:20 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA02716; Mon, 11 Nov 1996 18:25:19 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA06793 for ; Mon, 11 Nov 1996 18:25:19 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA13323; Mon, 11 Nov 96 18:24:25 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id SAA00683; Mon, 11 Nov 1996 18:25:14 -0800 Date: Mon, 11 Nov 1996 18:25:14 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199611120225.SAA00683@feller.mentat.com> To: bound@zk3.dec.com Subject: (IPng 2447) Re: BSD API - ipv6_mreq Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > If the API works on all systems and they interoperate then the API is in > fact portable. How you make it work underneath is an implementation > issue. In Pedro's last mail he stated its an API problem but I maintain > the problem is that we have not made sure the link-local address is > unique all the time on a node which Kre's draft in fact does. > There is interoperability and then there is the behavior of the API. If one implementation registers the group on a single interface and another registers the group on multiple interfaces (with the same link local address) then the application will behave differently on the two implementations. The first system will only receive packets from a single interface. The other system will receive packets from multiple interfaces. I think most application writers would view this as an unacceptable deviation in behavior even though the two systems may interoperate just fine. Of course KRE's draft would guarantee link-local address uniqueness and alleviate the problem. > > DHCPv6 is one. But thats a cheap shot at me. Take any IPv4 Multicast > app today and port it to use bigger addresses and its a done deal. But > if we do the above then its a change. Not that big of a change though. > What cheap shot? I was asking a valid question. > > Another cheap shot. #1 no one stated we should change the in6_pktinfo so I > don't know what your talking about. #2 if you want to join a multicast > group and as a side effect your implementation does it on multiple > interfaces "on different links" then thats not bad. #3 the question is > should the in6_pktinfo be used is on the table? So I am not sure how > you ended up on the above thread? > > I was assuming you wanted something like the following (from the > > advanced api spec): > > > > struct in6_pktinfo { > > int ipi6_ifindex; /* interface index */ > > struct in6_addr ipi6_addr; /* IPv6 address */ > > }; > > > > Is that clearer? > > > > If we do this that changes the behavior of how multicast apps are done > > today. It also prevents me from assuming an address for join will > > include multiple interfaces simply by the address per my implementation > > trickery or finess how ever you choose to speak of us captitalist > > pigs )->;. > > Hmm... I think you are being a little sensitive. You are the one that placed the in6_pktinfo structure in your mail. You also made the statement that you would lose the ability to register a group on multiple interfaces simultaneously if the ipv6 mreq structure changed. I simply wanted to point out that no one has claimed to be dependent on that feature of the ipv6 mreq structure so we probably should not worry too much about losing that capability until someone does. > Can you say that in more detail and be specific? I think I agree with > you but I am not sure? Sure. The socket API's used for interface identification in IPv4 uses addresses to identify the interface. As many people have pointed out, including the original author of these interfaces, this is an imperfect solution for IPv4 because of unnumbered interfaces. Unfortunately, we are kind of stuck with it because there is code already out there. So what do we do for IPv6. The choices are: 1) Use addresses to identify interfaces just like we do in IPv4. There is consistency between IPv6 and IPv4 API's. Since every IPv6 interface can have a unique link-local address (see KRE's draft) we don't have the IPv4 unnumbered interface problem. 2) Use an interface index type thing to identify interfaces. This solution works but is not consistent with the IPv4 API's. 3) Use a mix of both 1) and 2). (This is what we have now). This is the worst of both worlds in my opinion. We need KRE's draft to solve the link local uniqueness problem but application writers also get a second incompatible mechanism for identifying interfaces. They use the old style address based mechanism when registering for multicast groups and they get the new style index base mechanism when sending or receiving packets. This dichotomy seems unnecessary since we have a pretty clean slate to work with in IPv6 API area. My hope would be that we could settle on 1) or 2). Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 11 23:37:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07235; Mon, 11 Nov 96 23:37:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07229; Mon, 11 Nov 96 23:37:08 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA22235; Mon, 11 Nov 1996 23:30:06 -0800 Received: from mailgate.aist-nara.ac.jp (fsb1.aist-nara.ac.jp [163.221.76.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id XAA23209 for ; Mon, 11 Nov 1996 23:30:06 -0800 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.198.61]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with ESMTP id QAA14644 for ; Tue, 12 Nov 1996 16:30:04 +0900 Received: from mine.aist-nara.ac.jp by mine.aist-nara.ac.jp (8.7.3/2.7W-AIST/1.3) id HAA08212; Tue, 12 Nov 1996 07:31:08 GMT To: ipng@sunroof.eng.sun.com Subject: (IPng 2448) Re: BSD API - ipv6_mreq In-Reply-To: Your message of "Mon, 11 Nov 96 20:00:18 -0500" References: <9611120100.AA14099@wasted.zk3.dec.com> X-Mailer: Mew version 1.50+2 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 12 Nov 1996 16:31:08 +0900 Message-Id: <8209.847783868@mine.aist-nara.ac.jp> From: Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, From: bound@zk3.dec.com Subject: (IPng 2445) Re: BSD API - ipv6_mreq Date: Mon, 11 Nov 96 20:00:18 -0500 > You convinced me its a problem. > > I prefer we do something to make all link-local addresses unique. That's why WIDE project proposed an interface index for "struct sockaddr_in6". IPv6 working group members of WIDE project found a better solution. In stead of the interface index in sockaddr_in6, we encode an interface index within in in6_addr. We assume that link-local addresses are unique on the same link but not unique on one node. Interface indices are node-unique. Applications can specify an outgoing interface with a link-local address which encodes the interface index. The kernel sends packets through the interface without the interface index(i.e. non-node-unique yet link-unique address). In this point, this approach is different from IID. When the kernel receives packets, it tells the applications with the link-local address which encodes the incoming interface index. One of implementation advantages is that interface-dependent information (such as NDP and link-local direct routes for each interface) can be contained in the (global) routing table since we give link-local addresses a total order. An open question is which octets of link-local address should we assign for interface index. Some suggested s6addr[2] and [3]. Others sugguested s6addr[4-7]. This is a small problem for link-local multicast address since it doesn't assume such structure. (But we can change.) --Kazu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 12 03:45:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07324; Tue, 12 Nov 96 03:45:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07318; Tue, 12 Nov 96 03:44:51 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA02653; Tue, 12 Nov 1996 03:37:49 -0800 Received: from merit.edu (merit.edu [35.1.1.42]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA28063 for ; Tue, 12 Nov 1996 03:37:50 -0800 Received: from herman.merit.edu (masaki@herman.merit.edu [198.108.60.143]) by merit.edu (8.7.6/merit-2.0) with SMTP id GAA07554; Tue, 12 Nov 1996 06:37:45 -0500 (EST) Message-Id: <199611121137.GAA07554@merit.edu> To: Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2449) Re: BSD API - ipv6_mreq In-Reply-To: Your message of "Tue, 12 Nov 1996 16:31:08 +0900." <8209.847783868@mine.aist-nara.ac.jp> Date: Tue, 12 Nov 1996 06:37:44 -0500 From: Masaki Hirabaru Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kazu, > We assume that link-local addresses are unique on the same link but > not unique on one node. Interface indices are > node-unique. Applications can specify an outgoing interface with a > link-local address which encodes the interface index. The kernel sends > packets through the interface without the interface > index(i.e. non-node-unique yet link-unique address). In this point, > this approach is different from IID. When the kernel receives > packets, it tells the applications with the link-local address which > encodes the incoming interface index. My understanding is your are proposing API, not an IPv6 link-local addressing scheme like IID. In your proposal, IPv6 link-local address is the same as now, but the API defines usage of some part of 128 bit address for specifying an index instead of using an independent strage. An application puts an interface index to be used into unused (0s) part of an ipv6 link-local address and passes it to the kernel. Then, the kernel strips off the index when sending out. On receiving, the kernel puts an interface index being received into an ipv6 link-local address and passes it to the application. Then, the application strips off the index when using it as an ipv6 address. Some kernel internals and applications may use this 128 bit value as it is. My question is how an application can specify the outgoing interface when sending to a link-local multicast address. There is no space for an index without changing RFC 1884... Thanks. Masaki ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 12 04:10:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07336; Tue, 12 Nov 96 04:10:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07330; Tue, 12 Nov 96 04:10:38 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA03582; Tue, 12 Nov 1996 04:03:36 -0800 Received: from mailgate.aist-nara.ac.jp (fsb1.aist-nara.ac.jp [163.221.76.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA01032 for ; Tue, 12 Nov 1996 04:03:36 -0800 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.198.61]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with ESMTP id VAA06220 for ; Tue, 12 Nov 1996 21:03:34 +0900 Received: from mine.aist-nara.ac.jp by mine.aist-nara.ac.jp (8.7.3/2.7W-AIST/1.3) id MAA08466; Tue, 12 Nov 1996 12:04:34 GMT To: ipng@sunroof.eng.sun.com Subject: (IPng 2450) Re: BSD API - ipv6_mreq In-Reply-To: Your message of "Tue, 12 Nov 1996 06:37:44 -0500" References: <199611121137.GAA07554@merit.edu> X-Mailer: Mew version 1.50+2 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 12 Nov 1996 21:04:29 +0900 Message-Id: <8461.847800269@mine.aist-nara.ac.jp> From: Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hirabaru-san, From: Masaki Hirabaru Subject: Re: (IPng 2448) Re: BSD API - ipv6_mreq Date: Tue, 12 Nov 1996 06:37:44 -0500 > My understanding is your are proposing API, not an IPv6 > link-local addressing scheme like IID. In your proposal, IPv6 > link-local address is the same as now, but the API defines usage > of some part of 128 bit address for specifying an index instead > of using an independent strage. Yes and no. We proposed API but we need to change the scheme to reserve some octes for both link-local used unicast address and link-local scope multicast address. > An application puts an interface index to be used into unused > (0s) part of an ipv6 link-local address and passes it to the > kernel. Then, the kernel strips off the index when sending > out. On receiving, the kernel puts an interface index being > received into an ipv6 link-local address and passes it to the > application. Then, the application strips off the index when > using it as an ipv6 address. Yes! > My question is how an application can specify the outgoing > interface when sending to a link-local multicast address. There > is no space for an index without changing RFC 1884... Thanks. So I said that is a small problem for multicast. Again, we need to reserve some bytes(probably s6addr[2] and [3]) for API use. --Kazu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 12 04:13:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07348; Tue, 12 Nov 96 04:13:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07342; Tue, 12 Nov 96 04:13:12 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA03790; Tue, 12 Nov 1996 04:06:10 -0800 Received: from oberon.di.fc.ul.pt (oberon.di.fc.ul.pt [192.67.76.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA01435 for ; Tue, 12 Nov 1996 04:06:08 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id LAA14650; Tue, 12 Nov 1996 11:59:29 GMT Date: Tue, 12 Nov 1996 11:59:29 GMT Message-Id: <199611121159.LAA14650@oberon.di.fc.ul.pt> From: Pedro Roque To: Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2451) Re: BSD API - ipv6_mreq In-Reply-To: <8209.847783868@mine.aist-nara.ac.jp> References: <9611120100.AA14099@wasted.zk3.dec.com> <8209.847783868@mine.aist-nara.ac.jp> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Kazu" == Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= writes: Kazu> Jim, From: bound@zk3.dec.com Subject: (IPng 2445) Re: BSD Kazu> API - ipv6_mreq Date: Mon, 11 Nov 96 20:00:18 -0500 >> You convinced me its a problem. >> >> I prefer we do something to make all link-local addresses >> unique. Kazu> That's why WIDE project proposed an interface index for Kazu> "struct sockaddr_in6". Kazu> IPv6 working group members of WIDE project found a better Kazu> solution. "better" is always a relative term. Kazu> In stead of the interface index in sockaddr_in6, Kazu> we encode an interface index within in in6_addr. Kazu> We assume that link-local addresses are unique on the same Kazu> link but not unique on one node. Interface indices are Kazu> node-unique. Applications can specify an outgoing interface Kazu> with a link-local address which encodes the interface Kazu> index. The kernel sends packets through the interface Kazu> without the interface index(i.e. non-node-unique yet Kazu> link-unique address). So the kernel rewrites addresses ? Kazu> In this point, this approach is Kazu> different from IID. When the kernel receives packets, it Kazu> tells the applications with the link-local address which Kazu> encodes the incoming interface index. What address does the kernel rewrite ? The receiving interface link local address ? What about on sending ? Kazu> One of implementation advantages is that interface-dependent Kazu> information (such as NDP and link-local direct routes for Kazu> each interface) can be contained in the (global) routing Kazu> table since we give link-local addresses a total order. The implementation i'm working on has direct routes in the routing table without the need for address rewrite tricks. So it can be done without it. Kazu> An open question is which octets of link-local address Kazu> should we assign for interface index. Some suggested Kazu> s6addr[2] and [3]. Others sugguested s6addr[4-7]. This is a Kazu> small problem for link-local multicast address since it Kazu> doesn't assume such structure. (But we can change.) This is a big "open question". Personally i consider that rewriting addresses is a very ugly way to do things and that passing an additional int is better. regards, ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 12 06:05:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07411; Tue, 12 Nov 96 06:05:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07405; Tue, 12 Nov 96 06:05:30 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA09809; Tue, 12 Nov 1996 05:58:27 -0800 Received: from mailgate.aist-nara.ac.jp (fsb1.aist-nara.ac.jp [163.221.76.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA24944 for ; Tue, 12 Nov 1996 05:58:28 -0800 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.198.61]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with ESMTP id WAA15301; Tue, 12 Nov 1996 22:58:26 +0900 Received: from mine.aist-nara.ac.jp by mine.aist-nara.ac.jp (8.7.3/2.7W-AIST/1.3) id NAA08575; Tue, 12 Nov 1996 13:59:30 GMT To: roque@di.fc.ul.pt Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2452) Re: BSD API - ipv6_mreq In-Reply-To: Your message of "Tue, 12 Nov 1996 11:59:29 GMT" References: <199611121159.LAA14650@oberon.di.fc.ul.pt> X-Mailer: Mew version 1.50+2 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 12 Nov 1996 22:59:29 +0900 Message-Id: <8572.847807169@mine.aist-nara.ac.jp> From: Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pedro, From: Pedro Roque Subject: (IPng 2448) Re: BSD API - ipv6_mreq Date: Tue, 12 Nov 1996 11:59:29 GMT > Kazu> In this point, this approach is > Kazu> different from IID. When the kernel receives packets, it > Kazu> tells the applications with the link-local address which > Kazu> encodes the incoming interface index. > > What address does the kernel rewrite ? > The receiving interface link local address ? > What about on sending ? On both sending and receiving, the kernel rewrites link-local addresses from the point of application view. Probably, Hirabaru-san's message is more readable. Please refer to it. > Kazu> One of implementation advantages is that interface-dependent > Kazu> information (such as NDP and link-local direct routes for > Kazu> each interface) can be contained in the (global) routing > Kazu> table since we give link-local addresses a total order. > > The implementation i'm working on has direct routes in the routing table > without the need for address rewrite tricks. So it can be done without it. I'm talking about API for BSD. For BSD routing table, how do you make keys(i.e. destination prefixes) unique? I'm very curious. Would you explain it? --Kazu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 12 06:15:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07426; Tue, 12 Nov 96 06:15:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07420; Tue, 12 Nov 96 06:15:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA10539; Tue, 12 Nov 1996 06:08:34 -0800 Received: from oberon.di.fc.ul.pt (oberon.di.fc.ul.pt [192.67.76.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA27606 for ; Tue, 12 Nov 1996 06:08:19 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id OAA15037; Tue, 12 Nov 1996 14:02:13 GMT Date: Tue, 12 Nov 1996 14:02:13 GMT Message-Id: <199611121402.OAA15037@oberon.di.fc.ul.pt> From: Pedro Roque To: Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Cc: roque@di.fc.ul.pt, ipng@sunroof.eng.sun.com Subject: (IPng 2453) Re: BSD API - ipv6_mreq In-Reply-To: <8572.847807169@mine.aist-nara.ac.jp> References: <199611121159.LAA14650@oberon.di.fc.ul.pt> <8572.847807169@mine.aist-nara.ac.jp> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Kazu" == Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= writes: Kazu> One of implementation advantages is that interface-dependent Kazu> information (such as NDP and link-local direct routes for Kazu> each interface) can be contained in the (global) routing Kazu> table since we give link-local addresses a total order. >> The implementation i'm working on has direct routes in the >> routing table without the need for address rewrite tricks. So >> it can be done without it. Kazu> I'm talking about API for BSD. For BSD routing table, how do Kazu> you make keys(i.e. destination prefixes) unique? I'm very Kazu> curious. Would you explain it? Going complelty off-topic for the IPng WG list, Just do things such that your lookup key is (addr, iid) - I use a pointer to the device struct as internal iid. You don't need to make the internal tree depend on such key either as you can have multiple routes in a tree node and then do a linear search with the device part of the key. The advantage is that your can extend this aproach to non link local addresses (where you can't just rewrite some random bits) and have searches where the outgoing device is either advisory or mandatory. The code is freely availiable in case you are interested. ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 12 09:18:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07570; Tue, 12 Nov 96 09:18:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07564; Tue, 12 Nov 96 09:17:55 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA03220; Tue, 12 Nov 1996 09:10:53 -0800 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA26018 for ; Tue, 12 Nov 1996 09:10:51 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <19259(7)>; Tue, 12 Nov 1996 09:10:30 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 12 Nov 1996 09:09:43 PST To: thartric@mentat.com (Tim Hartrick) Cc: fenner@parc.xerox.com, ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 2454) Re: BSD API - ipv6_mreq In-Reply-To: thartric's message of Mon, 11 Nov 96 18:25:14 -0800. <199611120225.SAA00683@feller.mentat.com> Date: Tue, 12 Nov 1996 09:09:42 PST From: Steve Deering Message-Id: <96Nov12.090943pst."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Sure. The socket API's used for interface identification in IPv4 uses > addresses to identify the interface. As many people have pointed out, > including the original author of these interfaces, this is an imperfect > solution for IPv4 because of unnumbered interfaces. Unfortunately, we > are kind of stuck with it because there is code already out there. I haven't been able to keep up with all the ipng discussion and drafts lately, due to job-change hassles, etc., but I'd just like to confirm what Tim said above. I designed the BSD multicast API, and I have since concluded that the use of IP addresses to identify the interface on which join/leave operations are performed was a mistake. It prevents joining on unnumbered interfaces and tunnel-endpoints, and ambiguizes [new word] joining on not-separately-numbered interfaces. I wish I had used some sort of local interface ID, such as "le0"-style strings or a short integer index. It would be a shame not to fix that for IPv6. Bill Fenner tells me that 4.4BSD introduced local interface IDs as a new address family called AF_LINK, which supports both "le0"-style names and small integer indexes. Is that what the enhanced IPv6 API is using for interface identification? If not, why not? Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 12 09:26:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07601; Tue, 12 Nov 96 09:26:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07595; Tue, 12 Nov 96 09:26:39 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA04970; Tue, 12 Nov 1996 09:19:37 -0800 From: bound@ZK3.DEC.COM Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA29408 for ; Tue, 12 Nov 1996 09:19:35 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id MAA12376; Tue, 12 Nov 1996 12:05:22 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA04155; Tue, 12 Nov 1996 12:05:28 -0500 Message-Id: <9611121705.AA04155@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2455) Re: BSD API - ipv6_mreq In-Reply-To: Your message of "Mon, 11 Nov 96 18:25:14 PST." <199611120225.SAA00683@feller.mentat.com> Date: Tue, 12 Nov 96 12:05:27 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, >> >> If the API works on all systems and they interoperate then the API is in >> fact portable. How you make it work underneath is an implementation >> issue. In Pedro's last mail he stated its an API problem but I maintain >> the problem is that we have not made sure the link-local address is >> unique all the time on a node which Kre's draft in fact does. >> >There is interoperability and then there is the behavior of the API. >If one implementation registers the group on a single interface and >another registers the group on multiple interfaces (with the same >link local address) then the application will behave differently on >the two implementations. The first system will only receive packets >from a single interface. The other system will receive packets from >multiple interfaces. I think most application writers would view >this as an unacceptable deviation in behavior even though the two >systems may interoperate just fine. I wouldn't. As long as the end result is achieved and portability is maintained with interoperability I pretty much think a standards group has done its job. >Of course KRE's draft would guarantee link-local address uniqueness >and alleviate the problem. Yep. It would. >What cheap shot? I was asking a valid question. It was the misleading comment. I took it to be you stated I was being misleading on purpose. Words and where they are put is so critical to keep things friendly via email. I know its hard and I have to work at it too. >> >> Another cheap shot. #1 no one stated we should change the in6_pktinfo so I >> don't know what your talking about. #2 if you want to join a multicast >> group and as a side effect your implementation does it on multiple >> interfaces "on different links" then thats not bad. #3 the question is >> should the in6_pktinfo be used is on the table? So I am not sure how >> you ended up on the above thread? > >> > I was assuming you wanted something like the following (from the >> > advanced api spec): >> > >> > struct in6_pktinfo { >> > int ipi6_ifindex; /* interface index */ >> > struct in6_addr ipi6_addr; /* IPv6 address */ >> > }; >> > >> > Is that clearer? >> > >> > If we do this that changes the behavior of how multicast apps are done >> > today. It also prevents me from assuming an address for join will >> > include multiple interfaces simply by the address per my implementation >> > trickery or finess how ever you choose to speak of us captitalist >> > pigs )->;. >> > >Hmm... I think you are being a little sensitive. You are the one that >placed the in6_pktinfo structure in your mail. You also made the statement >that you would lose the ability to register a group on multiple interfaces >simultaneously if the ipv6 mreq structure changed. I simply wanted to >point out that no one has claimed to be dependent on that feature of the >ipv6 mreq structure so we probably should not worry too much about losing >that capability until someone does. I know. Some on this list have made me very sensitive. This has gotten totally confused and not what I stated but can see how that was construed from my words now. I was saying (I think we are past this now though) that if I have to specify an index with the address I loose the ability to just specify an address as today in IPv4 and let my implementation deal with the multiple interface issues. In other words it would happen automatically in my kernel when sending out the multicast join. >> Can you say that in more detail and be specific? I think I agree with >> you but I am not sure? >Sure. The socket API's used for interface identification in IPv4 uses >addresses to identify the interface. As many people have pointed out, >including the original author of these interfaces, this is an imperfect >solution for IPv4 because of unnumbered interfaces. Unfortunately, we >are kind of stuck with it because there is code already out there. I have no problem changing existing apps if they will perform and be more robust or telling my customers this is what is needed to get to IPv6. In most cases they won't care IMO or the ISVs as long as I do the following: 1. If they don't take advantage of IPv6 New Features the application can run via a knob over IPv6 or IPv4. ISVs won't want to ship two different versions of an application on a platform unless>>> 2. All bets are off if you want to use the new features in IPv6 like Flows, Addr Conf, Dynamic Renumbering, Advanced API spec features etc... >So what do we do for IPv6. The choices are: >1) Use addresses to identify interfaces just like we do in IPv4. > > There is consistency between IPv6 and IPv4 API's. Since every > IPv6 interface can have a unique link-local address (see KRE's > draft) we don't have the IPv4 unnumbered interface problem. >2) Use an interface index type thing to identify interfaces. > This solution works but is not consistent with the IPv4 API's. > >3) Use a mix of both 1) and 2). (This is what we have now). > This is the worst of both worlds in my opinion. We need KRE's > draft to solve the link local uniqueness problem but application > writers also get a second incompatible mechanism for identifying > interfaces. They use the old style address based mechanism when > registering for multicast groups and they get the new style index > base mechanism when sending or receiving packets. This dichotomy > seems unnecessary since we have a pretty clean slate to work with > in IPv6 API area. >My hope would be that we could settle on 1) or 2). I vote for number 1. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 12 09:50:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07676; Tue, 12 Nov 96 09:50:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07670; Tue, 12 Nov 96 09:49:50 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA09182; Tue, 12 Nov 1996 09:42:48 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA08105 for ; Tue, 12 Nov 1996 09:42:48 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.2/8.7.3) with SMTP id KAA03691; Tue, 12 Nov 1996 10:42:47 -0700 (MST) Received: by kohala.kohala.com (SMI-8.6/SMI-SVR4) id KAA03461; Tue, 12 Nov 1996 10:42:41 -0700 Message-Id: <199611121742.KAA03461@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Tue, 12 Nov 1996 10:42:41 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Steve Deering , thartric@mentat.com (Tim Hartrick) Subject: (IPng 2456) Re: BSD API - ipv6_mreq Cc: fenner@parc.xerox.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Nov 12, 9:09am you write:] > > I designed the BSD multicast API, and I have since > concluded that the use of IP addresses to identify the interface on which > join/leave operations are performed was a mistake. It prevents joining on > unnumbered interfaces and tunnel-endpoints, and ambiguizes [new word] > joining on not-separately-numbered interfaces. I wish I had used some sort > of local interface ID, such as "le0"-style strings or a short integer index. > It would be a shame not to fix that for IPv6. Then I think we should change the basic IPv6 API to use indexes instead of IP addresses for multicast joins and drops. This also implies that the SIOCGIFINDEX ioctl should be moved from the advanced API to the basic API. > Bill Fenner tells me that 4.4BSD introduced local interface IDs as a new > address family called AF_LINK, which supports both "le0"-style names and > small integer indexes. Is that what the enhanced IPv6 API is using for > interface identification? If not, why not? A datalink socket address structure (sockaddr_dl{}) has a family of AF_LINK and then contains the index, interface type, interface name (e.g., "le0"), and the Ethernet address (for Ethernet devices, at least). The advanced API is using only the index to identify the interface, currently to identify the receiving interface and to specify the sending interface. Given the interface name, the SIOCGIFINDEX ioctl returns the index. Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 12 10:05:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07716; Tue, 12 Nov 96 10:05:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07710; Tue, 12 Nov 96 10:05:26 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA12148; Tue, 12 Nov 1996 09:58:24 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA12398 for ; Tue, 12 Nov 1996 09:58:12 -0800 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id MAA14976; Tue, 12 Nov 1996 12:43:55 -0500 (EST) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA03519; Tue, 12 Nov 1996 12:43:40 -0500 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id NAA02231; Tue, 12 Nov 1996 13:49:37 GMT Message-Id: <199611121349.NAA02231@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2457) Re: BSD API - ipv6_mreq In-Reply-To: Your message of "Tue, 12 Nov 1996 09:09:42 PST." <96Nov12.090943pst."75270"@digit.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Nov 1996 13:49:35 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In <96Nov12.090943pst."75270"@digit.parc.xerox.com> , you wrote: > [...snip...] I wish I had used some sort > of local interface ID, such as "le0"-style strings or a short integer index. > It would be a shame not to fix that for IPv6. > > Bill Fenner tells me that 4.4BSD introduced local interface IDs as a new > address family called AF_LINK, which supports both "le0"-style names and > small integer indexes. Is that what the enhanced IPv6 API is using for > interface identification? If not, why not? the advanced API spec uses small integer indexes. While a AF_LINK sockaddr could have been used, it requires ~24 bytes of information to be copied whereas a small index uses 4. The API contains ways of converting a "name" to an index (and back). -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 12 10:06:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07723; Tue, 12 Nov 96 10:06:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07717; Tue, 12 Nov 96 10:05:53 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA12238; Tue, 12 Nov 1996 09:58:50 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA12454 for ; Tue, 12 Nov 1996 09:58:23 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id MAA15586; Tue, 12 Nov 1996 12:40:49 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA09576; Tue, 12 Nov 1996 12:40:40 -0500 Message-Id: <9611121740.AA09576@wasted.zk3.dec.com> To: Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2458) Re: BSD API - ipv6_mreq In-Reply-To: Your message of "Tue, 12 Nov 96 16:31:08 +0900." <8209.847783868@mine.aist-nara.ac.jp> Date: Tue, 12 Nov 96 12:40:39 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kazu, >> You convinced me its a problem. >> >> I prefer we do something to make all link-local addresses unique. >That's why WIDE project proposed an interface index for "struct >sockaddr_in6". Well I believe indexes are an implementation thingee and reporting or getting at them should not be a field in the sockaddr_in6 struct but done as specified in the recent Advanced API spec just released. Regarding making the Link-Local addresses unique I think Kre's proposal does that just fine. So its two problems I think we are discussing not one. >We assume that link-local addresses are unique on the same link but >not unique on one node. Interface indices are >node-unique. Applications can specify an outgoing interface with a >link-local address which encodes the interface index. The kernel sends >packets through the interface without the interface >index(i.e. non-node-unique yet link-unique address). In this point, >this approach is different from IID. When the kernel receives >packets, it tells the applications with the link-local address which >encodes the incoming interface index. OK. I just think Kre's is a better solution. Its more elegant in the sense it defines the address for the complete system not just for an applicaiton like sockets. Also as Pedro pointed out I too am not comfortable with a solution that requires me to alter the in6_addr in my kernel via a rewrite. This is also a performance hit in the kernel and can affect the protocol control blocks being rewritten that were set up at the point the socket is passed to kernel space from user space. This also means I think a routing table change in some cases which causes the routing table to be updated not because of a change in the state of the network but because an application has selected an indice for the address to be used. This can affect greatly a fined grained SMP implementation of an IPv6 stack regarding locking mechanisms. Kre's proposal does not cause this as the link-local address is defined during duplicate address detection and is complete within the entire stack implementation once its defined. >One of implementation advantages is that interface-dependent >information (such as NDP and link-local direct routes for each >interface) can be contained in the (global) routing table since we >give link-local addresses a total order. I would not suggest implementing inherent knowlege of interfaces this way in the routing table. I can see the thinking during the search on a patricia tree search but that is IMO overloading a data structure for its not intended purpose. This forces an addresses to an interface in a way that interferes with the purity of what an address is. The interface can be a leaf off the address that is not searched but just used and then an address can be used for multiple interfaces if an implementaiton deems that an advantage. Even with Kre's proposal. >An open question is which octets of link-local address should we >assign for interface index. Some suggested s6addr[2] and [3]. Others >sugguested s6addr[4-7]. This is a small problem for link-local >multicast address since it doesn't assume such structure. (But we can >change.) I am really "pro" Kre' solution and using the advanced API draft to use interface indexes. I think it more useful over all. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 12 10:07:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07730; Tue, 12 Nov 96 10:07:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07531; Tue, 12 Nov 96 08:25:05 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA24288; Tue, 12 Nov 1996 08:18:04 -0800 Received: from gta.ufrj.br (buzios.gta.ufrj.br [146.164.53.71]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA06806 for ; Tue, 12 Nov 1996 08:18:03 -0800 Received: (from emerson@localhost) by gta.ufrj.br (8.7.4/8.7.3) id OAA10966; Tue, 12 Nov 1996 14:17:19 -0200 (EDT) Date: Tue, 12 Nov 1996 14:17:19 -0200 (EDT) From: Emerson Carli Message-Id: <199611121617.OAA10966@gta.ufrj.br> To: ipng@sunroof.eng.sun.com Subject: (IPng 2459) Help on IPv6 Cc: emerson@gta.ufrj.br X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My name is Emerson Carli and I am a M.Sc student at GTA/COPPE/UFRJ,Brazil. My research interests focus on the Internet Protocol version 6 (IPv6), specially on its quality of sevice capabilities over ATM. However, I am having some trouble in get documentation of this protocol with respect to its PDU's formats, its primitives and so on. Does anybody know where can I get this documentation? I have already gotten the IPv6 specification, but it describes only the IPv6 header, the expansion headers, security and authentication headers... Thanks for your attention. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 12 10:10:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07767; Tue, 12 Nov 96 10:10:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07761; Tue, 12 Nov 96 10:10:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA13190; Tue, 12 Nov 1996 10:03:32 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA14534 for ; Tue, 12 Nov 1996 10:03:31 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id MAA26927; Tue, 12 Nov 1996 12:58:02 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14272; Tue, 12 Nov 1996 12:58:04 -0500 Message-Id: <9611121758.AA14272@wasted.zk3.dec.com> To: Steve Deering Cc: thartric@mentat.com (Tim Hartrick), fenner@parc.xerox.com, ipng@sunroof.eng.sun.com Subject: (IPng 2460) Re: BSD API - ipv6_mreq In-Reply-To: Your message of "Tue, 12 Nov 96 09:09:42 PST." <96Nov12.090943pst."75270"@digit.parc.xerox.com> Date: Tue, 12 Nov 96 12:58:03 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >Bill Fenner tells me that 4.4BSD introduced local interface IDs as a new >address family called AF_LINK, which supports both "le0"-style names and >small integer indexes. Is that what the enhanced IPv6 API is using for >interface identification? If not, why not? Yes it assumes these new mechanisms. But provides a means for non 4.4BSD mechanisms to use it too. This is discussed in the draft. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 12 10:43:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07868; Tue, 12 Nov 96 10:43:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07862; Tue, 12 Nov 96 10:42:59 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA19809; Tue, 12 Nov 1996 10:35:56 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA27404 for ; Tue, 12 Nov 1996 10:35:57 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA27756; Tue, 12 Nov 1996 13:26:33 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA19367; Tue, 12 Nov 1996 13:26:34 -0500 Message-Id: <9611121826.AA19367@wasted.zk3.dec.com> To: "W. Richard Stevens" Cc: Steve Deering , thartric@mentat.com (Tim Hartrick), fenner@parc.xerox.com, ipng@sunroof.eng.sun.com Subject: (IPng 2461) Re: BSD API - ipv6_mreq In-Reply-To: Your message of "Tue, 12 Nov 96 10:42:41 MST." <199611121742.KAA03461@kohala.kohala.com> Date: Tue, 12 Nov 96 13:26:33 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, >Then I think we should change the basic IPv6 API to use indexes instead >of IP addresses for multicast joins and drops. This also implies that the >SIOCGIFINDEX ioctl should be moved from the advanced API to the basic API. This is where it appears rough consensus is headed and moving to the base API seems appropriate. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 12 10:52:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07906; Tue, 12 Nov 96 10:52:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07900; Tue, 12 Nov 96 10:51:51 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA21584; Tue, 12 Nov 1996 10:44:49 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA03628 for ; Tue, 12 Nov 1996 10:44:50 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA16960; Tue, 12 Nov 96 10:25:21 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id KAA02168; Tue, 12 Nov 1996 10:26:10 -0800 Date: Tue, 12 Nov 1996 10:26:10 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199611121826.KAA02168@feller.mentat.com> To: bound@zk3.dec.com Subject: (IPng 2462) Re: BSD API - ipv6_mreq Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > >1) Use addresses to identify interfaces just like we do in IPv4. > > > > There is consistency between IPv6 and IPv4 API's. Since every > > IPv6 interface can have a unique link-local address (see KRE's > > draft) we don't have the IPv4 unnumbered interface problem. > > >2) Use an interface index type thing to identify interfaces. > > > This solution works but is not consistent with the IPv4 API's. > > > >3) Use a mix of both 1) and 2). (This is what we have now). > > > This is the worst of both worlds in my opinion. We need KRE's > > draft to solve the link local uniqueness problem but application > > writers also get a second incompatible mechanism for identifying > > interfaces. They use the old style address based mechanism when > > registering for multicast groups and they get the new style index > > base mechanism when sending or receiving packets. This dichotomy > > seems unnecessary since we have a pretty clean slate to work with > > in IPv6 API area. > > >My hope would be that we could settle on 1) or 2). > > I vote for number 1. > Just to clearify. You are saying that you would like link-local addresses to be used to identify interfaces. This includes changing the advanced API specification to use addresses instead of interface indexes. Is that what you are saying? Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 12 11:10:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07996; Tue, 12 Nov 96 11:10:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07986; Tue, 12 Nov 96 11:10:46 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA25457; Tue, 12 Nov 1996 11:03:43 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA11274 for ; Tue, 12 Nov 1996 11:03:28 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA17198; Tue, 12 Nov 96 11:02:18 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id LAA02251; Tue, 12 Nov 1996 11:03:06 -0800 Date: Tue, 12 Nov 1996 11:03:06 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199611121903.LAA02251@feller.mentat.com> To: bound@zk3.dec.com Subject: (IPng 2463) Re: BSD API - ipv6_mreq Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > >Then I think we should change the basic IPv6 API to use indexes instead > >of IP addresses for multicast joins and drops. This also implies that the > >SIOCGIFINDEX ioctl should be moved from the advanced API to the basic API. > > This is where it appears rough consensus is headed and moving to the base > API seems appropriate. > I am not convinced that is where consensus is headed. In general I would prefer that interfaces be identified using addresses. Since we can solve the uniqueness problem this mechanism does not have the same problems in the IPv6wworld as it does in the IPv4 world. However, my overriding concern is that we specify a uniform mechanism for interface identification. If it is addresses great. If it is indexes I can live with that. If it is some other identifier like the name or the slot number or.... that is probably OK as well. Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 12 13:20:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08292; Tue, 12 Nov 96 13:20:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08286; Tue, 12 Nov 96 13:20:25 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA18978; Tue, 12 Nov 1996 13:13:23 -0800 Received: from netmail1.austin.ibm.com (netmail1.austin.ibm.com [129.35.208.96]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA01407 for ; Tue, 12 Nov 1996 13:12:42 -0800 Received: from mojave.austin.ibm.com (mojave.austin.ibm.com [129.35.56.14]) by netmail1.austin.ibm.com (8.6.12/8.6.11) with ESMTP id PAA28307 for ; Tue, 12 Nov 1996 15:11:46 -0600 Received: from loopback (loopback [127.0.0.1]) by mojave.austin.ibm.com (AIX4.2/UCB 8.7/8.7-client1.0) with SMTP id PAA39886 for ; Tue, 12 Nov 1996 15:11:45 -0600 (CST) Message-Id: <199611122111.PAA39886@mojave.austin.ibm.com> X-Authentication-Warning: mojave.austin.ibm.com: Host loopback [127.0.0.1] didn't use HELO protocol X-Mailer: exmh version 1.6.9 8/22/96 To: ipng@sunroof.eng.sun.com Reply-To: swise@austin.ibm.com Subject: (IPng 2464) IPv6 on AIX Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Nov 1996 15:11:45 -0600 From: Steve Wise Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fellow IPv6ers, IBM Austin has made our IPv6 AIX prototype available for experimentation. You can download the first release of the prototype at: http://www.austin.ibm.com/ipv6 ******** Steve Wise IBM RISC System/6000 Division - Austin, TX. Internet: swise@austin.ibm.com VNET: AUSTIN(SWISE) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 12 13:53:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08366; Tue, 12 Nov 96 13:53:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08359; Tue, 12 Nov 96 13:53:23 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA25180; Tue, 12 Nov 1996 13:46:20 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA13374 for ; Tue, 12 Nov 1996 13:46:16 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA09188; Tue, 12 Nov 1996 16:33:29 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA31385; Tue, 12 Nov 1996 16:33:36 -0500 Message-Id: <9611122133.AA31385@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2465) Re: BSD API - ipv6_mreq In-Reply-To: Your message of "Tue, 12 Nov 96 10:26:10 PST." <199611121826.KAA02168@feller.mentat.com> Date: Tue, 12 Nov 96 16:33:35 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, > > >1) Use addresses to identify interfaces just like we do in IPv4. > > > > There is consistency between IPv6 and IPv4 API's. Since every > > IPv6 interface can have a unique link-local address (see KRE's > > draft) we don't have the IPv4 unnumbered interface problem. > > >2) Use an interface index type thing to identify interfaces. > > > This solution works but is not consistent with the IPv4 API's. > > > >3) Use a mix of both 1) and 2). (This is what we have now). > > > This is the worst of both worlds in my opinion. We need KRE's > > draft to solve the link local uniqueness problem but application > > writers also get a second incompatible mechanism for identifying > > interfaces. They use the old style address based mechanism when > > registering for multicast groups and they get the new style index > > base mechanism when sending or receiving packets. This dichotomy > > seems unnecessary since we have a pretty clean slate to work with > > in IPv6 API area. > > >My hope would be that we could settle on 1) or 2). > > I vote for number 1. > >Just to clearify. You are saying that you would like link-local >addresses to be used to identify interfaces. This includes changing >the advanced API specification to use addresses instead of interface >indexes. > >Is that what you are saying? No. If we are to bring in the Advanced API spec piece to make it work in the base spec then I think #2 is a better approach. I did not think this was an option but it appears it is. Using an index is superior for the general interface identifier problem. I still believe Kre's draft is useful though, for reasons other than this discussion. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Nov 13 17:58:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09536; Wed, 13 Nov 96 17:58:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09530; Wed, 13 Nov 96 17:58:29 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA05735; Wed, 13 Nov 1996 17:51:25 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA27817 for ; Wed, 13 Nov 1996 17:51:25 -0800 Received: from redwood.ipsilon.com (redwood.Ipsilon.COM [205.226.8.238]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id RAA11103 for ; Wed, 13 Nov 1996 17:51:23 -0800 Message-Id: <3.0.32.19961113174925.006b1988@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 13 Nov 1996 17:49:43 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 2466) W.G. Last Call on "Generic Packet Tunneling in IPv6 Specification" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is an ipng working group last call for comments on advancing the following document to Proposed Standard: Title : Generic Packet Tunneling in IPv6 Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-ipv6-tunnel-04.txt Pages : 35 Date : 10/31/1996 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end one weeks from today, on 11/20/96. Bob Hinden / Steve Deering ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Nov 14 01:14:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09860; Thu, 14 Nov 96 01:14:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09854; Thu, 14 Nov 96 01:13:51 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA23402; Thu, 14 Nov 1996 01:06:47 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA06494 for ; Thu, 14 Nov 1996 01:06:46 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id KAA01033; Thu, 14 Nov 1996 10:06:44 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA19750; Thu, 14 Nov 1996 10:06:44 +0100 Message-Id: <9611140906.AA19750@dxcoms.cern.ch> Subject: (IPng 2467) Re: W.G. Last Call on "Generic Packet Tunneling in IPv6 To: hinden@ipsilon.com (Bob Hinden) Date: Thu, 14 Nov 1996 10:06:44 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3.0.32.19961113174925.006b1988@mailhost.ipsilon.com> from "Bob Hinden" at Nov 13, 96 05:49:43 pm 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 Hi, There are at least a couple of reasons why this document will not get through the IESG as a PS in its present form. 1. There is some "shall, should, may" terminology included but the "definition of terms" section does not specify the usual macro expansions of these words. This may seem fiddly but it's something the IESG looks for. 2. The security considerations section does not pass muster. Nothing gets on the standards track without a real security analysis these days. Thanks for the ack, but one of my points hasn't made it, namely the issue of tunnels with an anycast address as their end point. I think it's sufficient to say "don't do this." Brian Carpenter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Nov 14 05:26:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09995; Thu, 14 Nov 96 05:26:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09989; Thu, 14 Nov 96 05:26:42 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA17904; Thu, 14 Nov 1996 05:19:37 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA13486 for ; Thu, 14 Nov 1996 05:19:38 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA19494; Thu, 14 Nov 1996 08:13:03 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA17745; Thu, 14 Nov 1996 08:13:11 -0500 Message-Id: <9611141313.AA17745@wasted.zk3.dec.com> To: "Brian Carpenter CERN-CN" Cc: hinden@ipsilon.com (Bob Hinden), ipng@sunroof.eng.sun.com Subject: (IPng 2468) Re: W.G. Last Call on "Generic Packet Tunneling in IPv6 In-Reply-To: Your message of "Thu, 14 Nov 96 10:06:44 +0100." <9611140906.AA19750@dxcoms.cern.ch> Date: Thu, 14 Nov 96 08:13:10 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I can't figure out why this would be a PS anyway. Why not a BCP or or Informational RFC. Also should this be run by Joel Halpburn in the Routing Area before it goes much further? Its just an explanation of tunnels and some conceptual discussion of the abstractions to use for tunnels. There is no recommendation for changes to the IP layer, services, etc? Its just describing how tunnels are done on a network. Once you add any MUSTs to this it woudl cause much more discussion. The discussion of hop limits is the only place that provides serious decisions that would affect implementations and I read those as suggestions too? Its a good piece of work I am just not clear what track it belongs on per the IETF rules on documents and their status? Its not a protocol specifiation? What is GRE classified at this point? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Nov 14 11:20:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10355; Thu, 14 Nov 96 11:20:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09908; Thu, 14 Nov 96 02:40:19 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA00018; Thu, 14 Nov 1996 02:33:15 -0800 Received: from gta.ufrj.br (buzios.gta.ufrj.br [146.164.53.71]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA20008 for ; Thu, 14 Nov 1996 02:33:14 -0800 Received: from lumiar.gta.ufrj.br (lumiar [146.164.53.83]) by gta.ufrj.br (8.7.4/8.7.3) with ESMTP id IAA04367 for ; Thu, 14 Nov 1996 08:32:13 -0200 (EDT) From: Emerson Carli Received: (from emerson@localhost) by lumiar.gta.ufrj.br (8.7.4/8.7.3) id IAA02303 for ipng@sunroof.eng.sun.com; Thu, 14 Nov 1996 08:33:19 -0200 (EDT) Date: Thu, 14 Nov 1996 08:33:19 -0200 (EDT) Message-Id: <199611141033.IAA02303@lumiar.gta.ufrj.br> To: ipng@sunroof.eng.sun.com Subject: (IPng 2469) Help on IPv6 X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My name is Emerson Carli and I am a M.Sc student at GTA/COPPE/UFRJ,Brazil. My research interests focus on the Internet Protocol version 6 (IPv6), specially on its quality of sevice capabilities over ATM. However, I am having some trouble in get documentation of this protocol with respect to its PDU's formats, its primitives and so on. Does anybody know where can I get this documentation? I have already gotten the IPv6 specification, but it describes only the IPv6 header, the expansion headers, security and authentication headers... Thanks for your attention. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Nov 14 16:04:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10901; Thu, 14 Nov 96 16:04:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10895; Thu, 14 Nov 96 16:04:17 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA24645; Thu, 14 Nov 1996 15:57:11 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA23196 for ; Thu, 14 Nov 1996 15:57:13 -0800 Received: from redwood.ipsilon.com (redwood.Ipsilon.COM [205.226.8.238]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id PAA17901; Thu, 14 Nov 1996 15:54:40 -0800 Message-Id: <3.0.32.19961114155402.006df05c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 14 Nov 1996 15:54:04 -0800 To: bound@zk3.dec.com From: Bob Hinden Subject: (IPng 2470) Re: W.G. Last Call on "Generic Packet Tunneling in IPv6 Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, >I can't figure out why this would be a PS anyway. Why not a BCP or or >Informational RFC. Also should this be run by Joel Halpburn in the >Routing Area before it goes much further? In my opinion it should be a PS because it specifies protocol stuff (bits, headers, procedures, etc.) It is important that there be a "standard" way to tunnel in IPv6. IPv4 suffered by having many different ways to do tunneling. This work is clearly not a routing protocol and does not belong in the routing area. Does this clarify? Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Nov 14 16:29:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10939; Thu, 14 Nov 96 16:29:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10879; Thu, 14 Nov 96 15:44:59 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA19400; Thu, 14 Nov 1996 15:37:52 -0800 Received: from nlanr.net (oceana.sdsc.edu [132.249.40.200]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA17936 for ; Thu, 14 Nov 1996 15:37:52 -0800 Received: (from kc@localhost) by nlanr.net (8.7.3/8.7.3) id PAA21757; Thu, 14 Nov 1996 15:33:52 -0800 (PST) From: k claffy Message-Id: <199611142333.PAA21757@nlanr.net> Subject: (IPng 2471) Re: W.G. Last Call on "Generic Packet Tunneling in IPv6 To: bound@zk3.dec.com Date: Thu, 14 Nov 1996 15:33:52 -0800 (PST) Cc: brian@dxcoms.cern.ch, hinden@ipsilon.com, ipng@sunroof.eng.sun.com, mrt-support@merit.edu In-Reply-To: <9611141313.AA17745@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Nov 14, 96 08:13:10 am X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hey there anyone out there have experience with the IPv6 kernel for OSF? we're trying to set up tunnels over the vBNS for an SC96 demo, but the OSF kernel seems to be generating 15-ish acks for every packet, which kind of wrought havoc with local mail and DNS for the day :( [should have known to unplug it from the production network :( ] i think i've got the solaris code working ok, though still have to get a working tunnel to masaki@merit -- k ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Nov 14 19:13:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11123; Thu, 14 Nov 96 19:13:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11115; Thu, 14 Nov 96 19:12:55 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA17654; Thu, 14 Nov 1996 19:05:50 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA11007 for ; Thu, 14 Nov 1996 19:05:50 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id VAA13323; Thu, 14 Nov 1996 21:58:15 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA31893; Thu, 14 Nov 1996 21:58:14 -0500 Message-Id: <9611150258.AA31893@wasted.zk3.dec.com> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2472) Re: W.G. Last Call on "Generic Packet Tunneling in IPv6 In-Reply-To: Your message of "Thu, 14 Nov 96 15:54:04 PST." <3.0.32.19961114155402.006df05c@mailhost.ipsilon.com> Date: Thu, 14 Nov 96 21:58:14 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What bits what headers? Procedures yes. I still am not convinced by your mail. I agree its needed but to cause correct operation is a BCP need not a PS need IMO. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Nov 14 19:22:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11150; Thu, 14 Nov 96 19:22:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11144; Thu, 14 Nov 96 19:22:34 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA19222; Thu, 14 Nov 1996 19:15:28 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA13232 for ; Thu, 14 Nov 1996 19:15:29 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id WAA25794; Thu, 14 Nov 1996 22:05:09 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA32159; Thu, 14 Nov 1996 22:05:08 -0500 Message-Id: <9611150305.AA32159@wasted.zk3.dec.com> To: k claffy Cc: bound@zk3.dec.com, brian@dxcoms.cern.ch, hinden@ipsilon.com, ipng@sunroof.eng.sun.com, mrt-support@merit.edu Subject: (IPng 2473) Re: W.G. Last Call on "Generic Packet Tunneling in IPv6 In-Reply-To: Your message of "Thu, 14 Nov 96 15:33:52 PST." <199611142333.PAA21757@nlanr.net> Date: Thu, 14 Nov 96 22:05:08 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >anyone out there have experience with >the IPv6 kernel for OSF? we're trying >to set up tunnels over the vBNS for an >SC96 demo, but the OSF kernel seems >to be generating 15-ish acks for every packet, >which kind of wrought havoc with local mail >and DNS for the day :( >[should have known to unplug it from >the production network :( ] WHat derivative of OSF are you running on what platform? You might want to contact the OSF group? I did not know they had done an implementation of IPv6? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 15 08:01:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11524; Fri, 15 Nov 96 08:01:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11518; Fri, 15 Nov 96 08:01:31 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA10796; Fri, 15 Nov 1996 07:54:26 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA25252 for ; Fri, 15 Nov 1996 07:54:25 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA24727; Fri, 15 Nov 1996 10:42:43 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA04000; Fri, 15 Nov 1996 10:42:27 -0500 Message-Id: <9611151542.AA04000@wasted.zk3.dec.com> To: Kevin Thompson Cc: bound@zk3.dec.com, kc@nlanr.net, clouter@woof.enet.dec.com, brian@dxcoms.cern.ch, hinden@ipsilon.com, ipng@sunroof.eng.sun.com, mrt-support@merit.edu Subject: (IPng 2474) Re: W.G. Last Call on "Generic Packet Tunneling in IPv6 (fwd) In-Reply-To: Your message of "Fri, 15 Nov 96 01:13:26 EST." <199611150613.BAA22666@postoffice.Reston.mci.net> Date: Fri, 15 Nov 96 10:42:27 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kevin, >Its a set of Dec Alpha 3000/900s now running >3.2C. The alpha at sdsc has the ipv6 binary kit installed >and has V6.7 firmware. The other 4 Decs are at V6.0 firmware >at the time of this writing, and we wanted to install the ipv6 binary >kit on those too. kc and I are also going to try netBSD. OK I was confused by the OSF in kc's mail... Your using Digital UNIX. >As a side note, we learned we can't run mrouted and ipv6 binaries >on the same alpha :) > >Mary Clouter is our contact for the DEC >ipv6 binary kit. Yes this will happen with AD kits and Mary will work it with you. I was concerned if it was Digital UNIX as there are several other OSs doing IPv6 out there that have OSF derivations. I was also unclear why such a message on a bug report went to the ipng list on a subject line that had nothing to do with implementations of IPv6. We have over a 100 kits out their working fine and see the bugs for several implementations as we test these specs out I would not send those to a public list either. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 15 08:55:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11572; Fri, 15 Nov 96 08:55:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11286; Thu, 14 Nov 96 22:35:11 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA18310; Thu, 14 Nov 1996 22:28:07 -0800 Received: from postoffice.Reston.mci.net (postoffice.Reston.mci.net [204.70.128.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA14562 for ; Thu, 14 Nov 1996 22:28:06 -0800 Received: from localhost (rem [166.45.4.41]) by postoffice.Reston.mci.net (8.7.5/8.7.3) with ESMTP id BAA22666; Fri, 15 Nov 1996 01:13:27 -0500 (EST) Message-Id: <199611150613.BAA22666@postoffice.Reston.mci.net> To: bound@zk3.dec.com Cc: kc@nlanr.net, kthomp@mci.net, clouter@woof.enet.dec.com, brian@dxcoms.cern.ch, hinden@ipsilon.com, ipng@sunroof.eng.sun.com, mrt-support@merit.edu Subject: (IPng 2475) Re: W.G. Last Call on "Generic Packet Tunneling in IPv6 (fwd) In-Reply-To: Your message of "Thu, 14 Nov 1996 21:24:13 PST." <199611150524.VAA06645@kasina.nlanr.net> Date: Fri, 15 Nov 1996 01:13:26 -0500 From: Kevin Thompson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>anyone out there have experience with >>the IPv6 kernel for OSF? we're trying >>to set up tunnels over the vBNS for an >>SC96 demo, but the OSF kernel seems >>to be generating 15-ish acks for every packet, >>which kind of wrought havoc with local mail >>and DNS for the day :( >>[should have known to unplug it from >>the production network :( ] >WHat derivative of OSF are you running on what platform? >You might want to contact the OSF group? >I did not know they had done an implementation of IPv6? > >/jim Its a set of Dec Alpha 3000/900s now running 3.2C. The alpha at sdsc has the ipv6 binary kit installed and has V6.7 firmware. The other 4 Decs are at V6.0 firmware at the time of this writing, and we wanted to install the ipv6 binary kit on those too. kc and I are also going to try netBSD. As a side note, we learned we can't run mrouted and ipv6 binaries on the same alpha :) Mary Clouter is our contact for the DEC ipv6 binary kit. Kevin Thompson MCI vBNS ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 15 08:57:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11579; Fri, 15 Nov 96 08:57:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11530; Fri, 15 Nov 96 08:09:39 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA12022; Fri, 15 Nov 1996 08:02:34 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA28227 for ; Fri, 15 Nov 1996 08:02:33 -0800 Received: from us1rmc.bb.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA30959; Fri, 15 Nov 1996 10:46:20 -0500 (EST) Received: from johill.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA25514; Fri, 15 Nov 96 08:52:50 -0500 Message-Id: <9611151352.AA25514@us1rmc.bb.dec.com> Received: from johill.enet; by us1rmc.enet; Fri, 15 Nov 96 10:48:15 EST Date: Fri, 15 Nov 96 10:48:15 EST From: Ken Powell To: mohta@necom830.hpcl.titech.ac.jp Cc: ipng@sunroof.eng.sun.com, powell@johill.ENET.dec.com Apparently-To: ipng@sunroof.Eng.Sun.COM, mohta@necom830.hpcl.titech.ac.jp Subject: (IPng 2476) Masataka's 8+8 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masataka Ohta wrote: >> They are already solved. >> >> IPv6 WG ignore IP or TAG switching. >> >> Make *ID 64 bit long. >> >> Make *ID independent of any topology. >> >> Let *ID have hierarchy. >> >> Have 64 bit locator to locate a subnet. >> >> The only possible overloading is to use *ID as an intra-subnet, >> thus topology independent, locator. >> >> And, there are REASONS to do so. I don't understand what you mean by "Let *ID have hierarchy". What functions does the hierarchy support? Here are some possible examples to show where my imagination drifts with this concept. 1) Subdivide the address space to various allocation authorities to guarantee global uniqueness. 2) Allocate specific address ranges in *ID to specific types of subnet addresses thereby supporting subnet address overloading (e.g., 802 MAC addresses) 3) Allow *ID to identify both a primary address resolver (home agent) as a block of addresses, with specific mobile host identifiers allocated within the block. 4) Support host address lookup in the namespace using *ID alone. This function implies that *ID hierarchy maps reasonably well to the namespace hierarchy. I wouldn't be surprised if your intentions were completely different. >> If you don't think my specs are not good enough, it would be very >> useful to me and I am sure to others if you would give details on >> where you think the specs specifically are in error. Where can I find a copy of your spec. I tried looking for it in the usual IETF areas with no success. I suspect it must have past the six month limit. I was hoping to find the answer to my question above would be in there, along with more details on how the hierarchy is applied to achieve the various functions. Ken Powell ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 15 10:26:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11665; Fri, 15 Nov 96 10:26:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11659; Fri, 15 Nov 96 10:26:38 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA09331; Fri, 15 Nov 1996 10:19:32 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA18540 for ; Fri, 15 Nov 1996 10:19:27 -0800 Received: from redwood.ipsilon.com (redwood.Ipsilon.COM [205.226.8.238]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id KAA13221; Fri, 15 Nov 1996 10:16:50 -0800 Message-Id: <3.0.32.19961115101608.0073612c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 15 Nov 1996 10:16:10 -0800 To: bound@zk3.dec.com From: Bob Hinden Subject: (IPng 2477) Re: W.G. Last Call on "Generic Packet Tunneling in IPv6 Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, >What bits what headers? Procedures yes. Section 4.1.1 and 5.1 defines an IPv6 "Tunnel Encapsulation Limit" destination option. Not a lot of "bits", but "bits" none the less :-) Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 15 11:05:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11691; Fri, 15 Nov 96 11:05:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11685; Fri, 15 Nov 96 11:05:45 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA16660; Fri, 15 Nov 1996 10:58:39 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA06767 for ; Fri, 15 Nov 1996 10:58:38 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA25851; Fri, 15 Nov 1996 13:41:28 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA20970; Fri, 15 Nov 1996 13:41:26 -0500 Message-Id: <9611151841.AA20970@wasted.zk3.dec.com> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2478) Re: W.G. Last Call on "Generic Packet Tunneling in IPv6 In-Reply-To: Your message of "Fri, 15 Nov 96 10:16:10 PST." <3.0.32.19961115101608.0073612c@mailhost.ipsilon.com> Date: Fri, 15 Nov 96 13:41:26 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, >>What bits what headers? Procedures yes. > >Section 4.1.1 and 5.1 defines an IPv6 "Tunnel Encapsulation Limit" >destination option. > >Not a lot of "bits", but "bits" none the less :-) Yep. Big spec for not a lot of bits. As I reread these sections it came to mind that the tunnel spec also states the tunnel-limit creates an exception to the dst options processing. Right now only hosts look at the dst options but for tunnels the routers need to so they can see this new dst option. Do we need to add a new set of tunnel options to the base RFC 1883 spec to avoid such an exception. The reason I suggested the routing area is because we are asking routers to look inside the packet in this spec for dst options now? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 15 16:01:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12137; Fri, 15 Nov 96 16:01:15 PST Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12131; Fri, 15 Nov 96 16:00:58 PST Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA01536; Fri, 15 Nov 1996 15:53:53 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA10104; Fri, 15 Nov 1996 15:53:35 -0800 Date: Fri, 15 Nov 1996 15:53:35 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199611152353.PAA10104@bobo.eng.sun.com> To: thartric@mentat.com Subject: (IPng 2479) Re: BSD API - ipv6_mreq Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1) Use addresses to identify interfaces just like we do in IPv4. > > There is consistency between IPv6 and IPv4 API's. Since every > IPv6 interface can have a unique link-local address (see KRE's > draft) we don't have the IPv4 unnumbered interface problem. Strictly speaking it is not true that you'll have a unique link-local address for all interfaces. An example is an interface that provides an IPv6-in-IPv6 tunnel. I haven't seen a proposal that would assign link-local addresses to such interfaces. > 2) Use an interface index type thing to identify interfaces. > > This solution works but is not consistent with the IPv4 API's. I'd prefer #2 since it is slightly more general and also more consistent with the advanced API draft. If we want to do this for ipv6_mreq we also need to specify an ifindex that means "don't care" which is what most applications use today. (The applications just join the multicast group and let the kernel pick the interface the join applies to.) Note that in the IPv4 API this is done by using INADDR_ANY. Is interface index 0 reserved? (i.e. does it ever refer to an interface) If so we could use zero for "don't care"? Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 15 16:40:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12337; Fri, 15 Nov 96 16:40:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12331; Fri, 15 Nov 96 16:40:38 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA25090; Fri, 15 Nov 1996 16:33:34 -0800 Received: from cornpuffs.cisco.com (cornpuffs.cisco.com [171.69.1.219]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA19923 for ; Fri, 15 Nov 1996 16:33:32 -0800 Received: (rja@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id QAA14577; Fri, 15 Nov 1996 16:33:31 -0800 Date: Fri, 15 Nov 1996 16:33:31 -0800 From: Ran Atkinson Message-Id: <199611160033.QAA14577@cornpuffs.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2480) Re: IPng WG Last Call on "Generic Packet Tunneling in IPv6" In-Reply-To: <9611141313.AA17745@wasted.zk3.dec.com> References: <9611140906.AA19750@dxcoms.cern.ch> Organization: cisco Systems Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For the record, I do not believe that "Generic Packet Tunneling in IPv6" is appropriate to be a standards-track document at this time in its current form. In article <9611141313.AA17745@wasted.zk3.dec.com> Jim wrote: >What is GRE classified at this point? GRE is an Informational RFC at this minute. I am willing to carry the IETF flag within cisco to have change control on GRE formally handed over to the IETF _if and only if_ there is interest within the IETF community to standardise GRE as an elective standard approach to tunnels (i.e. I'm willing to cooperate with the community but I'm not trying to force anything on anyone :-). I'd appreciate hearing privately from any folks interested in seeing GRE handed to the IETF for standardisation. Ran rja@cisco.com PS: I'll be on travel for the next few weeks with only intermittent email access, so a delayed response from me only means I'm on the road... ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 15 16:48:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12383; Fri, 15 Nov 96 16:48:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12377; Fri, 15 Nov 96 16:48:10 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA26470; Fri, 15 Nov 1996 16:41:03 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA21581 for ; Fri, 15 Nov 1996 16:41:00 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA19821; Fri, 15 Nov 96 16:40:07 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id QAA02567; Fri, 15 Nov 1996 16:40:57 -0800 Date: Fri, 15 Nov 1996 16:40:57 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199611160040.QAA02567@feller.mentat.com> To: erik.nordmark@Eng Subject: (IPng 2481) Re: BSD API - ipv6_mreq Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > > 1) Use addresses to identify interfaces just like we do in IPv4. > > > > There is consistency between IPv6 and IPv4 API's. Since every > > IPv6 interface can have a unique link-local address (see KRE's > > draft) we don't have the IPv4 unnumbered interface problem. > > Strictly speaking it is not true that you'll have a > unique link-local address for all interfaces. An example > is an interface that provides an IPv6-in-IPv6 tunnel. > I haven't seen a proposal that would assign link-local > addresses to such interfaces. That is true if one implements IPv6-in-IPv6 tunnels as a real interfaces. The same problem exists if you implement IPv6-in-IPv4 tunnels as real interfaces. Most of the implementations I have seen don't implement IPv6-in-IPv4 tunnels as real interfaces. I have not seen an implementation do IPv6-in-IPv6 tunneling yet. I suspect that what link-local address to assign to tunnel interfaces (IPv4 or IPv6) is a non-problem since multiple implementations exist and interoperate without the benefit of tunnel interfaces. > > > 2) Use an interface index type thing to identify interfaces. > > > > This solution works but is not consistent with the IPv4 API's. > > I'd prefer #2 since it is slightly more general and also > more consistent with the advanced API draft. > It was an implicit part of these choices (apparently only to me :-)) that in order to implement choice 1) the advanced API spec would need to change to use addresses rather than interface indices. I guess I should have made that more clear. It appears as though there is consensus around 2). Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 15 16:49:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12393; Fri, 15 Nov 96 16:49:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12387; Fri, 15 Nov 96 16:49:31 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA26657; Fri, 15 Nov 1996 16:42:26 -0800 Received: from oberon.di.fc.ul.pt (oberon.di.fc.ul.pt [192.67.76.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA21863; Fri, 15 Nov 1996 16:42:22 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id AAA03033; Sat, 16 Nov 1996 00:41:57 GMT Date: Sat, 16 Nov 1996 00:41:57 GMT Message-Id: <199611160041.AAA03033@oberon.di.fc.ul.pt> From: Pedro Roque To: erik.nordmark@Eng (Erik Nordmark) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2482) Re: BSD API - ipv6_mreq In-Reply-To: <199611152353.PAA10104@bobo.eng.sun.com> References: <199611152353.PAA10104@bobo.eng.sun.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Erik" == Erik Nordmark writes: >> 1) Use addresses to identify interfaces just like we do in >> IPv4. >> >> There is consistency between IPv6 and IPv4 API's. Since every >> IPv6 interface can have a unique link-local address (see KRE's >> draft) we don't have the IPv4 unnumbered interface problem. Erik> Strictly speaking it is not true that you'll have a unique Erik> link-local address for all interfaces. An example is an Erik> interface that provides an IPv6-in-IPv6 tunnel. I haven't Erik> seen a proposal that would assign link-local addresses to Erik> such interfaces. My wild guess is that even IPv6-in-IPv6 tunnels will have a link local address since routing software (and protocols) seams to assume that every link has a link local address. There is no "good" way to assign one, i.e. no way in which you can derivate the full corresponding IPv6 address... so i think uniqueness will be the major factor and fe80:: would be the "obvious" choice. Erik> I'd prefer #2 since it is slightly more general and also Erik> more consistent with the advanced API draft. Erik> If we want to do this for ipv6_mreq we also need to specify Erik> an ifindex that means "don't care" which is what most Erik> applications use today. (The applications just join the Erik> multicast group and let the kernel pick the interface the Erik> join applies to.) Note that in the IPv4 API this is done by Erik> using INADDR_ANY. Erik> Is interface index 0 reserved? (i.e. does it ever refer to Erik> an interface) If so we could use zero for "don't care"? That is exactly what the Linux kernel (>=2.1.9) does presently... an if_index of 0 will trigger a route lookup for the default multicast route. regards, ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 15 17:11:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12477; Fri, 15 Nov 96 17:11:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12471; Fri, 15 Nov 96 17:11:21 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA01218; Fri, 15 Nov 1996 17:04:09 -0800 Received: from relay-7.mail.demon.net (relay-7.mail.demon.net [194.217.242.9]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA26898 for ; Fri, 15 Nov 1996 17:04:06 -0800 Received: from psp.demon.co.uk ([158.152.26.54]) by relay-5.mail.demon.net id aa515604; 15 Nov 96 17:45 GMT Message-Id: Date: Fri, 15 Nov 1996 12:28:06 +0000 To: ipng@sunroof.eng.sun.com From: Thomas Lee Subject: (IPng 2483) Re: W.G. Last Call on "Generic Packet Tunneling in IPv6 Specification" In-Reply-To: <3.0.32.19961113174925.006b1988@mailhost.ipsilon.com> Mime-Version: 1.0 X-Mailer: Turnpike Version 3.01 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk x-no-archive: yes In article <3.0.32.19961113174925.006b1988@mailhost.ipsilon.com>, Bob Hinden writes >This is an ipng working group last call for comments on advancing the >following document to Proposed Standard: > > Title : Generic Packet Tunneling in IPv6 Specification > Author(s) : A. Conta, S. Deering > Filename : draft-ietf-ipngwg-ipv6-tunnel-04.txt > Pages : 35 > Date : 10/31/1996 > I've been trying to download this from the sunroof web site for 2 days and constantly get errors - and no document. Can the sunroof site get fixed (or can you point me to another source for this proposed standard)? Thomas -- Thomas Lee (email: tfl@psp.co.uk, web: http://www.psp.demon.co.uk/tfl/tfl.htm) Microsoft Certified Systems Engineer and Certified Trainer PS Partnership - A Microsoft Solution Provider Ph: +44 1628 850 077 Fax: +44 1628 850 143 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 15 17:15:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12492; Fri, 15 Nov 96 17:15:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12486; Fri, 15 Nov 96 17:14:53 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA02012; Fri, 15 Nov 1996 17:07:47 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA27642 for ; Fri, 15 Nov 1996 17:07:43 -0800 Received: from redwood.ipsilon.com (redwood.Ipsilon.COM [205.226.8.238]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id RAA02708; Fri, 15 Nov 1996 17:07:10 -0800 Message-Id: <3.0.32.19961115170621.00773270@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 15 Nov 1996 17:06:30 -0800 To: Ran Atkinson From: Bob Hinden Subject: (IPng 2484) Re: IPng WG Last Call on "Generic Packet Tunneling in IPv6" Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, > For the record, I do not believe that "Generic Packet Tunneling in >IPv6" is appropriate to be a standards-track document at this time in its >current form. Could you elaborate on why you believe we should not advance this specification to proposed standard. > GRE is an Informational RFC at this minute. I am willing to carry the >IETF flag within cisco to have change control on GRE formally handed over to >the IETF _if and only if_ there is interest within the IETF community to >standardise GRE as an elective standard approach to tunnels (i.e. I'm willing >to cooperate with the community but I'm not trying to force anything on anyone >:-). I'd appreciate hearing privately from any folks interested in seeing GRE >handed to the IETF for standardisation. I suspect there would be considerable interest in this. However I do not think this is a topic for the IPng w.g. as GRE is not specific to IPv6. I suggest you make your kind offer to the Internet AD's. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 15 17:45:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12553; Fri, 15 Nov 96 17:45:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12547; Fri, 15 Nov 96 17:45:45 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA06140; Fri, 15 Nov 1996 17:38:40 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA03997 for ; Fri, 15 Nov 1996 17:38:39 -0800 Received: from redwood.ipsilon.com (redwood.Ipsilon.COM [205.226.8.238]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id RAA04040; Fri, 15 Nov 1996 17:38:32 -0800 Message-Id: <3.0.32.19961115173746.006a2350@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 15 Nov 1996 17:37:52 -0800 To: Thomas Lee From: Bob Hinden Subject: (IPng 2485) Re: W.G. Last Call on "Generic Packet Tunneling in IPv6 Specification" Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >> >> Title : Generic Packet Tunneling in IPv6 Specification >> Author(s) : A. Conta, S. Deering >> Filename : draft-ietf-ipngwg-ipv6-tunnel-04.txt >> Pages : 35 >> Date : 10/31/1996 >> > >I've been trying to download this from the sunroof web site for 2 days >and constantly get errors - and no document. Can the sunroof site get >fixed (or can you point me to another source for this proposed >standard)? You can find it at ftp://ftp.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-04.txt Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 15 17:49:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12568; Fri, 15 Nov 96 17:49:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12562; Fri, 15 Nov 96 17:49:36 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA06515; Fri, 15 Nov 1996 17:42:31 -0800 Received: from cornpuffs.cisco.com (cornpuffs.cisco.com [171.69.1.219]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA04589 for ; Fri, 15 Nov 1996 17:42:30 -0800 Received: (rja@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id RAA15800; Fri, 15 Nov 1996 17:41:57 -0800 Message-Id: <199611160141.RAA15800@cornpuffs.cisco.com> From: rja@cisco.com (Ran Atkinson) Date: Fri, 15 Nov 1996 17:41:56 PST In-Reply-To: Bob Hinden "Re: (IPng 2480) Re: IPng WG Last Call on "Generic Packet Tunneling in IPv6"" (Nov 15, 5:06pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Bob Hinden , Ran Atkinson Subject: (IPng 2486) Re: IPng WG Last Call on "Generic Packet Tunneling in IPv6" Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, I believe that if the IETF is to standardise tunneling, it should do so in a generic manner that would work not only for IPv6 but also for IPv4 (and potentially also for other protocols over IPv*). I think there is significant evidence (e.g. IP-in-IP, ESP) that such generic tunneling is feasible. Regards, Ran rja@cisco.com -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 15 18:54:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12619; Fri, 15 Nov 96 18:54:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12613; Fri, 15 Nov 96 18:53:56 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA13288; Fri, 15 Nov 1996 18:46:51 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA14269 for ; Fri, 15 Nov 1996 18:46:50 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA20757; Fri, 15 Nov 96 18:45:58 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id SAA02790; Fri, 15 Nov 1996 18:46:48 -0800 Date: Fri, 15 Nov 1996 18:46:48 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199611160246.SAA02790@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2487) Advanced API Specification X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard and Matt, I have a couple comments/questions about the advanced API draft. All of my comments and questions are regarding section 4.3 and section 2. respectively. 1) In the portion which lists the "how-to's" of requesting the various options you have: setsockopt(fd, IPPROTO_IPV6, IPV6_RXINFO, &on, sizeof(on)); setsockopt(fd, IPPROTO_IPV6, IPV6_RXHOPOPTS, &on, sizeof(on)); setsockopt(fd, IPPROTO_IPV6, IPV6_RXDSTOPTS, &on, sizeof(on)); setsockopt(fd, IPPROTO_ROUTING, IPV6_RXSRCRT, &on, sizeof(on)); Should the last item be an IPPROTO_IPV6 level option? What is different about the IPV6_RXSRCRT option which makes it not an IPPROTO_IPV6 level option? I guess that was a couple of questions wasn't it :-). 2) With regard to options and extention headers it appears as though you have opted to make the kernel do more work and the user less with regard to the formatting and presentation of the options and extention headers. Specifically, you allow the user to specify multiple hop-by-hop or destination options by using multiple ancillary data items. It is left to the kernel to cobble together all the various pieces into the appropriate extention header, pad the header with additional options if necessary, and then place the extension header into the packet. The process is roughly the reverse on the receive side. The kernel must extract each option seperately and build a seperate ancillary date item for each option. Presumeably the kernel would extract any padding options and not pass those through to the user. Given that kernel time is usually more precious than user time it would seem that having the user build the entire extension header could have some efficiency benefits. Specifically, one could specify a single ancillary data item which had a level of IPPROTO_IPV6 and a type of IPPROTO_HOPOPTS. This ancillary data item would contain a pre-built and pre-padded hop-by-hop option header. Obviously the same approach would work for destination options as well. This single ancillary data item would then be passed into the kernel using sendmsg. The receive side would be the reverse. The kernel would simply pass the entire extension header to the user in a single ancillary data item. I assume you guys considered this approach and rejected it for some reason. Can you explain the rational for rejecting the above scheme in favor of the scheme described in the draft. 3) With respect to section 2. Do we need some "Common Structures and Definitions" which define what hop-by-hop and destination options. Specifically, the various bits in the option which describe the actions to be taken by the receiver probably need to be defined. The existing types probably need to be defined as well (PAD1, PADN, others?). Thanks Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 15 18:55:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12626; Fri, 15 Nov 96 18:55:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12620; Fri, 15 Nov 96 18:55:13 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA13375; Fri, 15 Nov 1996 18:48:08 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA14392 for ; Fri, 15 Nov 1996 18:48:07 -0800 Received: from redwood.ipsilon.com (redwood.Ipsilon.COM [205.226.8.238]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id SAA06233; Fri, 15 Nov 1996 18:47:36 -0800 Message-Id: <3.0.32.19961115184216.006a2358@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 15 Nov 1996 18:46:55 -0800 To: rja@cisco.com (Ran Atkinson) From: Bob Hinden Subject: (IPng 2488) Re: IPng WG Last Call on "Generic Packet Tunneling in IPv6" Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, > I believe that if the IETF is to standardise tunneling, it should >do so in a generic manner that would work not only for IPv6 but also >for IPv4 (and potentially also for other protocols over IPv*). I >think there is significant evidence (e.g. IP-in-IP, ESP) that such >generic tunneling is feasible. Firstly, you are not pointing out a specific technical problem with the current draft (e.g., why it would not work). You are suggesting we are doing the wrong thing by not making it generic to a range of protocols. This is a valid concern. I am not sure there is much we can do with IPv4 tunneling. As you mention there are already too many ways to do this now. Our desire with IPv6 was to define a single approach before too many others appeared. This draft is the result. This draft with it's implied approach (e.g., tunneling in IPv6) has been in the working group about a year. It was first discussed at the December 1995 IETF. As far am I aware this is the first time anyone has said we are solving the wrong problem. Before we abandon the considerable work of the authors or delay it with further changes, I would like to see other comments from the working group as to this issue. Unless there is strong feeling to the contrary I would perfer to continue moving this document forward. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 15 18:57:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12643; Fri, 15 Nov 96 18:57:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12632; Fri, 15 Nov 96 18:57:14 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA13496; Fri, 15 Nov 1996 18:50:09 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA14628 for ; Fri, 15 Nov 1996 18:50:08 -0800 Received: from redwood.ipsilon.com (redwood.Ipsilon.COM [205.226.8.238]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id SAA06229; Fri, 15 Nov 1996 18:47:34 -0800 Message-Id: <3.0.32.19961115184639.006f0b4c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 15 Nov 1996 18:46:54 -0800 To: bound@zk3.dec.com From: Bob Hinden Subject: (IPng 2489) Re: W.G. Last Call on "Generic Packet Tunneling in IPv6 Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, >Yep. Big spec for not a lot of bits. As I reread these sections it That has never been a criteria for making something a standard. Some "bits" are very important. What one does with the "bits" (e.g., procedures) can be even more important :-) >came to mind that the tunnel spec also states the tunnel-limit creates >an exception to the dst options processing. Right now only hosts look >at the dst options but for tunnels the routers need to so they can see >this new dst option. I may be confused, but I think that only the end points of the tunnel need to process this option. This makes it appropriate for a destination option. The routers at each of the tunnel source and sink these packets. If it were a secure tunnel they would also process the security encapsulation headers. >Do we need to add a new set of tunnel options to the base RFC 1883 spec >to avoid such an exception. As stated above, I don't think it is an exception. >The reason I suggested the routing area is because we are asking routers >to look inside the packet in this spec for dst options now? The routing area deals with routing protocols, not routers. Many things routers are required to do are not specified in the routing area. IPv6 itself comes to mind :-) I hope this resolves your issues. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Nov 16 01:50:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12950; Sat, 16 Nov 96 01:50:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12944; Sat, 16 Nov 96 01:50:13 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA05889; Sat, 16 Nov 1996 01:43:07 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id BAA27306 for ; Sat, 16 Nov 1996 01:42:55 -0800 From: Masataka Ohta Message-Id: <199611160941.SAA01290@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA01290; Sat, 16 Nov 1996 18:41:10 +0900 Subject: (IPng 2490) Re: Masataka's 8+8 To: powell@johill.ENET.dec.com (Ken Powell) Date: Sat, 16 Nov 96 18:41:09 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com, powell@johill.ENET.dec.com In-Reply-To: <9611151352.AA25514@us1rmc.bb.dec.com>; from "Ken Powell" at Nov 15, 96 10:48 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ken; > >> Let *ID have hierarchy. > I don't understand what you mean by "Let *ID have hierarchy". What > functions does the hierarchy support? Here are some possible examples > to show where my imagination drifts with this concept. The primary reason is to make it a useful index for looking up hierarchical databases, such as in-addr.arpa for IPv4. > 1) Subdivide the address space to various allocation authorities to > guarantee global uniqueness. Mere global uniqueness is no good. What we need is structured delegation and structured databases, for example, of public keys. > 2) Allocate specific address ranges in *ID to specific types of subnet > addresses thereby supporting subnet address overloading (e.g., 802 MAC > addresses) One reason why *ID must be 64bit long is that it should accomodate 64 bit IEEE 1394 globally unique ID. > 3) Allow *ID to identify both a primary address resolver (home agent) > as a block of addresses, with specific mobile host identifiers > allocated within the block. I'm afraid you missed the role or ILOC (the Internet LOCator, the locator part of 8+8 partition). The mobile host may change ILOC part of the address, but *ID part is, BY DEFINITION, *INVARIANT*. *ID of a mobile host identifies the mobile host. The mobile host has the primary address (or addresses): (ILOC(home subnet), *ID(mobile)) which would be registered to DNS. When the mobile host is not at home subnet, a home agent intercepts packets directed to: (ILOC(home subnet), *ID(mobile)), rewrites the ILOC part of the packet as: (ILOC(foreign subnet), *ID(mobile)) without being bothered by encapsulation, tunneling nor MTU. This is a removal of the mobility warts. When the packet reaches the foreign subnet, the packet is perfectly leagal and there is no worrying about the destruction of the subnet model. This is another removal of the mobility warts. And, such removal of warts is impossible with Mike's topology dependent *ID. > 4) Support host address lookup in the namespace using *ID alone. This > function implies that *ID hierarchy maps reasonably well to the > namespace hierarchy. Yes. That's the point. It should be noted that the *ID hierarchy has NOTHING to do with routing hierarchy, which is why 64 bits are a lot more than enough. 64bits for SIPP was no good becasue SIPP address was like that of IPv4 with no ILOC *ID separation. > I wouldn't be surprised if your intentions were completely different. Not so much, I hope. > >> If you don't think my specs are not good enough, it would be very > >> useful to me and I am sure to others if you would give details on > >> where you think the specs specifically are in error. > > Where can I find a copy of your spec. I tried looking for it in the > usual IETF areas with no success. I suspect it must have past the > six month limit. I was hoping to find the answer to my question > above would be in there, along with more details on how the > hierarchy is applied to achieve the various functions. I'm preparing a new Internet Draft. But, FYI, attached is an old one. Masataka Ohta INTERNET DRAFT M. Ohta draft-ohta-ipv6-addr-arch-00.txt Tokyo Institute of Technology March 1995 Provider Independent IPv6 Addressing Architecture Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract An IPv6 addressing architecture which maximize the provider independence is described. With flatly routed IPv4 addresses, one can subscribe to multiple providers and change providers at will without a lot of efforts. But, IPv6 packets will be hierarchically routed and their addresses will have hierarchical structure, whose higher part is determined by the network provider. By separating a 128 bit IPv6 address into 64 bit ILOC (Internet LOCator), first 4 bytes of which is flat routable provider part and the rest 4 bytes of which is hierarchical intra-provider part, and 64 bit IID (Internet ID), which is not routable but globally unique, it is possible to preserve some of the provider independence of IPv4. The architecture can also identify geographical location of providers. Introduction IPv4 addresses do not contain provider dependent information. Thus, with IPv4 addresses, we can select and change providers without M. Ohta Expires on Sept. 25, 1995 [Page 1] INTERNET DRAFTProvider Independent IPv6 Addressing Architecture March 1995 reassigning IP addresses. On the other hand, IPv6 addresses contain provider dependent part for routing aggregation. If host identification is controlled by providers, it is difficult to change providers or have multiple provider. It is likely that subscribers are tuned into the provider they choose and tends to promote provider monopoly. The problem, obviously, is in provider-dependent hierarchical routing. And, the solution, obviously, is not to do provider-dependent hierarchical routing. This memo proposes an address assignment scheme for IPv6 which does flat routing for providers. Routing below providers is, of course, hierarchical so that enough scalability is assured to support 10^12 networks and 10^15 hosts. A mechanism to identify small geographical locations is also included to have geographically-near-optimal and least-costly routing with proper route selection. Assignment Plan for IPv6 address The 16 byte IPv6 address is divided into two fields: 8 byte ILOC (Internet LOCator) and 8 byte IID (Internet ID). ILOC is further divided into three sub fields: 4 byte "Provider ID", 2 byte "Subscriber ID" and 2 byte "Subnet ID". "Provider ID" and "Subscriber ID" together is called "Provider dependent part". Provider dependent part is supplied by providers and dynamically reconfigurable at system boot time or even during operation. It is expected that routers to providers announce provider dependent part information. IID is a globally unique ID of a host or a multicast group to identify the host or the multicast group. While an IID uniquely identifies a single host, a host may have multiple IIDs. But, within a lifetime of some connection or reservation such as for TCP or flow, the same IID should be used regardless of the routing changes. IID is supplied by subscribers. The configuration may be automatic. But it is expected that renumbering is necessary not so often, in M. Ohta Expires on Sept. 25, 1995 [Page 2] INTERNET DRAFTProvider Independent IPv6 Addressing Architecture March 1995 general, only when a host is purchased or the host is moved to different suborganization of the provider. Host specific information such as IP address to host name mapping is looked up only through IID. For autoconfiguration, it must be possible to derive some IIDs from MAC addresses. As 2^28<10^15, MAC addresses to support 10^15 hosts must be longer than 48 bits (actually, a lot longer than that), IID is designed to have 64 bits. Subnet ID is also supplied by subscribers and identifies a subnet within a subscribers LAN. The configuration may be automatic through nearest routers. Renumbering is necessary when a location of a host is changed to a different subnet. Network layer identification of a host is done through IID just like the current IPv4. Routing is controlled purely by the ILOC part of IPv6 address, which is 8byte aligned and, thus, is more efficient than schemes using full 16 bytes. For the deliverly between adjacent routers or a router and a host, which is within a single link layer, only the identification is necessary. So, for IPv6 ARP equivalent, IID is used and ILOC is not consulted. Users can change providers at will just by disconnecting one of its external routers and connect it to a new provider, and ILOC part will be automatically reconfigured. But, it is still necessary to update information of DNS, which is further explained in the "DNS interaction" section. A host of a subscriber belonging to multiple providers may have multiple provider dependent parts. Different interfaces of a host is, in general, distinguished by ILOC part. Assignment Plan for Provider ID, Subscriber ID and Subnet ID 4 byte provider ID uniquely identifies a single provider in the Internet, while a provider may have multiple provider IDs. 4 byte provider ID combined with 2 byte subscriber ID uniquely identifies a subscriber in the Internet. Provider ID of 0 is reserved for subscriber local routing. 2 byte subnet ID uniquely identifies a subnet in a subscribers M. Ohta Expires on Sept. 25, 1995 [Page 3] INTERNET DRAFTProvider Independent IPv6 Addressing Architecture March 1995 network. A large subscriber having more than 65536 subnets will have multiple subscriber IDs from a provider. A large provider having more than 65536 subscriber IDs or having some geographical constraints, as explained in the next section, will have multiple provider IDs. Avoiding Treework A goal of IPv6 is to avoid treework and make it real network. With usual provider based addressing, users within a single provider share the same routing prefix so that it is difficult to use better route outside the provider. That is, complex configuration is necessary to break the routing hierarchy, which does not scale. It is unlikely that providers welcome such configuration only to allow subscribers pay less to the provider. So, in this proposal, to identify small geographical locations, a provider ID should not cover an area of 100Km radius. That is, a large provider must use different provider IDs for hosts located more than 200Km apart. The distance is measured only for IP entry point of providers, so that PPP service through non-IP public data network for 1,000Km-distant user is allowed. Thus, it becomes naturally possible to favor local links outside of the centralized provider, if local IXes are available. Only about 17,000 IDs are necessary to cover the surface of the Earth. Inter-planetary communication is NOT considered here. Assignment Plan for IIDs There are two kinds of IIDs, structured and unstructured. Structured IIDs are maintained by IANA and is used to lookup IANA maintained database of in-addr.arpa. equivalent of IPv6. Unstructured IIDs are directly derived from globally unique MAC addresses of hosts and useful for autoconfiguration. The most significant bit of structured IID is 0. First three bytes of structured IID are assigned from IANA to country NICs. M. Ohta Expires on Sept. 25, 1995 [Page 4] INTERNET DRAFTProvider Independent IPv6 Addressing Architecture March 1995 Each country NIC uses the next three bytes for independent subscribers. A subscriber use the last two bytes for the internal use. If the lease significant bit of IID is 0, it is for unicasting. Otherwise, the IID identifies multicast. An IID of all 1's except of the first bit is for broadcasting. The most significant bit of unstructured IID is 1. For the current 48 bit MAC addresses maintained by IEEE, 16 bits prefix of "1000000000000000" is added to form the IID. Rest of the unstructured IID space is reserved for the future use. DNS Interaction While IPv6 addresses are mostly autoconfigurable, it is still necessary to use DNS to advertise IPv6 addresses all over the Internet. As IIDs are considered to be rather static, they can be stored in DNS just as the current IPv4 addresses. On the other hand, if a subscriber adds or changes a provider, it is necessary to reflect the change to DNS. To do so without a lot of pain, the DNS lookup of ILOC should be indirect. That is, each DNS node of a host should not directly have ILOC but have a pointer to some node. The node, which is pointed by a lot of hosts within the same subscriber, then, have (multiple) ILOC information of the subscriber. Thus, it is possible to quickly change a provider without much difficulty. Of course, some statically configured raw addresses, which is necessary for the minimal operation of DNS itself, will still need to be reconfigured. Supporting 10^12 networks and 10^15 hosts How the requirement to support 10^12 networks and 10^15 hosts can be satisfied? First, how routing between 10^12 networks is possible? 10^3 hosts within a subnet can easily be identified by the IID. Thus, (Provider ID, Subscriber ID, Subnet ID) must identify 10^12 networks. It is not unnatural that a provider, in average, supports at least 10^3 subscribers. It can also be safely assumed that subnet ID can identify 10^1 subnets. Thus, Provider ID is required to identify 10^8 hosts. Considering that the requirement contains 10^2 safety factor, the least significant byte of the Provider ID are reserved for the factor. The remaining 3 bytes (2^24>10^7) are much more than M. Ohta Expires on Sept. 25, 1995 [Page 5] INTERNET DRAFTProvider Independent IPv6 Addressing Architecture March 1995 enough to identify 10^6 providers. It is assumed that by the time we support 10^12 networks, flat routing of 10^6 providers is not a problem at all. The reserved lowest byte of provider ID may also be used for two-level routing among providers. Next, how identification of 10^15 hosts is possible? 10^3 hosts of a subscriber can easily be identified by the last two bytes of IID. For the remaining 10^12 factor, IANA and country NICs are expected to manage the upper 6 bytes (for about 2*10^24 hosts) densely enough. Thus, it is feasible that more than 10^12 networks can be identified with the 6 bytes. Conclusion As the 16 byte address space is so large, it is possible to use it wisely to enjoy full provider independence, including provider change without renumbering and long distance provider selection by provider IDs. Acknowledgement The work is inspired by the concept of locator/EID of NIMROD and PIP. Josh Osborne helped the Author to clarify the geographical identification feature of the proposal. References (to be provided) Security Considerations (to be provided) Author's Addresses Masataka Ohta Computer Center Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku Tokyo 152, JAPAN Phone: +81-3-5734-3299 Fax: +81-3-5734-3415 EMail: mohta@necom830.cc.titech.ac.jp M. Ohta Expires on Sept. 25, 1995 [Page 6] ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Nov 16 06:51:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13038; Sat, 16 Nov 96 06:51:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13032; Sat, 16 Nov 96 06:51:23 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA22419; Sat, 16 Nov 1996 06:44:17 -0800 Received: from iol.unh.edu (sun4.iol.unh.edu [132.177.120.114]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA15466 for ; Sat, 16 Nov 1996 06:44:16 -0800 Received: from sparky.IOL.UNH.EDU by iol.unh.edu (4.1/SMI-4.1) id AA09903; Sat, 16 Nov 96 09:38:11 EST Received: by sparky.IOL.UNH.EDU (SMI-8.6/SMI-SVR4) id JAA24895; Sat, 16 Nov 1996 09:47:08 -0500 Date: Sat, 16 Nov 1996 09:47:08 -0500 Message-Id: <199611161447.JAA24895@sparky.IOL.UNH.EDU> From: Quaizar Vohra To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2491) Advanced API Specification In-Reply-To: <199611160246.SAA02790@feller.mentat.com> References: <199611160246.SAA02790@feller.mentat.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tim, > > 2) With regard to options and extention headers it appears as though > you have opted to make the kernel do more work and the user less > with regard to the formatting and presentation of the options > and extention headers. > I pretty much thought the same. But then I think, the kernel might want to insert its own options (like jumbo payload). Or TCP might want to add some bind update option. But still I would prefer that user pass the entire extension header and kernel appends or prepends its options to those extension headers. Quaizar ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Nov 16 14:32:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13210; Sat, 16 Nov 96 14:32:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13204; Sat, 16 Nov 96 14:32:04 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA12995; Sat, 16 Nov 1996 14:24:56 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA03106 for ; Sat, 16 Nov 1996 14:24:57 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA25016; Sat, 16 Nov 96 14:24:04 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id OAA04708; Sat, 16 Nov 1996 14:24:54 -0800 Date: Sat, 16 Nov 1996 14:24:54 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199611162224.OAA04708@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2492) Advanced API Specification Part II X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard and Matt, Unfortunately, I could not put this spec down. I have some more comments. 1) In section 2.1 you have defined the ip6hdr structure. It not clear why this structure needs to be defined in this draft. You have very explicitly not included any sort of HDRINCL facility so it would seem that this structure definition could be removed from the draft without any loss of functionality. If you do a search through the draft you will find that the structure is only reference in section 2.1 and in the table of contents. If this draft were a C program I think we would call section 2.1 "dead code". :-) 2) The source routing portions of the draft (section 8.) are well done. With the availability of this API people might actually use source routes. 3) I like the details in section 9., even though I don't like what the details are describing.:-) This level of description will go a long way towards making sure these facilities work the same on every platform. Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Nov 16 15:07:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13226; Sat, 16 Nov 96 15:07:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13220; Sat, 16 Nov 96 15:07:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA14293; Sat, 16 Nov 1996 15:00:27 -0800 Received: from oberon.di.fc.ul.pt (oberon.di.fc.ul.pt [192.67.76.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA05665 for ; Sat, 16 Nov 1996 15:00:15 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id WAA06735; Sat, 16 Nov 1996 22:59:30 GMT Date: Sat, 16 Nov 1996 22:59:30 GMT Message-Id: <199611162259.WAA06735@oberon.di.fc.ul.pt> From: Pedro Roque To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2493) Advanced API Specification Part II In-Reply-To: <199611162224.OAA04708@feller.mentat.com> References: <199611162224.OAA04708@feller.mentat.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Tim" == Tim Hartrick writes: Tim, Tim> 1) In section 2.1 you have defined the ip6hdr structure. It Tim> not clear why this structure needs to be defined in this Tim> draft. You have very explicitly not included any sort of Tim> HDRINCL facility so it would seem that this structure Tim> definition could be removed from the draft without any loss Tim> of functionality. If you do a search through the draft you Tim> will find that the structure is only reference in section 2.1 Tim> and in the table of contents. If this draft were a C program Tim> I think we would call section 2.1 "dead code". :-) Even without an HDRINCL facility defined the ip6hdr can be helpfull, for instance to make sure "tcpdump" compiles on every platform. Personally, I'm not too fond on the way the structure is defined (just a matter of taste) but it beats not having such a definition. But should we read your mail as a suggestion that an IPV6_HDRINCL setsockopt should be included ? If it is the case, i agree. ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Nov 16 20:45:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13280; Sat, 16 Nov 96 20:45:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13274; Sat, 16 Nov 96 20:45:17 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA01338; Sat, 16 Nov 1996 20:38:09 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA26290 for ; Sat, 16 Nov 1996 20:38:09 -0800 Received: from inner.net (lust.inner.net [199.33.248.1]) by inner.net (8.8.2/42) with ESMTP id EAA05783; Sun, 17 Nov 1996 04:37:55 GMT Message-Id: <199611170437.EAA05783@inner.net> To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2494) Re: Advanced API Specification Part II In-Reply-To: Your message of "Sat, 16 Nov 1996 14:24:54 PST." <199611162224.OAA04708@feller.mentat.com> X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Sat, 16 Nov 1996 23:37:52 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199611162224.OAA04708@feller.mentat.com>, you write: >1) In section 2.1 you have defined the ip6hdr structure. It not clear > why this structure needs to be defined in this draft. You have very > explicitly not included any sort of HDRINCL facility so it would seem > that this structure definition could be removed from the draft without > any loss of functionality. If you do a search through the draft you > will find that the structure is only reference in section 2.1 and in the > table of contents. If this draft were a C program I think we would > call section 2.1 "dead code". :-) I belive that the "HDRINCL" mode for IPv4 raw sockets is the only mode for IPv6 raw sockets done according to this spec. Perhaps the wording is not clear? -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Nov 16 21:14:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13295; Sat, 16 Nov 96 21:14:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13289; Sat, 16 Nov 96 21:14:42 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA02518; Sat, 16 Nov 1996 21:07:34 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA28066 for ; Sat, 16 Nov 1996 21:07:34 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA26422; Sat, 16 Nov 96 21:06:41 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id VAA05347; Sat, 16 Nov 1996 21:07:31 -0800 Date: Sat, 16 Nov 1996 21:07:31 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199611170507.VAA05347@feller.mentat.com> To: roque@di.fc.ul.pt Subject: (IPng 2495) Re: Advanced API Specification Part II Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pedro, > > Even without an HDRINCL facility defined the ip6hdr can be helpfull, > for instance to make sure "tcpdump" compiles on every platform. > Personally, I'm not too fond on the way the structure is defined (just a > matter of taste) but it beats not having such a definition. This is a valid point which I had not considered. > > But should we read your mail as a suggestion that an IPV6_HDRINCL setsockopt > should be included ? If it is the case, i agree. > Hmm... Well I have never been a big fan of IP_HDRINCL in IPv4 world simply because its behavior on various platforms was unpredictable. That is a documentation issue more than a techinical issue. I also have never really understood what it bought the application writer that the manipulation of a number of other options could not. Between IP_OPTIONS, IP_TOS, IP_TTL and probably others the same results could be obtained. Of course it requires more system calls to match the results of IP_HDRINCL. I am not fundamentally opposed to IPV6_HDRINCL being created I just don't know what it buys you that cannot be addressed using other mechanisms. Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Nov 16 21:18:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13307; Sat, 16 Nov 96 21:18:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13301; Sat, 16 Nov 96 21:18:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA02665; Sat, 16 Nov 1996 21:11:27 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA28311 for ; Sat, 16 Nov 1996 21:11:28 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA26432; Sat, 16 Nov 96 21:10:35 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id VAA05357; Sat, 16 Nov 1996 21:11:26 -0800 Date: Sat, 16 Nov 1996 21:11:26 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199611170511.VAA05357@feller.mentat.com> To: cmetz@inner.net Subject: (IPng 2496) Re: Advanced API Specification Part II Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, > > I belive that the "HDRINCL" mode for IPv4 raw sockets is the only mode > for IPv6 raw sockets done according to this spec. Perhaps the wording is not > clear? > That is not my interpretation of the specification. I don't see any mechanism defined in the specification which would allow the user to specify the entire IPv6 header to be used for a particular sendto call. I also don't see any mechanism which would allow the user the recieve the entire IPv6 header associated with a particular datagram. I may be misreading things, however. Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Nov 17 06:43:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13458; Sun, 17 Nov 96 06:43:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13452; Sun, 17 Nov 96 06:43:15 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA21097; Sun, 17 Nov 1996 06:36:07 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA25823 for ; Sun, 17 Nov 1996 06:36:07 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.2/8.7.3) with SMTP id HAA05007; Sun, 17 Nov 1996 07:36:06 -0700 (MST) Received: by kohala.kohala.com (SMI-8.6/SMI-SVR4) id HAA02483; Sun, 17 Nov 1996 07:36:00 -0700 Message-Id: <199611171436.HAA02483@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Sun, 17 Nov 1996 07:36:00 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: thartric@mentat.com (Tim Hartrick), ipng@sunroof.eng.sun.com Subject: (IPng 2497) Re: Advanced API Specification Part II Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Nov 16, 2:24pm you write:] > > 1) In section 2.1 you have defined the ip6hdr structure. It not clear > why this structure needs to be defined in this draft. You have very > explicitly not included any sort of HDRINCL facility so it would seem > that this structure definition could be removed from the draft without > any loss of functionality. I've written versions of Ping and Traceroute for IPv6 and needed this structure for both programs: to examine the next header field and the hop limit, for example. Since a raw socket returns data beginning with the entire IPv6 header, I think we need the definition. Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Nov 17 13:30:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13589; Sun, 17 Nov 96 13:30:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13583; Sun, 17 Nov 96 13:29:56 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA06511; Sun, 17 Nov 1996 13:22:47 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA00030 for ; Sun, 17 Nov 1996 13:22:46 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.2/8.7.3) with SMTP id OAA05148; Sun, 17 Nov 1996 14:22:45 -0700 (MST) Received: by kohala.kohala.com (SMI-8.6/SMI-SVR4) id OAA02810; Sun, 17 Nov 1996 14:22:45 -0700 Message-Id: <199611172122.OAA02810@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Sun, 17 Nov 1996 14:22:44 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: thartric@mentat.com (Tim Hartrick), ipng@sunroof.eng.sun.com Subject: (IPng 2498) Re: Advanced API Specification Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Nov 15, 6:46pm you write:] > > 1) In the portion which lists the "how-to's" of requesting the various > options you have: > > setsockopt(fd, IPPROTO_IPV6, IPV6_RXINFO, &on, sizeof(on)); > setsockopt(fd, IPPROTO_IPV6, IPV6_RXHOPOPTS, &on, sizeof(on)); > setsockopt(fd, IPPROTO_IPV6, IPV6_RXDSTOPTS, &on, sizeof(on)); > setsockopt(fd, IPPROTO_ROUTING, IPV6_RXSRCRT, &on, sizeof(on)); > > Should the last item be an IPPROTO_IPV6 level option? What is different > about the IPV6_RXSRCRT option which makes it not an IPPROTO_IPV6 level > option? I guess that was a couple of questions wasn't it :-). As I recall the desire was to have the setsockopt() "level" (the 2nd arg) the same as the cmsg_level. But if not having them the same is OK, then IPPROTO_IPV6 is fine with me. > 2) With regard to options and extention headers it appears as though > you have opted to make the kernel do more work and the user less > with regard to the formatting and presentation of the options > and extention headers. > ... > Given that kernel time is usually more precious than user time it would > seem that having the user build the entire extension header could have > some efficiency benefits. > ... > I assume you guys considered this approach and rejected it for some > reason. Can you explain the rational for rejecting the above scheme > in favor of the scheme described in the draft. I'll defer to Matt for this one. It also gets complicated if you allow the user to send a destination or hop-by-hop option that the kernel doesn't understand (say when new ones are first tried), as there needs to be some way to encode the Xn+Y alignment requirements from the user to the kernel (Appendix A of RFC 1883 is a nice example). > 3) With respect to section 2. Do we need some "Common Structures and > Definitions" which define what hop-by-hop and destination options. > Specifically, the various bits in the option which describe the > actions to be taken by the receiver probably need to be defined. > The existing types probably need to be defined as well (PAD1, PADN, > others?). Yes. Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Nov 17 13:37:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13602; Sun, 17 Nov 96 13:37:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13596; Sun, 17 Nov 96 13:36:57 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA06981; Sun, 17 Nov 1996 13:29:48 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA00906 for ; Sun, 17 Nov 1996 13:29:48 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.2/8.7.3) with SMTP id OAA05155; Sun, 17 Nov 1996 14:29:47 -0700 (MST) Received: by kohala.kohala.com (SMI-8.6/SMI-SVR4) id OAA02827; Sun, 17 Nov 1996 14:29:47 -0700 Message-Id: <199611172129.OAA02827@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Sun, 17 Nov 1996 14:29:47 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: thartric@mentat.com (Tim Hartrick), ipng@sunroof.eng.sun.com Subject: (IPng 2499) Re: Advanced API Specification Part II Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Nov 16, 2:24pm you write:] > > Unfortunately, I could not put this spec down. I don't know if that's good or bad :-) > 2) The source routing portions of the draft (section 8.) are well done. > With the availability of this API people might actually use source > routes. Kudos to Matt for those functions. I recently took Matt's functions and changed them for IPv4 (what an undocumented mess the IP_OPTIONS socket option is!) and they were easy to implement. > 3) I like the details in section 9., even though I don't like what the > details are describing.:-) This level of description will go a long > way towards making sure these facilities work the same on every > platform. That's the goal. Matt and I are actually surprised by how few comments we've gotten on the draft to date. Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Nov 17 14:02:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13631; Sun, 17 Nov 96 14:02:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13625; Sun, 17 Nov 96 14:01:58 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA08335; Sun, 17 Nov 1996 13:54:49 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA04348 for ; Sun, 17 Nov 1996 13:54:50 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA29826; Sun, 17 Nov 96 13:54:00 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id NAA06977; Sun, 17 Nov 1996 13:54:51 -0800 Date: Sun, 17 Nov 1996 13:54:51 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199611172154.NAA06977@feller.mentat.com> To: rstevens@kohala.com Subject: (IPng 2500) Re: Advanced API Specification Part II Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, > > I don't know if that's good or bad :-) > It is bad (for me). Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Nov 17 14:18:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13679; Sun, 17 Nov 96 14:18:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13673; Sun, 17 Nov 96 14:17:50 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA09343; Sun, 17 Nov 1996 14:10:41 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAB06745 for ; Sun, 17 Nov 1996 14:10:40 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA29887; Sun, 17 Nov 96 14:09:42 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id OAA07000; Sun, 17 Nov 1996 14:10:33 -0800 Date: Sun, 17 Nov 1996 14:10:33 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199611172210.OAA07000@feller.mentat.com> To: rstevens@kohala.com Subject: (IPng 2501) Re: Advanced API Specification Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, > > I'll defer to Matt for this one. It also gets complicated if you allow > the user to send a destination or hop-by-hop option that the kernel doesn't > understand (say when new ones are first tried), as there needs to be some > way to encode the Xn+Y alignment requirements from the user to the kernel > (Appendix A of RFC 1883 is a nice example). It is certainly true that we do not want the user groveling about attempting to solve all the various alignment and padding issues. However, I suspect that we could devise a set of inet6_xxx library routines which could be used to construct and parse full hop-by-hop and destination options extension headers. These routines would deal with the padding and alignment problems. These routines would be akin to the routines you guys have specified for manipulation of source routes. Clearly the tedium of getting the extension head properly aligned and padded needs to be dealt with somewhere. I would prefer that it be dealt with in user space where efficiency is not as large an issue. I suspect that moving to this type of scheme could help simplify the rules in section 9 as well. Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Nov 17 18:49:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13744; Sun, 17 Nov 96 18:49:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13738; Sun, 17 Nov 96 18:49:06 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA21581; Sun, 17 Nov 1996 18:41:57 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA04314 for ; Sun, 17 Nov 1996 18:41:56 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA01235; Sun, 17 Nov 96 18:41:02 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id SAA07434; Sun, 17 Nov 1996 18:41:52 -0800 Date: Sun, 17 Nov 1996 18:41:52 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199611180241.SAA07434@feller.mentat.com> To: roque@di.fc.ul.pt Subject: (IPng 2502) Re: Advanced API Specification Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pedro, > > While i agree with you in that i would like to see the dull work of > formating those headers in user space there i fear that with will > raise a priviledge issue. As not to send bogus packets you would > have to limit those options to priviledged users... > That might be limitative to the usage of some options (or raise a new > set of setuid holes) > If real authentication and encryption were not a requirement of IPv6 I would agree completely. Since they are a requirement I am not sure that this is a serious issue. Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Nov 17 19:30:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13801; Sun, 17 Nov 96 19:30:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13795; Sun, 17 Nov 96 19:30:43 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA23530; Sun, 17 Nov 1996 19:23:34 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA09597 for ; Sun, 17 Nov 1996 19:23:34 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id WAA12916; Sun, 17 Nov 1996 22:17:12 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA00752; Sun, 17 Nov 1996 22:17:11 -0500 Message-Id: <9611180317.AA00752@wasted.zk3.dec.com> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2503) Re: W.G. Last Call on "Generic Packet Tunneling in IPv6 In-Reply-To: Your message of "Fri, 15 Nov 96 18:46:54 PST." <3.0.32.19961115184639.006f0b4c@mailhost.ipsilon.com> Date: Sun, 17 Nov 96 22:17:11 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, >>came to mind that the tunnel spec also states the tunnel-limit creates >>an exception to the dst options processing. Right now only hosts look >>at the dst options but for tunnels the routers need to so they can see >>this new dst option. >I may be confused, but I think that only the end points of the tunnel need >to process this option. This makes it appropriate for a destination >option. The routers at each of the tunnel source and sink these packets. >If it were a secure tunnel they would also process the security >encapsulation headers. Well see attached. Every entry point to the tunnel must look at the tunnel-limit and that can be a router. The attached is the reference you sent me in a previous mail message. RFC 1883 IMO implies end points are Hosts not routers, because they are referenced as the packets destination end-point. An entry point is a destination end-point if it is an entry point in a nested tunnel. But I think it takes liberty with the interpretation of RFC 1883. In fact the tunnel text for 4.1.1 below points out that this creates an exception for destination options in its own spec. I still think the WG (in addition to yourself) needs to think if it may want to have a tunnel limit option defined in RFC 1883. ********************************* 4.1.1 Tunnel Encapsulation Limit The "Tunnel Encapsulation Limit" destination option is provided only by tunnel entry-point nodes, it is discarded only by tunnel exit- point nodes, and it is used to carry optional information [RFC-1883] that need be examined only by tunnel entry-point nodes. The "Tunnel Encapsulation Limit" destination option is defined as follows: Option Type Opt Data Len Opt Data Len 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 0 0| 1 | Tun Encap Lim | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type value 4 - the highest-order two bits - set to 00 - indicate "skip over this option if the option is not recognized". - the third-highest-order bit - set to 0 - indicates that the option data in this option does not change en route to the packet's destination [RFC-1883]. Opt Data Len value 1 - the data portion of the Option is one byte long. Opt Data Value the Tunnel Encapsulation Limit value - 8-bit unsigned integer. To avoid excessive nested encapsulation, an IPv6 tunnel entry-point node may prepend to a packet undergoing encapsulation a "Tunnel Encapsulation Limit - Destination Option". The "OptData Value" field of the option is set to: (a) a pre-configured value - if the packet being encapsulated has no IPv6 destination options header or no "Tunnel Encapsulation Limit" option in such a header - see section 6.6. (b) a value resulting from a value stored in the IPv6 destination options header - if such a header exist and if it contains a "Tunnel Encapsulation Limit" option. The "OptData Value" of the extant option is copied into the newly prepended "Tunnel Encapsulation Limit" option and then decremented by one. This is an exception to the rule of processing a destination options extension header in that, although the entry-point node is not a destination node, during encapsulation, the IPv6 tunneling protocol engine looks ahead, for an IPv6 destination header with a "Tunnel Encapsulation Limit" option immediately following the current IPv6 main header. *** Right here in the spec it says "even though the entry-point is not..." If the Tunnel Encapsulation Limit is decremented to zero, the packet undergoing encapsulation is discarded. When the packet is discarded, a Parameter Problem ICMP message [RFC-1885] is returned to the packet originator, which is the previous tunnel entry-point. The message points to the Opt Data Value field within the Tunnel Encapsulation Limit destination header of the packet. The field pointed to has a value of one. ********************************************** >>Do we need to add a new set of tunnel options to the base RFC 1883 spec >>to avoid such an exception. >As stated above, I don't think it is an exception. Well the spec itself calls it out as an exception. >>The reason I suggested the routing area is because we are asking routers >>to look inside the packet in this spec for dst options now? >The routing area deals with routing protocols, not routers. Many things >routers are required to do are not specified in the routing area. IPv6 >itself comes to mind :-) Of course, I have been around here for awhile working on protocols now! But which Area is responsible for tunneling across an Internet that mostly will involve routers? We are not doing OSPFv6 in the IPng WG, its being done in the routing area and IPv6 over ATM is being done in ION. I think your position above is an old position and should not be the present one for IPv6. But as it started here in IPng we should finish here, but I think running it by the routing area is wise so it don't get blasted out at Last Call by folks in that area. >I hope this resolves your issues. Not at all. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Nov 17 20:11:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13821; Sun, 17 Nov 96 20:11:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13815; Sun, 17 Nov 96 20:11:40 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA25607; Sun, 17 Nov 1996 20:04:30 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA15889 for ; Sun, 17 Nov 1996 20:04:30 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id WAA31506; Sun, 17 Nov 1996 22:59:29 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA02403; Sun, 17 Nov 1996 22:59:27 -0500 Message-Id: <9611180359.AA02403@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: rstevens@kohala.com, ipng@sunroof.eng.sun.com Subject: (IPng 2504) Re: Advanced API Specification In-Reply-To: Your message of "Sun, 17 Nov 96 14:10:33 PST." <199611172210.OAA07000@feller.mentat.com> Date: Sun, 17 Nov 96 22:59:27 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, I don't agree with you regarding this being done in user space for several reasons. 1. I think the implementaton will perform faster if it is not done in user space. 2. Kernel bloat is one reason to not put any code in the kernel when it can be done in user space. But this is not the case as depending on how you define and process IP packets in your implementation providing this to user space is not a major task. I agree that if the implementation does this poorly in the kernel by design (ala BSD standard ip code) then better off to send it up to the user app, but those old error in our ways with IPv4 should not continue. IPv6 is an opportunity to clean up the kernel processing for IP packets. 3. I think asking application developers to parse raw bits when its not necessary is not good engineering on the part of kernel developers. 4. I would like to see a concrete reason why you want this in user space I have not heard one yet? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 18 11:40:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14337; Mon, 18 Nov 96 11:40:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14331; Mon, 18 Nov 96 11:40:14 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA03575; Mon, 18 Nov 1996 11:33:04 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA11604 for ; Mon, 18 Nov 1996 11:33:00 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA05651; Mon, 18 Nov 96 11:31:56 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id LAA08972; Mon, 18 Nov 1996 11:32:47 -0800 Date: Mon, 18 Nov 1996 11:32:47 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199611181932.LAA08972@feller.mentat.com> To: bound@zk3.dec.com Subject: (IPng 2505) Re: Advanced API Specification Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > 3. I think asking application developers to parse raw bits > when its not necessary is not good engineering on the part of > kernel developers. I would not have that either. That is why I proposed in some mail to Richard that we devise a set of inet6_xxx type routines to do the bit fiddling for the user. This scheme seems to be just dandy for routing headers. Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 18 11:41:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14344; Mon, 18 Nov 96 11:41:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13958; Mon, 18 Nov 96 02:16:07 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA15345; Mon, 18 Nov 1996 02:08:57 -0800 Received: from ercole.cefriel.it (ercole.cefriel.it [131.175.5.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA09597 for ; Mon, 18 Nov 1996 02:08:19 -0800 Received: from espo.cefriel.it ([131.175.4.136]) by ercole.cefriel.it (8.7.5/8.7.3) with SMTP id LAA23277 for ; Mon, 18 Nov 1996 11:05:10 +0100 (MET) Message-Id: <2.2.32.19961118100602.006bf5a8@mailer.cefriel.it> X-Sender: esposito@mailer.cefriel.it X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Nov 1996 11:06:02 +0100 To: ipng@sunroof.eng.sun.com From: Sergio Esposito Subject: (IPng 2506) any translators? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, is there work in progress about ipv4/ipv6 translators? Are there implementations? Thank you for your help, Sergio Esposito ============================================================================ Organization : CEFRIEL Address : Via Emanueli, 15 - 20126 MILANO (Italy) Phone : +39-2-66161.211 / +39-2-66161.1 FAX : +39-2-66161.448 Interests : IPv6, IPSec, VPN e-mail : esposito@mailer.cefriel.it www : ============ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 18 11:50:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14366; Mon, 18 Nov 96 11:50:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14074; Mon, 18 Nov 96 07:40:28 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA09247; Mon, 18 Nov 1996 07:33:18 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA10057 for ; Mon, 18 Nov 1996 07:32:51 -0800 Received: from ietf.org by ietf.org id aa05612; 18 Nov 96 9:52 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: (IPng 2507) I-D ACTION:draft-ietf-ipngwg-multicast-assgn-01.txt Date: Mon, 18 Nov 1996 09:52:35 -0500 Message-Id: <9611180952.aa05612@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPv6 Multicast Address Assignments Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipngwg-multicast-assgn-01.txt Pages : 8 Date : 11/15/1996 This document defines the initial assignment of IPv6 multicast addresses. It is based on the "RFC-1884 IP Version 6 Addressing Architecture" [RFC1884] and current IPv4 multicast address assignment found in . It adapts the IPv4 assignments that are relevant to IPv6 assignments. IPv4 assignments that were not relevant were not converted into IPv6 assignments. Comments are solicited on this conversion. All other IPv6 multicast addresses are reserved. Sections 2 and 3 specify reserved and preassigned IPv6 multicast addresses. Section 4 defines guidelines for assigning new IPv6 multicast addresses. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-multicast-assgn-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-multicast-assgn-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-multicast-assgn-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115104009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-multicast-assgn-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-multicast-assgn-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115104009.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 18 18:32:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14940; Mon, 18 Nov 96 18:32:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14934; Mon, 18 Nov 96 18:32:01 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA21784; Mon, 18 Nov 1996 18:24:51 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA22941 for ; Mon, 18 Nov 1996 18:24:51 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id VAA17007; Mon, 18 Nov 1996 21:17:09 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA21859; Mon, 18 Nov 1996 21:17:08 -0500 Message-Id: <9611190217.AA21859@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2508) Re: Advanced API Specification In-Reply-To: Your message of "Mon, 18 Nov 96 11:32:47 PST." <199611181932.LAA08972@feller.mentat.com> Date: Mon, 18 Nov 96 21:17:08 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, >I would not have that either. That is why I proposed in some mail to >Richard that we devise a set of inet6_xxx type routines to do the bit >fiddling for the user. This scheme seems to be just dandy for routing >headers. OK..... sorry I missed the point.... I am using this now it is good and robust but intense (not that this is bad but the more I use it I like it). Matt and Ricahard did a good job on this spec. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 18 19:28:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15037; Mon, 18 Nov 96 19:28:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15031; Mon, 18 Nov 96 19:28:43 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA27700; Mon, 18 Nov 1996 19:21:32 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA03791 for ; Mon, 18 Nov 1996 19:21:30 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA08505; Mon, 18 Nov 96 19:20:11 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id TAA09712; Mon, 18 Nov 1996 19:21:03 -0800 Date: Mon, 18 Nov 1996 19:21:03 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199611190321.TAA09712@feller.mentat.com> To: bound@zk3.dec.com Subject: (IPng 2509) Re: Advanced API Specification Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > 1. I think the implementaton will perform faster if it is not done > in user space. Possibly. But I did not say anything about speed. I did mention efficiency. > 3. I think asking application developers to parse raw bits > when its not necessary is not good engineering on the part of > kernel developers. See my previous mail. I am not asking them to do that. > 4. I would like to see a concrete reason why you want this in > user space I have not heard one yet? > Hmm... Well I am not guessing that anything I say on this topic is "concrete" enough for you but I love pointless rhetoric so here goes. In designing an API there are some things that probably should be considered. 1) Efficiency. This is a bit subjective. a) How many individual copyin's and copyout's are required in order to do something with the API. Also how much formatting of meta-data (cmsg- hdr's in this case) is required for each copyin or copyout operation. b) How much additional parsing, searching, reformatting and copying needs to be done after the copyin's or before the copyout's. 2) Usability. This is a more subjective area. But there are some things which I think most people can agree on. a) Completeness. One would like to be able to specify any legal packet format using the interface. b) Simplicity. This is really subjective but... What one would like is a simple set of composition rules that map directly to how the packet will look on the wire. These composition rules will probably have a direct impact on 1b) as well. Given the above set of criteria, which I am sure you do not agree with, lets see how the current draft scores vs. the scheme I am suggesting. 1) Efficiency. In the case of copyins both schemes will need to copyin a msg_control area. The scheme described in the current draft requires quite a bit more meta-data formatting since every option will be passed in seperately. It also requires more shuffling of data once the copyin is complete. Each cmsghdr will need to be parsed individually and placed in the appropriate portion of the outgoing packet. Since the user is free to place hop-by-hop options anywhere in the chain of options, we face having shuffle already complete packet contents around in order to make room for newly discovered hop-by-hop options. The scheme I am proposing has a single meta-data item to construct for each extension header. All the formatting, copying and aligning would be taken care of in user space by some inet6_xxx facilities. In the case of copyouts the scheme described in the draft requires that each requested option be copied into its own cmsghdr area. It also requires that the extension header be searched in order to locate the specific option that is requested by the cmsghdr. The scheme I am proposing has a single copyout for each extension header. All the parsing and searching is taken care of by some inet6_xxx facilities. 2) Usability. The current draft does not allow the user to easily specify multiple destination options extension headers even though it is perfectly legal to do so. The scheme I am proposing allows for multiple destination options extension headers of any size up to the limit specified by the protcol. On the simplicity front. If we look at section 9. of the current draft we see ordering and placement restrictions on the individual cmsghdr structures. Section 9. describes a specific example where the user lays out a set of options in a specific order and those options get reordered. This is a clear case where the API is not faithfully translating the desires of the user into a packet. This could be corrected I suspect by making use of PAD options instead of reordering. The scheme I am proposing would always faithfully translate the users desires into a packet assuming the users desires were legal. That is because the the user would have the option of constructing his own extension headers by hand if he did not trust the inet6_xxx options utilities provided by the library. In closing, I want to make it clear that I think the vast majority of this document is great. I have implemented, tested and debugged enough API options code to last a lifetime (2 implementations of sockets, XTI and TLI). What I have concluded is that the less frequently a particular facility is used the simpler its implementation should be. That is why I like the source routing facility in this document so much. It gives the user maximal control and keeps the interface between the user and the proto- col dead simple. Unfortunately, the options facility does not have the same properties. Blast away. Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 18 20:52:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15102; Mon, 18 Nov 96 20:52:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15096; Mon, 18 Nov 96 20:52:13 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA05027; Mon, 18 Nov 1996 20:45:02 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA17700 for ; Mon, 18 Nov 1996 20:45:03 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA15968; Mon, 18 Nov 1996 23:39:55 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA26548; Mon, 18 Nov 1996 23:39:55 -0500 Message-Id: <9611190439.AA26548@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2510) Re: Advanced API Specification In-Reply-To: Your message of "Mon, 18 Nov 96 19:21:03 PST." <199611190321.TAA09712@feller.mentat.com> Date: Mon, 18 Nov 96 23:39:54 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, #1 that took some time, thought, and expertise around APIs. #2 you gave good concrete "technical" reasons and concerns, that were communicated clearly with words. #3 you convinced me your idea needs to be reviewed and seriously considered. #4 I was just working on how I could get dst options to a udp app for anycast address update and dynamic renumbering and I ran into the options too. So I see what your saying.... #5 at this point I would like to see the authors response.... Excellent Response...and I do agree with your subjective views on Efficiency and Usability. The response was concrete as opposed to abstract which is what I needed to see. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 19 00:32:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15200; Tue, 19 Nov 96 00:32:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15194; Tue, 19 Nov 96 00:32:25 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA22313; Tue, 19 Nov 1996 00:25:14 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA19275 for ; Tue, 19 Nov 1996 00:25:14 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id JAA28120 for ; Tue, 19 Nov 1996 09:25:12 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA08760; Tue, 19 Nov 1996 09:25:12 +0100 Message-Id: <9611190825.AA08760@dxcoms.cern.ch> Subject: (IPng 2511) IPv6 over IPv4 without tunnels To: ipng@sunroof.eng.sun.com Date: Tue, 19 Nov 1996 09:25:12 +0100 (MET) From: "Brian Carpenter CERN-CN" 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 Hi, I've just submitted an Internet Draft by Cyndi Jung and myself entitled "Transmission of IPv6 Packets over IPv4 Networks without Tunnels" If you really can't wait, it is stored *for a few days only* at http://wwwcs.cern.ch/wwwcs/public/6over4.txt The key motivation for this draft is: IPv6 hosts connected using this method do not require IPv4-compatible addresses or configured tunnels. In this way IPv6 gains considerable independence of the underlying links and can step over many hops of IPv4 subnets. Brian Carpenter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 19 08:18:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15403; Tue, 19 Nov 96 08:18:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15397; Tue, 19 Nov 96 08:18:39 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA24706; Tue, 19 Nov 1996 08:11:28 -0800 Received: from iol.unh.edu (sun4.iol.unh.edu [132.177.120.114]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA24624 for ; Tue, 19 Nov 1996 08:11:27 -0800 Received: from sparky.IOL.UNH.EDU by iol.unh.edu (4.1/SMI-4.1) id AA12525; Tue, 19 Nov 96 11:02:48 EST Received: by sparky.IOL.UNH.EDU (SMI-8.6/SMI-SVR4) id LAA27302; Tue, 19 Nov 1996 11:11:45 -0500 Date: Tue, 19 Nov 1996 11:11:45 -0500 Message-Id: <199611191611.LAA27302@sparky.IOL.UNH.EDU> From: Quaizar Vohra To: thartric@mentat.com (Tim Hartrick) Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 2512) Re: Advanced API Specification In-Reply-To: <199611190321.TAA09712@feller.mentat.com> References: <199611190321.TAA09712@feller.mentat.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tim, I think that simplicity of extension header processing within the kernel is very important and I like what you are proposing. I have seen that simply trying to gain efficiency for something which might occur infrequently (or whose frequency of occurance is not very clear at all) makes code in the kernel very complex and much less flexible. Also by parsing incoming options in the kernel (before passing them out to the application) you are giving priority to something which is not as important as other tasks of the kernel. But my only concern with your proposal is how would you insert options which are not user defined, but come from within the kernel. You will still need shuffling. I wish we can have something like being able to define another extension header, or defining a set of rules that allows prepending or appending of in-kernel options. Quaizar ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 19 08:31:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15436; Tue, 19 Nov 96 08:31:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15430; Tue, 19 Nov 96 08:31:34 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA26481; Tue, 19 Nov 1996 08:24:23 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA28669 for ; Tue, 19 Nov 1996 08:24:22 -0800 Received: from muggsy.lkg.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA30084; Tue, 19 Nov 1996 11:06:04 -0500 (EST) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA28412; Tue, 19 Nov 1996 11:06:01 -0500 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id MAA22558; Tue, 19 Nov 1996 12:11:35 GMT Message-Id: <199611191211.MAA22558@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2513) Re: Advanced API Specification In-Reply-To: Your message of "Fri, 15 Nov 1996 18:46:48 PST." <199611160246.SAA02790@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Nov 1996 12:11:34 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > Richard and Matt, > > I have a couple comments/questions about the advanced API draft. > > All of my comments and questions are regarding section 4.3 and section 2. > respectively. > [...snip...] > Specifically, one could specify a single ancillary data item which > had a level of IPPROTO_IPV6 and a type of IPPROTO_HOPOPTS. This > ancillary data item would contain a pre-built and pre-padded hop-by-hop > option header. Obviously the same approach would work for destination > options as well. This single ancillary data item would then be > passed into the kernel using sendmsg. But the kernel (IMO) will still need to validate the header. Whether that takes less time than building the header I can't say. I did it the way in the spec due to a misunderstanding of how options worked. > The receive side would be the reverse. The kernel would simply pass > the entire extension header to the user in a single ancillary data > item. > > I assume you guys considered this approach and rejected it for some > reason. Can you explain the rational for rejecting the above scheme > in favor of the scheme described in the draft. Since my rational for the current method has been proved to be in error, I'll probably do something similar to what is being done with source routes. > 3) With respect to section 2. Do we need some "Common Structures and > Definitions" which define what hop-by-hop and destination options. Yes. Except the only option defined right now is the jumbogram option and that's just a 4 byte integer. Mobile IPv6 has a number of options but they certainly are not in a state to be defined. > Specifically, the various bits in the option which describe the > actions to be taken by the receiver probably need to be defined. > The existing types probably need to be defined as well (PAD1, PADN, > others?). Good point. Those should probably be defined. Thanks for the comments, -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 19 09:20:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15514; Tue, 19 Nov 96 09:20:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15508; Tue, 19 Nov 96 09:20:01 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA04898; Tue, 19 Nov 1996 09:12:50 -0800 Received: from jennie.bellcore.com (jennie.bellcore.com [192.4.15.79]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA16954 for ; Tue, 19 Nov 1996 09:12:46 -0800 Received: from bellcore.com (localhost [127.0.0.1]) by jennie.bellcore.com (8.6.9/8.6.10) with ESMTP id MAA10865; Tue, 19 Nov 1996 12:12:30 -0500 Message-Id: <199611191712.MAA10865@jennie.bellcore.com> To: ion@nexen.com, 6bone@isi.edu, ipng@sunroof.eng.sun.com Cc: gja@bellcore.com Subject: (IPng 2514) Revised IPv6/ATM draft now available. Date: Tue, 19 Nov 1996 12:12:27 -0500 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peoples, draft-armitage-ion-tn-01.txt has now been released. It is a synthesis of the Transient Neighbors model from draft-armitage-ion-tn-00.txt and the IPv6 specific text from draft-ietf-ion-ipv6atm-framework-00.txt, both presented at the ION meeting in June 96. Whilst initially targetted at IPv6 over ATM, it is also applicable to non-ATM NBMA environments where appropriate intra-link NBMA support for multicasting is available (or emulatable). I maintain a web page for this work: http://gump.bellcore.com:8000/~gja/iv6-drafts.html There is also a set of slides available from the June ION presentation on the Transient Neighbors model. Anonymous ftp from ftp.bellcore.com, the file is named /pub/gja/ipv6/transient-Jun96.ps.Z (or try ftp://ftp.bellcore.com/pub/gja/ipv6/transient-Jun96.ps.Z) Comments welcome, but please send them to the ION working group's list (ion@nexen.com) only, unless they're of IPv6 specific nature. cheers, gja _________________________________________________________________________ Grenville Armitage http://gump.bellcore.com:8000/~gja/home.html Have you hugged your home page today? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 19 11:45:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15788; Tue, 19 Nov 96 11:45:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15782; Tue, 19 Nov 96 11:44:48 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA07925; Tue, 19 Nov 1996 11:37:38 -0800 Received: from lobster.wellfleet.com (lobster.corpeast.baynetworks.com [192.32.253.3]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA17765 for ; Tue, 19 Nov 1996 11:37:35 -0800 Received: from pobox.BayNetworks.com by lobster.wellfleet.com (SMI-8.6/SMI-4.1) id OAA26158; Tue, 19 Nov 1996 14:41:28 -0500 Received: from andover.engeast by pobox.BayNetworks.com (SMI-8.6/SMI-SVR4) id OAA28934; Tue, 19 Nov 1996 14:37:30 -0500 Date: Tue, 19 Nov 1996 14:37:30 -0500 From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <199611191937.OAA28934@pobox.BayNetworks.com> To: brian@dxcoms.cern.ch, cmj@NSD.3Com.com Subject: (IPng 2515) Re: IPv6 over IPv4 without tunnels Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Cyndi, I've had a quick look at your "Transmission of IPv6 Packets over IPv4 Networks without Tunnels" draft. To get picky, I think claiming that there is no tunneling involved in the proposed scheme is stretching the point. What you're proposing is the automatic (in the NGTRANS terminology) or open-end Ipv6-in-Ipv4 tunneling with an IPv4 address resolution capability so that IPv4-compatible addresses will not be required for isolated hosts. This is a step forward. In regard to section 7, a solution to use a limited IP brodcast address (255.255.255.255) address in the absence of IPv4 multicast support will not work. I'm not aware of any IP routers that will forward packets addressed to 255.255.255.255. This is actually prohibited in the Router Requirements spec. I guess in a very limited network environment you may try to bridge IPv6 Neighbor Solicitation packets via bridge-routers that don't support IPv6 and get the same intended result. Regards, Dimitry > From owner-ipv6 Tue Nov 19 03:39 EST 1996 > Subject: (IPng 2511) IPv6 over IPv4 without tunnels > To: ipng@sunroof.Eng.Sun.COM > Date: Tue, 19 Nov 1996 09:25:12 +0100 (MET) > From: "Brian Carpenter CERN-CN" > X-Mailer: ELM [version 2.4 PL25] > Mime-Version: 1.0 > Content-Transfer-Encoding: 7bit > Sender: owner-ipv6 > Content-Type> : > text/plain> ; > charset=US-ASCII> > Content-Length: 832 > > Hi, > > I've just submitted an Internet Draft by Cyndi Jung and myself entitled > "Transmission of IPv6 Packets over IPv4 Networks without Tunnels" > > If you really can't wait, it is stored *for a few days only* at > http://wwwcs.cern.ch/wwwcs/public/6over4.txt > > The key motivation for this draft is: > > IPv6 hosts connected using this method do not require IPv4-compatible > addresses or configured tunnels. In this way IPv6 gains considerable > independence of the underlying links and can step over many hops of > IPv4 subnets. > > Brian Carpenter > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 19 13:29:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15929; Tue, 19 Nov 96 13:29:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15923; Tue, 19 Nov 96 13:29:39 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA02127; Tue, 19 Nov 1996 13:22:28 -0800 Received: from brahma.sics.se (brahma.sics.se [193.10.66.43]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA22594 for ; Tue, 19 Nov 1996 13:22:27 -0800 Received: from tott.sics.se by brahma.sics.se (8.7.3/SICS) with ESMTP id WAA10018; Tue, 19 Nov 1996 22:21:04 +0100 (MET) Message-Id: <199611192121.WAA10018@brahma.sics.se> X-Mailer: exmh version 1.6.9 8/22/96 To: Matt Thomas Cc: thartric@mentat.com (Tim Hartrick), ipng@sunroof.eng.sun.com Subject: (IPng 2516) Re: Advanced API Specification In-Reply-To: Your message of "Tue, 19 Nov 1996 12:11:34 GMT." <199611191211.MAA22558@whydos.lkg.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Nov 1996 22:20:54 +0100 From: Peter Sjodin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, > > Specifically, one could specify a single ancillary data item which > > had a level of IPPROTO_IPV6 and a type of IPPROTO_HOPOPTS. This > > ancillary data item would contain a pre-built and pre-padded hop-by-hop > > option header. Obviously the same approach would work for destination > > options as well. This single ancillary data item would then be > > passed into the kernel using sendmsg. > > But the kernel (IMO) will still need to validate the header. Whether that > takes less time than building the header I can't say. I did it the way in > the spec due to a misunderstanding of how options worked. Just some thoughts on this: Letting the application build the header has the advantage of making it possible to minimize the overhead for building headers: a header doesn't have to be built each time a packet is sent, but only when the application wants to use a different header. It would be good to be able to validate headers in a similar way. This could be done through a socket option that tells the kernel "this is the header to use in forthcoming packets". This is similar to how IPv4 options are handled, but hiding the details of header formatting in the library. It could be combined with the sendmsg() approach -- a default header specified through a socket option could be overridden by a header specified as ancillary data in a sendmsg() call. I guess the same applies to source routes. Peter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 19 13:43:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15965; Tue, 19 Nov 96 13:43:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15958; Tue, 19 Nov 96 13:43:14 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA04821; Tue, 19 Nov 1996 13:36:03 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA27037 for ; Tue, 19 Nov 1996 13:36:02 -0800 Received: from gungnir.fnal.gov ("port 34760"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IC19XHMB6S00072U@FNAL.FNAL.GOV>; Tue, 19 Nov 1996 15:35:59 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id PAA00264; Tue, 19 Nov 1996 15:35:06 -0600 Date: Tue, 19 Nov 1996 15:35:05 -0600 From: Matt Crawford Subject: (IPng 2517) Re: IPv6 over IPv4 without tunnels In-Reply-To: "19 Nov 1996 09:25:12 +0100." <"9611190825.AA08760"@dxcoms.cern.ch> To: Brian Carpenter CERN-CN Cc: ipng@sunroof.eng.sun.com Message-Id: <199611192135.PAA00264@gungnir.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16744; Wed, 20 Nov 96 10:26:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16639; Wed, 20 Nov 96 08:40:54 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA10415; Wed, 20 Nov 1996 08:33:41 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA10134 for ; Wed, 20 Nov 1996 08:33:40 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA18908; Wed, 20 Nov 1996 11:21:44 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA22632; Wed, 20 Nov 1996 11:21:27 -0500 Message-Id: <9611201621.AA22632@wasted.zk3.dec.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2518) Re: IPv6 over IPv4 without tunnels In-Reply-To: Your message of "Tue, 19 Nov 96 09:25:12 +0100." <9611190825.AA08760@dxcoms.cern.ch> Date: Wed, 20 Nov 96 11:21:27 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian/Cyndi, This is a really good idea. This should be on the IPng WG agenda too for San Jose. I think it should be discussed on ipng not ngtrans as other input, but see comment below. >The key motivation for this draft is: > > IPv6 hosts connected using this method do not require IPv4-compatible > addresses or configured tunnels. In this way IPv6 gains considerable > independence of the underlying links and can step over many hops of > IPv4 subnets. I don't think it eliminates the use of configured tunnels though. If I want to have a tunnel btw node A at x.y.z Digital and a.b.c. in Cern on the Internet I should be able to still do that and especially if there is not capable IPv6 router on my link. But I do think it eliminates the need for an IPv4-compat address is my first impression (and that does releate to ngtrans so we probably need a joint vulcan mind grip on this one with ipng and ngtrans together ????). But, I already am testing implementation scenarios and that will take some cycles but before the IETF. I also think this will work with Mikes 8+8 proposal as an ESD and we should look for synergy there IMO. I think eventually this draft needs diagrams of real implementation scenarios so all the cases are tested. I see no reason why the bit sets in ND would not work either. I am concerned if this puts any performance penalty on the IPv4 stack but thats just because I have not gotten that far. Customers have told me IPv4 cannot perform worse because IPv6 is on the platform. Attached are my initial comments on the draft for your review and comment. Good job and good thinking. ------------------------------------- > An IPv6 address prefix used for stateless autoconfiguration of an > IPv4 interface must be 80 bits in length. Why not 96. Why isn't 32bits the token for IPv6 over IPv4? A reason would be that 80 bits is now used for ll address and it would keep implementations in synch code wise. So I am just asking not saying it should not be 80bits. > IPv4 Address > ..................... The 32 bit IPv4 address, in network byte > order. This is the address the interface currently responds > to, and may be different from the built-in address used as > the address token. I can't parse this? Do you mean the address may be different than the link-layer address used for IPv4? > A solution is to use the IPv4 global broadcast address of > 255.255.255.255 as the destination IPv4 address for all IPv6 > multicast packets. In this case, the scope of such IPv4 broadcasts > MUST be administratively limited to the IPv4 network over which > operation of IPv6 over IPv4 is desired. Non-IPv6 IPv4 hosts > receiving such broadcasts with protocol type TBD1 MUST silently > discard them. This solution SHOULD be implemented as an alternative > to use of IPv4 multicast. However, it carries an intrinsic risk of > broadcast storms and MUST NOT be the default configuration. This > solution SHOULD NOT be used in an IPv4 topology that has alternate > paths, as there is no guaranteed way to contain broadcast storms in > such a case. YUCK... YUCK... YUCK... I don't think this should be an option for the reason you state. We all do multicast and would need to make the TBD1 changes. > Another approach would be treat the IPv4 network as an NBMA network, > but this solution is not recommended on grounds of complexity. I would not even put this in the draft why confuse a good thing. Let ION work the NBMA issues for multicast which is happening now and then it will just work. ------------------------------------ /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Nov 20 10:26:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16748; Wed, 20 Nov 96 10:26:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16594; Wed, 20 Nov 96 06:46:02 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA24195; Wed, 20 Nov 1996 06:38:49 -0800 Received: from lobster.wellfleet.com (lobster.corpeast.baynetworks.com [192.32.253.3]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA29690 for ; Wed, 20 Nov 1996 06:38:48 -0800 Received: from pobox.BayNetworks.com by lobster.wellfleet.com (SMI-8.6/SMI-4.1) id JAA20595; Wed, 20 Nov 1996 09:42:37 -0500 Received: from andover.engeast by pobox.BayNetworks.com (SMI-8.6/SMI-SVR4) id JAA01316; Wed, 20 Nov 1996 09:38:35 -0500 Date: Wed, 20 Nov 1996 09:38:35 -0500 From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <199611201438.JAA01316@pobox.BayNetworks.com> To: brian@dxcoms.cern.ch Subject: (IPng 2521) Re: IPv6 over IPv4 without tunnels Cc: cmj@NSD.3Com.com, ipng@sunroof.eng.sun.com, dhaskin@BayNetworks.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > > > > In regard to section 7, a solution to use a limited IP brodcast address > > (255.255.255.255) address in the absence of IPv4 multicast support > > will not work. I'm not aware of any IP routers that will forward packets > > addressed to 255.255.255.255. This is actually prohibited in the > > Router Requirements spec. I guess in a very limited network environment > > you may try to bridge IPv6 Neighbor Solicitation packets via bridge-routers > > that don't support IPv6 and get the same intended result. > > > > It also works if you run proxy ARP, another violation of RR that > is supported by well known vendors. But as I said to Matt, > this is indeed an uncomfortable solution. > > Thanks > Brian > Yeah, as it was pointed out to me, there is a way to administratively override the default (compliant to RR) behavior in respect to 255.255.255.255 on Bay routers. Thinking of that gives me a nausea. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Nov 20 10:26:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16745; Wed, 20 Nov 96 10:26:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16490; Wed, 20 Nov 96 00:51:05 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA02542; Wed, 20 Nov 1996 00:43:53 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA08576 for ; Wed, 20 Nov 1996 00:43:52 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id JAA11126; Wed, 20 Nov 1996 09:43:50 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA10881; Wed, 20 Nov 1996 09:43:49 +0100 Message-Id: <9611200843.AA10881@dxcoms.cern.ch> Subject: (IPng 2519) Re: IPv6 over IPv4 without tunnels To: crawdad@fnal.gov (Matt Crawford) Date: Wed, 20 Nov 1996 09:43:49 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199611192135.PAA00264@gungnir.fnal.gov> from "Matt Crawford" at Nov 19, 96 03:35:05 pm 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 Matt, > > Zeroth, how should the IPv4 TTL be chosen? Should it be the default > value from ASSIGNED NUMBERS or might there be other considerations? > Good question. Any good answers? > > First, I dislike the concept of a 48 bit token which is 16 bits of > zero and an IPv4 address. If two nodes on the same wire somehow wind > up using the same prefix, one for 6over4, the other for native IPv6, > then beliefs about the on-link status (the "L" flag of the prefix > information option) of that prefix become void. In fact one parenthesis that didn't go in says something like: [Discussion: if the Mike O'Dell 8+8 proposal is adopted, the token would actually be defined as in that proposal.] Which I think would go some way to resolving the ambiguity. > > You may indeed remind me that one host should look only at Router > Advertisements which are encapsulated in IPv4 headers, and the other > should look only at "native" RA packets. But both Mr. Murphy and > possible excessive zeal in application of the robustness principle > work against this. > > How about using a 32 bit token and only allowing auto-configuration > on a 96 bit prefix? Well we discussed that and Cyndi (who is in Australia by now) persuaded me that it is cleaner to use 80 bits in all cases. But again, the 8+8 approach would resolve this. > > > Second, 255.255.255.255 is in no way a "global" broadcast address. > See RFC 1812 (v4 router requirements): > A limited IP broadcast address is defined to be all-ones: { -1, -1 } > or 255.255.255.255. > [...] > Limited broadcasts MUST NOT be forwarded. > A site that has no IPv4 multicast support probably does not have > general flooding for broadcasts or directed broadcasts of protocol > TBD1, so there may be no alternatives other than multicast or the > full-blown NBMA mechanisms. > I hate broadcasts. I think we'd be perfectly happy if the real world forced us to take this out. In any case we need to align with RFC 1812, thanks. > Third, an enumeration of the IPv4 multicast groups that must be > joined to support Neighbor Discovery would be a useful appendix. > For node with a link-layer (IPv4) address of W.X.Y.Z, i make those > out to be TBD2.X.Y.Z and TBD2.0.0.1. A router must also join > TBD2.0.0.2. > Yes, that's a good suggestion if the whole idea goes forward. > > And fourth and finally, one instance of "Ethernet" slipped through > your global replacement. :-) That was just to prove that we really did rip off your text :-) Thanx Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Nov 20 10:26:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16746; Wed, 20 Nov 96 10:26:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16499; Wed, 20 Nov 96 00:55:37 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA02851; Wed, 20 Nov 1996 00:48:25 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA09460 for ; Wed, 20 Nov 1996 00:48:25 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id JAA11400; Wed, 20 Nov 1996 09:48:23 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA15897; Wed, 20 Nov 1996 09:48:22 +0100 Message-Id: <9611200848.AA15897@dxcoms.cern.ch> Subject: (IPng 2520) Re: IPv6 over IPv4 without tunnels To: dhaskin@baynetworks.com (Dimitry Haskin) Date: Wed, 20 Nov 1996 09:48:22 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: cmj@NSD.3Com.com, ipng@sunroof.eng.sun.com In-Reply-To: <199611191937.OAA28934@pobox.BayNetworks.com> from "Dimitry Haskin" at Nov 19, 96 02:37:30 pm 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 Dimitry, > > I've had a quick look at your "Transmission of IPv6 Packets over > IPv4 Networks without Tunnels" draft. To get picky, I think > claiming that there is no tunneling involved in the proposed > scheme is stretching the point. What you're proposing is the > automatic (in the NGTRANS terminology) or open-end Ipv6-in-Ipv4 tunneling > with an IPv4 address resolution capability so that IPv4-compatible > addresses will not be required for isolated hosts. This is > a step forward. Right, but the title got you reading, didn't it? I agree that it's a bit cheeky ;-) > > In regard to section 7, a solution to use a limited IP brodcast address > (255.255.255.255) address in the absence of IPv4 multicast support > will not work. I'm not aware of any IP routers that will forward packets > addressed to 255.255.255.255. This is actually prohibited in the > Router Requirements spec. I guess in a very limited network environment > you may try to bridge IPv6 Neighbor Solicitation packets via bridge-routers > that don't support IPv6 and get the same intended result. > It also works if you run proxy ARP, another violation of RR that is supported by well known vendors. But as I said to Matt, this is indeed an uncomfortable solution. Thanks Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Nov 20 15:15:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17368; Wed, 20 Nov 96 15:15:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17362; Wed, 20 Nov 96 15:15:00 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA25253; Wed, 20 Nov 1996 15:07:45 -0800 Received: from lobster.wellfleet.com (lobster.corpeast.baynetworks.com [192.32.253.3]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA06200 for ; Wed, 20 Nov 1996 15:07:43 -0800 Received: from pobox.BayNetworks.com by lobster.wellfleet.com (SMI-8.6/SMI-4.1) id SAA02930; Wed, 20 Nov 1996 18:11:37 -0500 Received: from andover.engeast by pobox.BayNetworks.com (SMI-8.6/SMI-SVR4) id SAA29169; Wed, 20 Nov 1996 18:07:38 -0500 Date: Wed, 20 Nov 1996 18:07:38 -0500 From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <199611202307.SAA29169@pobox.BayNetworks.com> To: ip6mib@Research.Ftp.Com, ipng@sunroof.eng.sun.com Subject: (IPng 2522) FYI: SMI Network Management Experimental code for IPv6 MIB Cc: sonishi@BayNetworks.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Begin Included Message ----- >From iana@ISI.EDU Wed Nov 20 17:41 EST 1996 From: iana@ISI.EDU Date: Wed, 20 Nov 1996 14:43:56 -0800 Posted-Date: Wed, 20 Nov 1996 14:43:56 -0800 To: dhaskin@BayNetworks.com Subject: Re: SMI Network Management Experimental code for IPv6 MIB Cc: iana@ISI.EDU Content-Type: text Content-Length: 111 Dimitry, We have assigned SMI experimental code 74 to IPv6 MIB, with you as the point of contact. Joyce ----- End Included Message ----- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 22 01:58:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19032; Fri, 22 Nov 96 01:58:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19026; Fri, 22 Nov 96 01:57:53 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA26779; Fri, 22 Nov 1996 01:50:38 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA12102 for ; Fri, 22 Nov 1996 01:50:34 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id KAA06066; Fri, 22 Nov 1996 10:50:33 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA19532; Fri, 22 Nov 1996 10:50:31 +0100 Message-Id: <9611220950.AA19532@dxcoms.cern.ch> Subject: (IPng 2523) Re: IPv6 over IPv4 without tunnels To: bound@zk3.dec.com Date: Fri, 22 Nov 1996 10:50:31 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9611201621.AA22632@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Nov 20, 96 11:21:27 am 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 Jim, > > This is a really good idea. This should be on the IPng WG agenda too > for San Jose. I think it should be discussed on ipng not ngtrans as > other input, but see comment below. Up to the chairs. I will be in San Jose anyway :-) > > >The key motivation for this draft is: > > > > IPv6 hosts connected using this method do not require IPv4-compatible > > addresses or configured tunnels. In this way IPv6 gains considerable > > independence of the underlying links and can step over many hops of > > IPv4 subnets. > > I don't think it eliminates the use of configured tunnels though. If I Agree. ... > I also think this will work with Mikes 8+8 proposal as an ESD and we > should look for synergy there IMO. Agree > > I think eventually this draft needs diagrams of real implementation > scenarios so all the cases are tested. I see no reason why the bit sets > in ND would not work either. > > I am concerned if this puts any performance penalty on the IPv4 stack > but thats just because I have not gotten that far. Customers have told > me IPv4 cannot perform worse because IPv6 is on the platform. I don't see why it would; there is just one more IPv4 protocol type which would divert you into the IPv6 stack. ... > > An IPv6 address prefix used for stateless autoconfiguration of an > > IPv4 interface must be 80 bits in length. > > Why not 96. Why isn't 32bits the token for IPv6 over IPv4? > A reason would be that 80 bits is now used for ll address and it would > keep implementations in synch code wise. So I am just asking not saying > it should not be 80bits. > I think I covered this in previous responses to Matt and Dimitry. > > IPv4 Address > > ..................... The 32 bit IPv4 address, in network byte > > order. This is the address the interface currently responds > > to, and may be different from the built-in address used as > > the address token. > > I can't parse this? Do you mean the address may be different than the > link-layer address used for IPv4? If a host is using multiple IPv4 addresses on the same interface you have to pick one. But the text needs more modification from Matt's original Ethernet text. > > > > A solution is to use the IPv4 global broadcast address of > > 255.255.255.255 as the destination IPv4 address for all IPv6 > > multicast packets. In this case, the scope of such IPv4 broadcasts > > MUST be administratively limited to the IPv4 network over which > > operation of IPv6 over IPv4 is desired. Non-IPv6 IPv4 hosts > > receiving such broadcasts with protocol type TBD1 MUST silently > > discard them. This solution SHOULD be implemented as an alternative > > to use of IPv4 multicast. However, it carries an intrinsic risk of > > broadcast storms and MUST NOT be the default configuration. This > > solution SHOULD NOT be used in an IPv4 topology that has alternate > > paths, as there is no guaranteed way to contain broadcast storms in > > such a case. > > YUCK... YUCK... YUCK... > I don't think this should be an option for the reason you state. We all > do multicast and would need to make the TBD1 changes. If everybody tells us this then I expect it will disappear. > > > Another approach would be treat the IPv4 network as an NBMA network, > > but this solution is not recommended on grounds of complexity. > > I would not even put this in the draft why confuse a good thing. Let > ION work the NBMA issues for multicast which is happening now and then > it will just work. It should certainly not be documented as standard. It could maybe go into an "open issues" annex. Thanx Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 22 08:59:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19349; Fri, 22 Nov 96 08:59:03 PST Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19343; Fri, 22 Nov 96 08:58:47 PST Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA00980; Fri, 22 Nov 1996 08:51:31 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA18672; Fri, 22 Nov 1996 08:51:11 -0800 Date: Fri, 22 Nov 1996 08:51:11 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199611221651.IAA18672@bobo.eng.sun.com> To: rstevens@kohala.com Subject: (IPng 2524) Re: Advanced API Specification Part II Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm behind on mail. On Sun, 17 you wrote: > I've written versions of Ping and Traceroute for IPv6 and needed this > structure for both programs: to examine the next header field and the > hop limit, for example. Since a raw socket returns data beginning > with the entire IPv6 header, I think we need the definition. For benefit of things like tcpdump I think it would make sense to extend the scope of the advanced API draft to cover "packet sniffers". I think the only thing the draft is missing in this area is structure definitions for all the extension headers e.g. the fragmentation header. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 25 14:00:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00756; Mon, 25 Nov 96 14:00:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00750; Mon, 25 Nov 96 14:00:26 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA03212; Mon, 25 Nov 1996 13:53:05 -0800 Received: from webserver.casc.com (webserver.casc.com [152.148.41.200]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA21784 for ; Mon, 25 Nov 1996 13:52:59 -0800 Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id QAA08468; Mon, 25 Nov 1996 16:51:20 -0500 Received: from apollo13.cascade by casc.com (SMI-8.6/SMI-SVR4-bob.2) id QAA07939; Mon, 25 Nov 1996 16:53:42 -0500 Received: by apollo13.cascade (5.x/SMI-SVR4) id AA11045; Mon, 25 Nov 1996 16:53:42 -0500 Date: Mon, 25 Nov 1996 16:53:42 -0500 From: jmoy@alpo.casc.com (John Moy) Message-Id: <9611252153.AA11045@apollo13.cascade> To: ospf@gated.cornell.edu Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2526) OSPF for IPv6 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi. As those of you on the OSPF list probably noticed, I posted an updated copy of the OSPF for IPv6 document this morning. The only change is the change that we discussed last WG meeting: IPv6 link-local addresses have been disallowed in all LSA types except the Link-LSA. I'm contemplating submitting this document to the standards process, and for that I need to know whether there are any implementations of OSPF for IPv6 underway. Please send any relevant information to me at jmoy@casc.com. Thanks, John ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 25 15:07:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00896; Mon, 25 Nov 96 15:07:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00879; Mon, 25 Nov 96 15:01:44 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA16548; Mon, 25 Nov 1996 14:54:23 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA14315 for ; Mon, 25 Nov 1996 14:54:20 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.3/8.7.3) with ESMTP id PAA23765 for ; Mon, 25 Nov 1996 15:54:19 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.3/8.8.3) id PAA02057 for ipng@sunroof.Eng.Sun.COM; Mon, 25 Nov 1996 15:54:18 -0700 (MST) Message-Id: <199611252254.PAA02057@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Mon, 25 Nov 1996 15:54:18 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.eng.sun.com Subject: (IPng 2527) updated sockets API: draft-ietf-ipngwg-bsd-api-06.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk An update of the "Basic Socket Interface Extensions for IPv6" draft has just been submitted and it should appear in the I-D directories in a few days. If you want a copy before then, help yourself to: ftp://ftp.kohala.com/pub/rstevens/draft-ietf-ipngwg-bsd-api-06.txt Attached is a list of the changes from the -05 version. Rich Stevens ------------------------------------------------------------------- 8. Change History Changes from the April 1996 Edition (-05 draft) - Rewrote Abstract. - Added Table of Contents. - New Section 2.2 (Data Types). - Removed the example from Section 3.4 (Socket Address Structure for 4.4BSD-Based Systems) implying that the process must set the sin6_len field. This field need not be set by the process before passing a socket address structure to the kernel: bind(), connect(), sendto(), and sendmsg(). - The examples in Section 3.8 (Flow Information) on setting and fetching the flow label and priority have been expanded, since the byte ordering and shifting required to set and fetch these fields can be confusing. It is also explicitly stated that the two IPV6_FLOWLABEL_xxx constants and the 16 IPV6_PRIORITY_xxx constants are all network byte ordered. - Warning placed at the end of Section 3.9 concerning the byte ordering of the IPv4 INADDR_xxx constants versus the IPv6 IN6ADDR_xxx constants and in6addr_xxx externals. - Added a new Section 4 (Interface Identification). This provides functions to map between an interface name and an interface index. - In Section 5.1 (Changing Socket Type) the qualifier was added that you cannot downgrade an IPv6 socket to an IPv4 socket unless all nonwildcard addresses already associated with the IPv6 socket are IPv4-mapped IPv6 addresses. - In Section 5.3 (Sending and Receiving Multicast Packets) the method of specifying the local interface was changed from using a local IPv6 address to using the interface index. This changes the argument type for IPV6_MULTICAST_IF and the second member of the ipv6_mreq structure. - In Section 5.3 (Sending and Receiving Multicast Packets) the IPV6_ADD_MEMBERSHIP socket option description was corrected. A note was also added at the end of this section concerning joining the group versus binding the group address to the socket. - The old Sections 5.1, 5.2, and 5.3 are gone, and new Sections 6.1, 6.2, 6.3, 6.4, and 6.5 are provided. The new sections describe the BIND 4.9.4 implementation of the name-to-address functions (which support IPv6), a POSIX-free description of the getaddrinfo() function, a description of the new getnameinfo() function, and the inet_ntop() and inet_pton() functions. The old Section 5.4 (Embedded IPv4 addresses) is now Section 6.6 (IPv4- Mapped Addresses). - Renamed inet6_isipv4addr() to inet6_isipv4mapped() so the name better describes the function. - Section 8 (Open Issues) was removed. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 25 16:00:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00947; Mon, 25 Nov 96 16:00:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00941; Mon, 25 Nov 96 16:00:34 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA28819; Mon, 25 Nov 1996 15:53:14 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA03360 for ; Mon, 25 Nov 1996 15:53:10 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA21573; Mon, 25 Nov 96 15:52:14 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id PAA29277; Mon, 25 Nov 1996 15:53:09 -0800 Date: Mon, 25 Nov 1996 15:53:09 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199611252353.PAA29277@feller.mentat.com> To: rstevens@kohala.com Subject: (IPng 2528) Re: updated sockets API: draft-ietf-ipngwg-bsd-api-06.txt Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, > > - The examples in Section 3.8 (Flow Information) on setting and > fetching the flow label and priority have been expanded, since > the byte ordering and shifting required to set and fetch these > fields can be confusing. It is also explicitly stated that the > two IPV6_FLOWLABEL_xxx constants and the 16 IPV6_PRIORITY_xxx > constants are all network byte ordered. > At some IETF (LA or Montreal) I seem to remember the working group agreeing that the priority field of IPv6 packets should be MBZ since we could not get agreement on whether the priority was a hop-by-hop item or a end-to-end item. If I am remembering this correctly, why do we need the IPV6_PRIORITY_xxx definitions at all? Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Nov 27 06:47:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02400; Wed, 27 Nov 96 06:47:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02394; Wed, 27 Nov 96 06:47:40 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA00809; Wed, 27 Nov 1996 06:40:17 -0800 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA04241 for ; Wed, 27 Nov 1996 06:40:17 -0800 Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA49594; Wed, 27 Nov 1996 09:39:06 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id JAA40734 for ; Wed, 27 Nov 1996 09:39:03 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA19360; Wed, 27 Nov 1996 09:04:03 -0500 Message-Id: <9611271404.AA19360@ludwigia.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2529) draft-ietf-ipngwg-multicast-assgn-01.txt Date: Wed, 27 Nov 1996 09:04:02 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Couple of minor comments on the draft. > The current approach [RFC1972] to map IPv6 multicast addresses into > IEEE 802 MAC addresses takes the low order 32 bits of the IPv6 > multicast address and uses it to create a MAC address. This isn't quite true. The current Token Ring spec still maps IP multicast addresses into functional addresses (sigh). How about rewording the sentence to something like: The current approach taken by the Ethernet to map IPv6 multicast addresses into IEEE 802 MAC addresses takes the low order 32 bits of the IPv6 multicast address and uses it to create a MAC address [RFC1972]. > Groups ID's > less than or equal to 32 bits will generate unique MAC addresses. > Due to this new IPv6 multicast addresses should be assigned so that > the group identifier is always in the low order 32 bits as shown in > the following: This may be getting picky about wording, but there are no 32-bit group addresses. There may be addresses with lots of zeros in the middle bits, but I don't think they should be called 32-bit addresses. How about rewording as: Because only the low-order 32-bits are used in mapping an IPv6 multicast address to a link-layer multicast address, new IPv6 multicast addresses should be assigned so that the low-order 32-bits of the group identifier differ from those of other defined groups as shown in the following: Other than that, the draft looks fine. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Nov 27 09:06:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02508; Wed, 27 Nov 96 09:06:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02502; Wed, 27 Nov 96 09:06:21 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA19346; Wed, 27 Nov 1996 08:58:57 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA19101 for ; Wed, 27 Nov 1996 08:58:57 -0800 Received: from redwood.ipsilon.com (redwood.Ipsilon.COM [205.226.8.238]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id IAA16596; Wed, 27 Nov 1996 08:58:49 -0800 Message-Id: <3.0.32.19961127085650.006ecdd8@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 27 Nov 1996 08:56:59 -0800 To: Thomas Narten From: Bob Hinden Subject: (IPng 2530) Re: draft-ietf-ipngwg-multicast-assgn-01.txt Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, Thanks for the comments. Your changes look fine. Given the ID deadline for this IETF meeting was yesterday, I will do an new version after the meeting. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Nov 27 09:35:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02535; Wed, 27 Nov 96 09:35:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02462; Wed, 27 Nov 96 08:32:45 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA13825; Wed, 27 Nov 1996 08:25:22 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA06416 for ; Wed, 27 Nov 1996 08:25:19 -0800 Received: from ietf.org by ietf.org id aa24063; 27 Nov 96 10:16 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: (IPng 2531) I-D ACTION:draft-ietf-ipngwg-bsd-api-06.txt Date: Wed, 27 Nov 1996 10:16:51 -0500 Message-Id: <9611271016.aa24063@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens Filename : draft-ietf-ipngwg-bsd-api-06.txt Pages : 34 Date : 11/26/1996 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 [5]. 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-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-bsd-api-06.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-06.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126102714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-bsd-api-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126102714.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Nov 27 12:26:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02724; Wed, 27 Nov 96 12:26:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02718; Wed, 27 Nov 96 12:26:23 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA03906; Wed, 27 Nov 1996 12:18:58 -0800 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA04434 for ; Wed, 27 Nov 1996 12:18:53 -0800 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA14768; Wed, 27 Nov 1996 15:17:46 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id PAA39112 for ; Wed, 27 Nov 1996 15:17:51 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA11638; Wed, 27 Nov 1996 15:19:43 -0500 Message-Id: <9611272019.AA11638@ludwigia.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2532) multicast routing in ipv6 Date: Wed, 27 Nov 1996 15:19:42 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Heads up on a possible agenda item. I think we may want to talk a bit about what IPv6 should be doing with multicast routing. The current DHCP spec (and service location too, I think) assumes multicasting works for scopes beyond just link-local addresses. What multicast routing protocol should IPv6 be using? PIM? DVMRP? OSPF? Are there specs that cover this space? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Nov 27 15:51:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02848; Wed, 27 Nov 96 15:51:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02842; Wed, 27 Nov 96 15:50:53 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA10858; Wed, 27 Nov 1996 15:43:30 -0800 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA28824 for ; Wed, 27 Nov 1996 15:43:30 -0800 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.6/8.7.1) with ESMTP id AAA17229; Thu, 28 Nov 1996 00:43:23 +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 AAA07690; Thu, 28 Nov 1996 00:43:23 +0100 (MET) Message-Id: <199611272343.AAA07690@givry.inria.fr> From: Francis Dupont To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2533) Re: multicast routing in ipv6 In-Reply-To: Your message of Wed, 27 Nov 1996 15:19:42 -0400. <9611272019.AA11638@ludwigia.raleigh.ibm.com> Date: Thu, 28 Nov 1996 00:43:22 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Heads up on a possible agenda item. I think we may want to talk a bit about what IPv6 should be doing with multicast routing. The current DHCP spec (and service location too, I think) assumes multicasting works for scopes beyond just link-local addresses. What multicast routing protocol should IPv6 be using? PIM? DVMRP? OSPF? Are there specs that cover this space? => I propose PIM! I believe it is very simple to extend PIM for IPv6 (there are some implementations of PIM around, is there a potential problem ?). Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Nov 27 16:33:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02904; Wed, 27 Nov 96 16:33:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02898; Wed, 27 Nov 96 16:32:46 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA17003; Wed, 27 Nov 1996 16:25:24 -0800 Received: from jennie.bellcore.com (jennie.bellcore.com [192.4.15.79]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA14532 for ; Wed, 27 Nov 1996 16:25:22 -0800 Received: from bellcore.com (localhost [127.0.0.1]) by jennie.bellcore.com (8.6.9/8.6.10) with ESMTP id TAA16203; Wed, 27 Nov 1996 19:24:44 -0500 Message-Id: <199611280024.TAA16203@jennie.bellcore.com> To: Francis Dupont Cc: ipng@sunroof.eng.sun.com, gja@bellcore.com Subject: (IPng 2534) Re: multicast routing in ipv6 In-Reply-To: Your message of Thu, 28 Nov 1996 00:43:22 +0100. <199611272343.AAA07690@givry.inria.fr> Date: Wed, 27 Nov 1996 19:24:40 -0500 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>=> I propose PIM! I believe it is very simple to extend PIM for IPv6 >>(there are some implementations of PIM around, is there a potential >>problem ?). I propose we use whatever IDMR comes up with. It is unlikely an IPv6-unfriendly solution will be accepted, and it would be messy for ipng to pre-empt their final multicast architecture. cheers, gja _________________________________________________________________________ Grenville Armitage http://gump.bellcore.com:8000/~gja/home.html Have you hugged your home page today? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Nov 27 18:15:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03021; Wed, 27 Nov 96 18:15:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03015; Wed, 27 Nov 96 18:14:48 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA00553; Wed, 27 Nov 1996 18:07:26 -0800 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA08134 for ; Wed, 27 Nov 1996 18:07:26 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <17139(2)>; Wed, 27 Nov 1996 18:07:24 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75271>; Wed, 27 Nov 1996 18:07:05 PST To: Thomas Narten Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 2535) Re: multicast routing in ipv6 In-Reply-To: narten's message of Wed, 27 Nov 96 11:19:42 -0800. <9611272019.AA11638@ludwigia.raleigh.ibm.com> Date: Wed, 27 Nov 1996 18:07:05 PST From: Steve Deering Message-Id: <96Nov27.180705pst."75271"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Thomas Narten > > Heads up on a possible agenda item. I think we may want to talk a bit > about what IPv6 should be doing with multicast routing. The current > DHCP spec (and service location too, I think) assumes multicasting > works for scopes beyond just link-local addresses. What multicast > routing protocol should IPv6 be using? PIM? DVMRP? OSPF? Are there > specs that cover this space? Thomas, I believe the OSPFv6 spec includes the MOSPF extensions, and the PIM-DM and PIM-SM specs are written for both v4 and v6. Also, this summer, I had a couple of interns working with me on an improved version of PIM-DM for IPv6, and we are planning to write it up in the new year, after we have some implementation experience (some folks at Sun and UCLA are picking up the implementation work for that). I suggest that we *not* use DVMRP for IPv6. The salient feature of DVMRP is that it maintains a separate routing table for multicast. That was a crucial feature for getting IP multicast off the ground in the IPv4 Internet, where tunnels were necessary to get across routers that did not understand multicast -- the use of tunnels makes the multicast topology different than the unicast topology, and thus makes separate routing tables necessary. However, with IPv6, I very much hope that all routers will support IPv6 multicast, we won't use multicast-only tunnels, and the multicast and unicast topologies will be the same. If that's the case, we can run multicast routing protocols that share the unicast routing tables, such as MOSPF and PIM. Furthermore, if we only deploy those kinds of multicast routing protocols, it'll make it harder to run multicast only only a fraction of the routers. :-) Bringing up the IPv6 multicast question, however, forces me to sheepishly admit (as usual) that I dropped the ball on producing a general IPv6 multicast issues document (issues that are independent of any particular mcast routing protocol), which I had signed up for at the Montreal meeting. I even had Tom Pusteri volunteer to help me, and he reminded me several times of my commitment, but I still failed to make any progress on that front. [Story of my life...] How much agenda time do you think we need for this topic, or will this email converstation suffice? [...he says, just before departing on a trip which will keep him mostly out of email range for the next week...] Steve [By the way, in case anyone's surprise to see me still posting from my PARC address, rather than a Cisco address, no, I didn't change my mind about my job change. :-) I can now be reached as deering@cisco.com. I just haven't gotten around yet to re-targetting my zillions of mailing list subscriptions, so I'm still doing most of my email reading, and a little bit of replying, from my PARC account. I also haven't yet obtained the magic access card needed to reach my Cisco account when I am on the road, so odds are higher of reaching me via my PARC account for the next couple of weeks.] ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 29 13:56:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03962; Fri, 29 Nov 96 13:56:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03952; Fri, 29 Nov 96 13:56:20 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA15103; Fri, 29 Nov 1996 13:48:55 -0800 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA15854 for ; Fri, 29 Nov 1996 13:48:51 -0800 Received: from uvite54.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA20132; Fri, 29 Nov 1996 16:48:46 -0500 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Nov 1996 16:48:46 -0500 To: ipng@sunroof.eng.sun.com From: droms@bucknell.edu (Ralph Droms) Subject: (IPng 2536) DHCP fo IPv6 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound and Charlie Perkins, authors of the DHCP for IPv6 specs, have informed me that they expect to submit the current specs for "Proposed Standard" status soon. To ensure the broadest possible review of the protocol specifications, I encourage you to read the DHCP for IPv6 documents: draft-ietf-dhc-dhcpv6-08.txt draft-ietf-dhc-v6exts-04.txt and reply with comments to the dhcp-v6@bucknell.edu mailing list. Thanks... - Ralph Droms ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com