From owner-ipng Sun Dec 1 06:06:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04485; Sun, 1 Dec 96 06:06:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04479; Sun, 1 Dec 96 06:06:37 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA00472; Sun, 1 Dec 1996 05:59:08 -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 FAA03235 for ; Sun, 1 Dec 1996 05:59:09 -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 OAA05068; Sun, 1 Dec 1996 14:55:30 +0100 (MET) Received: from scarpa (localhost [127.0.0.1]) by scarpa (SMI-8.6/8.6.12) with ESMTP id OAA10920; Sun, 1 Dec 1996 14:57:58 +0100 Message-Id: <199612011357.OAA10920@scarpa> X-Mailer: exmh version 1.6.7 5/3/96 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: ipng@sunroof.eng.sun.com, rem-conf@es.net Cc: steve@sics.se, bcn@cdt.luth.se Subject: (IPng 2537) IPv6 header compression Date: Sun, 01 Dec 1996 14:57:58 +0100 From: Mikael Degermark Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new version of the IPv6 header compression draft is available in the internet-draft directories. draft-degermark-ipv6-hc-02.txt The draft specifies how both IPv6 and IPv4 headers should be compressed and has hooks for allowing compression of for example RTP headers on top of UDP. There is demand for a stable header compression scheme and we would like the draft to go to Last Call soon after San Jose. Please read and comment! Micke ------- Changes from version 01 to version 02: General: - Added hooks for additional header compression mechanisms on top of UDP, for example for compressed RTP (section 12). - Maximum CID is now 16 bits instead of 24 bits. This change is needed to make room for an additional data byte passed by the hooks above. 16 bits of CID should be sufficient for bandwidths up to several megabit/s. - Clarified that the kind of errors a header compression scheme needs to worry about is loss of entire packets, not bit errors. (TCP and UDP checksums are not strong enough to protect against that kind of error anyway.) This header compression scheme should not be used over links that lacks strong error detection like a 16-bit CRC. No SLIP links. - Clarified what packet types we need (3.1). - Format of compressed headers changed to keep the initial part constant (allows some modems to do additional compression...). (section 6). - The ranges of the configuration parameters have been specified. TCP: - Today many TCPs use the Timestamp option by default. The TCP Option field then changes between each segment, so the compressor then needs to send full headers all the time. To allow compression anyway, we have added a D-flag to the flag byte so the compressor can signal that the TCP Options have changed and are sent as-is. When they don't change, the D-flag is 0 and no Options are sent. - A way to compress TCP headers without using delta-encoding is specified (COMPRESSED_TCP_NODELTA). UDP: - UDP checksum not passed when it is zero. This cannot happen for IPv6 but it can for IPv4. Saves 2 bytes in compressed headers when checksum is zero. ------------------------------------------------------------------------------ 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 Dec 2 03:49:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04667; Mon, 2 Dec 96 03:49:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04658; Mon, 2 Dec 96 03:48:31 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA21932; Mon, 2 Dec 1996 03:41:01 -0800 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id DAA11808 for ; Mon, 2 Dec 1996 03:41:02 -0800 Received: by mail.noris.net id <34989-13554>; Mon, 2 Dec 1996 12:40:48 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 2539) Re: BSD API - ipv6_mreq Date: 2 Dec 1996 11:08:22 +0100 Organization: noris network GmbH, Nuernberg, FRG Lines: 44 Message-Id: <57u9qm$van$1@work.smurf.noris.de> References: <199611120225.SAA00683@feller.mentat.com> <9611121705.AA04155@wasted.zk3.dec.com> <847819594.22490@noris.de> Nntp-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: noris.net dist.ipng:841 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jim writes: > Tim, > > >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. > Let's assume that the end result is 'send packets on one interface. Specify which'. Let's further assume that the system has more than one Ethernet and a bunch of point-to-point links which share (non-link-local) IP addresses with one of the Ethernet links. In this context, specification of the interface by its address (or public name) makes sense. Therefore, an implementation which enables multicast on all interfaces with the specified address doesn't make sense. Contrariwise, in a context where you want to enable multicasts on "all interfaces", since there also may be interface without an address of their own, a program needs to cycle through all the device names or interface IDs anyway. Having the kernel enable multicasts on all interfaces with a specified IP address therefore doesn't simplify the application. Therefore, I propose that specification by IP address, if any, uses the first broadcast interface found, or the first non-broadcast interface found, or returns an error. -- Il est mort, Jean Luc... -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ 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 Dec 2 03:49:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04666; Mon, 2 Dec 96 03:49:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04654; Mon, 2 Dec 96 03:48:29 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA21929; Mon, 2 Dec 1996 03:41:00 -0800 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id DAA11805 for ; Mon, 2 Dec 1996 03:41:00 -0800 Received: by mail.noris.net id <34990-13554>; Mon, 2 Dec 1996 12:40:48 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 2538) Re: Advanced API Specification Part II Date: 2 Dec 1996 12:20:56 +0100 Organization: noris network GmbH, Nuernberg, FRG Lines: 32 Message-Id: <57ue2o$vhu$1@work.smurf.noris.de> References: <199611170507.VAA05347@feller.mentat.com> <848212686.20991@noris.de> Nntp-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: noris.net dist.ipng:840 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thartric@mentat.com (Tim Hartrick) writes: > 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. > IMHO, that _is_ a technicl issue in that the behavior of that option must be documented fully, eg. which words are in network byte order and which are not (IMHO: the set of the latter should be empty). > 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. > IMHO, there should be a "raw IPv6" way of using a socket. There should also be a well-defined way to turn this option on, i.e. anything I read or write to the socket is defined as a usable, this-is-how-it-looks-like-on-the-wire, copy of the packet. Whether we specify the way to turn this mode on as "setsockopt(IPV6_HDRINCL)" or "setsockopt(IP_OPTIONS and IP_TOS and IP_TTL)" is a secondary issue, though IMHO the former way is preferable. Disclaimer: I didn't read the draft yet. Shame on me, I know... -- Yankees do it frugally. -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ 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 Dec 2 10:15:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05029; Mon, 2 Dec 96 10:15:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05013; Mon, 2 Dec 96 10:08:28 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA10713; Mon, 2 Dec 1996 10:00:58 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA28455 for ; Mon, 2 Dec 1996 10:00:55 -0800 Received: from ietf.ietf.org by ietf.org id aa05905; 2 Dec 96 11:27 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: (IPng 2540) I-D ACTION:draft-ietf-ipngwg-ipv6-tunnel-05.txt Date: Mon, 02 Dec 1996 11:27:50 -0500 Message-Id: <9612021127.aa05905@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-05.txt Pages : 36 Date : 11/27/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-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-05.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-05.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: <19961202104220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-tunnel-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961202104220.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 Dec 2 12:22:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05564; Mon, 2 Dec 96 12:22:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05548; Mon, 2 Dec 96 12:22:16 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA18707; Mon, 2 Dec 1996 12:14:47 -0800 Received: from CHIMAY.MACH.CS.CMU.EDU (CHIMAY.MACH.CS.CMU.EDU [128.2.222.167]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA29118 for ; Mon, 2 Dec 1996 12:14:43 -0800 Received: from CHIMAY.MACH.CS.CMU.EDU by CHIMAY.MACH.CS.CMU.EDU id aa05629; 2 Dec 96 15:14:01 EST To: mobile-ip@SMALLWORKS.com, ipng@sunroof.eng.sun.com From: Dave Johnson Subject: (IPng 2541) Two new Internet-Drafts Date: Mon, 02 Dec 96 15:13:51 EST Message-Id: <5627.849557631@CHIMAY.MACH.CS.CMU.EDU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new version of the Mobile IPv6 draft and a new version of the Mobile IP Route Optimization (for IPv4) draft are available in the usual IETF FTP sites: Title : Mobility Support in IPv6 Authors : David B. Johnson, Charles Perkins Filename : draft-ietf-mobileip-ipv6-02.txt and Title : Route Optimization in Mobile IP Authors : David B. Johnson, Charles Perkins Filename : draft-ietf-mobileip-optim-05.txt I submitted these before the Internet-Draft submission cutoff deadline last week, and they got installed correctly in the internet-drafts directories, but for some reason, the "official" announcements of them haven't been made yet on the mailing lists. By the way, the same thing happened to me with the Mobile IPv6 draft before the last IETF meeting (no official announcement ever came out for that one, although it got installed in the directory right away with no problem). Has anyone else seen this problem with missing announcements for other drafts? Dave ------------------------------------------------------------------------------ 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 Dec 2 13:22:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06312; Mon, 2 Dec 96 13:22:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06306; Mon, 2 Dec 96 13:22:43 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA01731; Mon, 2 Dec 1996 13:15:14 -0800 Received: from arbi.Informatik.Uni-Oldenburg.DE (arbi.Informatik.Uni-Oldenburg.DE [134.106.1.7]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA22337 for ; Mon, 2 Dec 1996 13:14:01 -0800 Received: by arbi.Informatik.Uni-Oldenburg.DE (Smail3.1.29.1) id ; Mon, 2 Dec 96 22:13 CET Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail3.1.29.1) id ; Mon, 2 Dec 96 22:13 MET Received: by rutil.Informatik.Uni-Oldenburg.DE (Smail3.1.29.1) id ; Mon, 2 Dec 96 22:13 MET Message-Id: X-Aliased: From schmidt@rutil.Informatik.Uni-Oldenburg.DE (Torge Schmidt) From: "Torge Schmidt" Subject: (IPng 2542) Questions To: ipng@sunroof.eng.sun.com Date: Mon, 2 Dec 1996 22:13:55 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greetings, I'm new here, read through this years' mail archives, but didn't find answers to the following questions. The text of RFC 1883 and companions do not cohere as strictly as other standards to the established MUST/SHOULD/MAY terminology. Why is that? That leaves open a lot of laxness in interpretation. For example, on page seven it reads "A full implementation of IPv6 includes implementation of the following extension headers: ..." Does that mean, e.g., a router MAY ignore the routing header, and just perform it's normal routing strategy, and still does a "full implementation of IPv6"? Another open interpretation question for me is, on the same page, "If, as a result of processing a header, a node is required to proceed to the next header but the Next Header value in the current header is unrecognized by the node, it should discard the packet and send an ICMP Parameter Problem message to the source of the packet, ..." What does "unrecognized" mean here? Is a routing header, which the node is able to skip over, but the contents of which will be ignored, an "unrecognized" header? There seems to be another inconsistency. On page six and seven it is stated, that ONLY the hop-by-hop options header is to be examined at every node on the delivery path of a packet. What about the routing header? I miss any means of flow control in the IPv6 specs. Any statement would be helpful. The rationale behind the new checksum scheme is not clear to me. IMHO, it was a good design descision to drop a mandatory header checksum field from the IP header. OTOH, there is still a presumably weak checksum in the ICMP header, justified in RFC 1883 as needed for correct delivery. I disagree here, somewhat. I think, today's link layer technology error detection and correction is better than the proposed ICMP and upper layer (UDP) checksum algorithm, which doesn't give much assurance about packet correctness either. For those links, which are supposed or known to be error prone, there could/should be an optional IP checksum header, covering an IP packet with and/or without (different header options for the same header) it's upper layer contents, as an hop-by-hop or end-to-end option, and thus eliminating the need for a weak and ever (if needed or not) time consuming mandatory UDP checksum. The optional IP authentication header does this check in some way, but is not satisfying in at least these two respects: a) it usually uses a very computation intense algorithm compared to a faster and for delivery purposes sufficient CRC check; b) it does not have the option to check ONLY the IP header. Thanks, Torge ------------------------------------------------------------------------------ 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 Dec 3 09:04:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08312; Tue, 3 Dec 96 09:04:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08188; Tue, 3 Dec 96 01:20:20 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA11406; Tue, 3 Dec 1996 01:12:50 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA10610 for ; Tue, 3 Dec 1996 01:12:51 -0800 Received: from ietf.ietf.org by ietf.org id aa27423; 2 Dec 96 15:25 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: (IPng 2543) I-D ACTION:draft-ietf-ipngwg-bsd-api-06.txt Date: Mon, 02 Dec 1996 15:25:56 -0500 Message-Id: <9612021525.aa27423@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 Tue Dec 3 09:06:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08319; Tue, 3 Dec 96 09:06:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08259; Tue, 3 Dec 96 06:46:06 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA01200; Tue, 3 Dec 1996 06:38:36 -0800 Received: from fsnt.future.futsoft.com ([38.242.192.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA14479 for ; Tue, 3 Dec 1996 06:38:30 -0800 Received: from kailash.future.futsoft.com (38.242.192.4) by fsnt.future.futsoft.com (Integralis SMTPRS 1.4) with SMTP id ; Tue, 03 Dec 1996 20:11:39 +0530 Received: from kandy.future.futsoft.com (kandy.future.futsoft.com [10.0.4.1]) by kailash.future.futsoft.com (8.7.1/8.7.1) with ESMTP id UAA09093 for ; Tue, 3 Dec 1996 20:12:00 +0530 Received: (from kaushikb@localhost) by kandy.future.futsoft.com (8.6.11/8.6.9) id UAA00679; Tue, 3 Dec 1996 20:02:06 -0500 Date: Tue, 3 Dec 1996 20:02:06 -0500 (EST) From: kaushik X-Sender: kaushikb@kandy.future.futsoft.com To: ipng@sunroof.eng.sun.com Subject: (IPng 2544) Some clarification on tentative IPv6 address Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, The RFC 1971 for Stateless Address Autoconfiguration says that an interface discards received packets addressed to a tentative address, but accepts Neighbor Discovery packets related to Duplicate Address Detection for the tentative address. Also other documents like RFC 1883 and RFC 1884 do not mention what all to be processed when the address is tentative. So can we process the routing extention header even when the address is tentative and do the forwarding ? While going through the codes for Linux-IPv6 implementation and NRL-IPv6 implementation it seems that tentative address are not handled as mentioned in RFC 1971. Please give your inputs regarding the same. Thanks in advance. regards, Kaushik. ------------------------------------------------------------------------------ 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 Dec 3 10:09:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08449; Tue, 3 Dec 96 10:09:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08443; Tue, 3 Dec 96 10:09:29 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA05117; Tue, 3 Dec 1996 10:01:40 -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 KAA26225 for ; Tue, 3 Dec 1996 10:01:36 -0800 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA56900; Tue, 3 Dec 1996 12:59:43 -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 MAA46184; Tue, 3 Dec 1996 12:59:53 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA12212; Tue, 3 Dec 1996 13:01:58 -0500 Message-Id: <9612031801.AA12212@ludwigia.raleigh.ibm.com> To: kaushik Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2545) Re: Some clarification on tentative IPv6 address In-Reply-To: Your message of "Tue, 03 Dec 1996 20:02:06 EST." Date: Tue, 03 Dec 1996 13:01:57 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kaushik writes: >The RFC 1971 for Stateless Address Autoconfiguration says that an interface >discards received packets addressed to a tentative address, but accepts >Neighbor Discovery packets related to Duplicate Address Detection for the >tentative address. >Also other documents like RFC 1883 and RFC 1884 do not mention what all >to be processed when the address is tentative. So can we process the routing >extention header even when the address is tentative and do the >forwarding ? The answer should be no. If an address is "tentative", that means it has not passed Duplicate Address Detection (DAD) yet. Such an address has not yet been assigned to the interface in a true sense, and indeed, there is a chance that it never will be. The address is associated with the interface *only* for the purposes of performing DAD, which is why the exception for ND is explicitely mentioned. Besides, DAD shouldn't take long, any truly critical packets will be retransmitted, and by then, the address should be properly assigned to the interface. 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 Tue Dec 3 15:01:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08866; Tue, 3 Dec 96 15:01:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08860; Tue, 3 Dec 96 15:01:01 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA15686; Tue, 3 Dec 1996 14:53:28 -0800 Received: from bbmail1.unisys.com (192-63-2005.unisys.com [192.63.200.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA21744 for ; Tue, 3 Dec 1996 14:53:29 -0800 Received: from trsvr.tr.unisys.com (trsvr.tr.unisys.com [192.63.216.7]) by bbmail1.unisys.com (8.7.3/8.6.12) with ESMTP id WAA04637 for ; Tue, 3 Dec 1996 22:53:27 GMT Received: from tr-exchange-2.tr.unisys.com by trsvr.tr.unisys.com (8.6.12/8.6.12) id WAA10011 ; Tue, 3 Dec 1996 22:45:22 GMT Received: by tr-exchange-2.tr.unisys.com with Microsoft Exchange (IMC 4.0.838.14) id <01BBE143.2A405C20@tr-exchange-2.tr.unisys.com>; Tue, 3 Dec 1996 17:55:27 -0500 Message-Id: From: "Dean, David A" To: "'IPng - IETF Working Group'" Subject: (IPng 2546) Question on Transition Mechanisms for IPv6... Date: Tue, 3 Dec 1996 17:55:19 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14 Encoding: 23 TEXT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We have been evaluating our requirements for deploying and supporting IPv6 in the next year or two and have the following question: After reading RFC 1933, "Transition mechanisms for IPv6 Hosts and Routers", it appears that a possible topological configuration has not been addressed (or mentioned). Consider that some years from now, say four or more, the current IPv4 addressing space has been exhausted and new network nodes are now being allocated pure 128-bit IPv6 addresses. Also consider that a rather extensive IPv4 network remains in place due to the cost of converting everything etc. How will these IPv4 nodes be able to communicate with the new pure IPv6 addressed node? I may be stating the obvious here, but it seems to me that these two nodes will never be able to communicate since the IPv4 node cannot specify an IPv6 address as its destination. Is this true? Have any strategies been discussed concerning this type of issue? David A. Dean Unisys Corp. Tredyffrin, Pa TCP/IP Product Group EMail: david.dean@unisys.com >> Opinions expressed above are mine and do not represent those of Unisys << ------------------------------------------------------------------------------ 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 Dec 3 15:21:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08892; Tue, 3 Dec 96 15:21:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08886; Tue, 3 Dec 96 15:21:21 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA20527; Tue, 3 Dec 1996 15:13:48 -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 PAA28790 for ; Tue, 3 Dec 1996 15:13:47 -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 PAA02106; Tue, 3 Dec 1996 15:13:46 -0800 Message-Id: <3.0.32.19961203151115.006fe16c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 03 Dec 1996 15:11:17 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 2547) Draft IPng Working Group Agenda Cc: hinden@Ipsilon.COM, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached is the draft agenda for the IPng working group sessions at next weeks IETF. Please let us know if we left anything out, need more or less time, etc. Apologies in advance if you asked for a slot and it was not included or your name was misspelled. Bob Hinden / Steve Deering ---------------------------------------------------------------------- IPng Working Group Draft Agenda for San Jose IETF Meeting --------------------------------------- Monday 1:00-3:00pm ------------------- Introduction / Steve Deering (5 min) Document Status / Bob Hinden (10 min) ITU Addressing Request Status / Bob Hinden (1 min) Priority Field / Steve Deering (10 min) Default Hop Limit / Steve Deering (10 min) IPv6 over Token Ring (10 min) BSD API / Rich Stevens (10 min) Advanced API spec / Matt Thomas (15 min) Tunneling Spec / Alex Conta (10 min) Router Alert Option / Ran Atkinson (10 min) Host Anycast / Jim Bound (15 min) Header Compression spec / Micke Degermark (10 min) Monday 7:30-10:00pm ------------------- 8+8 Addressing Proposal / Mike O'Dell (45 min) Multihoming / Source Address Selection / Steve Deering (30 min) Interface ID Proposal / Steve Deering (20 min) IPv6 MIB / Dimitry Haskin (15 min) Open for Additional Discussion from Monday Thursday 1:00-3:00pm -------------------- Moving Base IPv6 Specs to Draft Standard / Steve Deering (30 min) IPv6 Packets over IPv4 Networks without Tunnels / Brian Carpenter (15 min) Multicast Routing / Thomas Narten (10 min) Inter-Domain Routing (IDRP, BGP5, ?) / Bob Hinden (10 min) Open for Additional Discussion from Previous Sessions ------------------------------------------------------------------------ ------------------------------------------------------------------------------ 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 Dec 4 08:42:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09537; Wed, 4 Dec 96 08:42:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09531; Wed, 4 Dec 96 08:41:50 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA01134; Wed, 4 Dec 1996 08:34:18 -0800 Received: from lobster (lobster.corpeast.baynetworks.com [192.32.253.3]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA10218 for ; Wed, 4 Dec 1996 08:33:59 -0800 Received: from pobox.BayNetworks.com (pobox [192.32.151.199]) by lobster (SMI-8.6/SMI-SVR4) with SMTP id LAA19291; Wed, 4 Dec 1996 11:36:49 -0500 for Received: from andover.engeast by pobox.BayNetworks.com (SMI-8.6/SMI-SVR4) id LAA24091; Wed, 4 Dec 1996 11:32:40 -0500 Date: Wed, 4 Dec 1996 11:32:40 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199612041632.LAA24091@pobox.BayNetworks.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2548) link MTU Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, The inter-operability test at UNH has shown that there is a disagreement whether the link-layer header is included in the link MTU value for a given link. The discrepancy has been detected in the value of the MTU option of Router Advertisements sent by different routers. I guess the terminology definitions of ND and Path MTU Discovery specs suggest that the link MTU value includes only the maximum size of the data portion of link frame, i.e. IPv6 packet itself: packet - an IPv6 header plus payload. link MTU - the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed in one piece over a link. An authoritative conformation one way or another would help to resolve this tiny disagreement. Thanks, 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 Dec 4 10:15:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09634; Wed, 4 Dec 96 10:15:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09149; Tue, 3 Dec 96 23:33:39 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA12360; Tue, 3 Dec 1996 23:26:08 -0800 Received: from marino.backyard.wide.toshiba.co.jp (ceres.wide.toshiba.co.jp [202.249.10.113]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id XAA12374 for ; Tue, 3 Dec 1996 23:26:07 -0800 Received: (from mailer@localhost) by marino.backyard.wide.toshiba.co.jp (8.7.5/8.7.3) id QAA29882 for ; Wed, 4 Dec 1996 16:33:15 +0900 (JST) Received: from samber.backyard.wide.toshiba.co.jp(133.196.2.11) by marino.backyard.wide.toshiba.co.jp via smap (V1.3) id sma029880; Wed Dec 4 16:33:13 1996 Received: from brian.backyard.wide.toshiba.co.jp (root@brian.backyard.wide.toshiba.co.jp [133.196.2.32]) by samber.backyard.wide.toshiba.co.jp (8.7.5/8.7.3) with ESMTP id QAA19661 for ; Wed, 4 Dec 1996 16:26:28 +0900 (JST) Message-Id: <199612040726.QAA19661@samber.backyard.wide.toshiba.co.jp> To: ipng@sunroof.eng.sun.com Subject: (IPng 2549) [Q] ICMPv6 Echo message with Routing header X-Mailer: Mew version 1.06 on Emacs 19.34.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Wed, 04 Dec 1996 16:25:32 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I have a question about an IPv6 packet which contains ICMPv6 Echo Request message and at least one Routing header. RFC 1122 says that: If a Source Route option is received in an ICMP Echo Request, the return route MUST be reversed and used as a Source Route option for the Echo Reply message. On the analogy of the above rule, we MUST reserve (one of) the Routing header(s) and use it as a Routing header for the ICMPv6 Echo Reply message. But as far as I read RFC 1883(IPv6 spec.) and RFC 1885(ICMPv6), I couldn't decide whether we must or not. Do I miss something in the RFCs? Or can I find the answer in another document? If anyone knows, please let me know. Thanks in advance, JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@backyard.wide.toshiba.co.jp #I'm afraid no one replies to this mail since many IPv6 #specialists are not at their office for the next IETF meeting. #I hope this mail won't be buried in your mail folder.... ------------------------------------------------------------------------------ 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 Dec 4 10:45:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09659; Wed, 4 Dec 96 10:45:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09653; Wed, 4 Dec 96 10:45:07 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA27988; Wed, 4 Dec 1996 10:37:34 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA03921 for ; Wed, 4 Dec 1996 10:37:20 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA12730; Wed, 4 Dec 96 10:35:50 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id KAA18719; Wed, 4 Dec 1996 10:36:52 -0800 Date: Wed, 4 Dec 1996 10:36:52 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199612041836.KAA18719@feller.mentat.com> To: jinmei@backyard.wide.toshiba.co.jp Subject: (IPng 2550) Re: [Q] ICMPv6 Echo message with Routing header Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > I have a question about an IPv6 packet which contains ICMPv6 Echo > Request message and at least one Routing header. > > RFC 1122 says that: > If a Source Route option is received in an ICMP Echo > Request, the return route MUST be reversed and used as a > Source Route option for the Echo Reply message. > > On the analogy of the above rule, we MUST reserve (one of) the Routing > header(s) and use it as a Routing header for the ICMPv6 Echo Reply > message. > > But as far as I read RFC 1883(IPv6 spec.) and RFC 1885(ICMPv6), I > couldn't decide whether we must or not. > > Do I miss something in the RFCs? Or can I find the answer in another > document? If anyone knows, please let me know. > This has been discussed in the past, although probably not on this list. In general source routes should not be reversed unless the packet has been authenticated. This applies even to the sending of ICMPv6 error messages I think. I don't believe that there is any other document which speaks to this issue. Because of the security ramifications our implementation will not reverse source routes on any IPv6 packets without explicit authentication and/or explicit intervention of the application receiving the packets. 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 Dec 4 11:04:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09691; Wed, 4 Dec 96 11:04:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09685; Wed, 4 Dec 96 11:03:47 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA02654; Wed, 4 Dec 1996 10:56:12 -0800 Received: from lobster (lobster.corpeast.baynetworks.com [192.32.253.3]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA15177 for ; Wed, 4 Dec 1996 10:56:12 -0800 Received: from pobox.BayNetworks.com (pobox [192.32.151.199]) by lobster (SMI-8.6/SMI-SVR4) with SMTP id NAA22826; Wed, 4 Dec 1996 13:58:50 -0500 for Received: from andover.engeast by pobox.BayNetworks.com (SMI-8.6/SMI-SVR4) id NAA01548; Wed, 4 Dec 1996 13:54:42 -0500 Date: Wed, 4 Dec 1996 13:54:42 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199612041854.NAA01548@pobox.BayNetworks.com> To: ipng@sunroof.eng.sun.com, jinmei@backyard.wide.toshiba.co.jp Subject: (IPng 2551) Re: [Q] ICMPv6 Echo message with Routing header Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Hello, > > I have a question about an IPv6 packet which contains ICMPv6 Echo > Request message and at least one Routing header. > > RFC 1122 says that: > If a Source Route option is received in an ICMP Echo > Request, the return route MUST be reversed and used as a > Source Route option for the Echo Reply message. > > On the analogy of the above rule, we MUST reserve (one of) the Routing > header(s) and use it as a Routing header for the ICMPv6 Echo Reply > message. > > But as far as I read RFC 1883(IPv6 spec.) and RFC 1885(ICMPv6), I > couldn't decide whether we must or not. > > Do I miss something in the RFCs? Or can I find the answer in another > document? If anyone knows, please let me know. > As far as I remember, it is not required in IPv6 to reverse the route when replying to a source routed packet. It is subject to the local policy of the replying node. 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 Dec 4 12:43:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09882; Wed, 4 Dec 96 12:43:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09875; Wed, 4 Dec 96 12:43:39 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA26757; Wed, 4 Dec 1996 12:36:07 -0800 Received: from relay4.UU.NET (relay4.UU.NET [192.48.96.14]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA26466; Wed, 4 Dec 1996 12:36:05 -0800 Received: from twinkie.agile.com by relay4.UU.NET with SMTP (peer crosschecked as: twinkie.agile.com [198.3.104.2]) id QQbsri21132; Wed, 4 Dec 1996 15:35:46 -0500 (EST) Received: from moonpie.agile.com by twinkie.agile.com with SMTP (1.37.109.8/16.2.TW) id AA02284; Wed, 4 Dec 1996 15:34:03 -0500 Received: from aconta.agile.com ([198.3.105.52]) by moonpie.agile.com (4.1/SMI-4.1) id AA00220; Wed, 4 Dec 96 15:33:41 EST Received: by aconta.agile.com with Microsoft Mail id <01BBE25D.77828920@aconta.agile.com>; Thu, 5 Dec 1996 03:36:14 -0500 Message-Id: <01BBE25D.77828920@aconta.agile.com> From: Alex Conta To: "ipng@sunroof.eng.sun.com" , "jinmei@backyard.wide.toshiba.co.jp" , "'owner-ipng@sunroof.eng.sun.com'" Subject: (IPng 2552) Re: [Q] ICMPv6 Echo message with Routing header Date: Thu, 5 Dec 1996 03:36:08 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ---------- From: owner-ipng@sunroof.eng.sun.com[SMTP:owner-ipng@sunroof.eng.sun.com] Sent: Wednesday, December 04, 1996 1:55 PM To: ipng@sunroof.eng.sun.com; jinmei@backyard.wide.toshiba.co.jp Subject: (IPng 2551) Re: [Q] ICMPv6 Echo message with Routing header > > Hello, > > I have a question about an IPv6 packet which contains ICMPv6 Echo > Request message and at least one Routing header. > > RFC 1122 says that: > If a Source Route option is received in an ICMP Echo > Request, the return route MUST be reversed and used as a > Source Route option for the Echo Reply message. > > On the analogy of the above rule, we MUST reserve (one of) the Routing > header(s) and use it as a Routing header for the ICMPv6 Echo Reply > message. > > But as far as I read RFC 1883(IPv6 spec.) and RFC 1885(ICMPv6), I > couldn't decide whether we must or not. > > Do I miss something in the RFCs? Or can I find the answer in another > document? If anyone knows, please let me know. > As far as I remember, it is not required in IPv6 to reverse the route when replying to a source routed packet. It is subject to the local policy of the replying node. 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 Indeed, the consensus was or seemed to be - with the ICMPv6 specification tacitly underlining it - that the return of an ICMP message may find a better route (path) if the route header of the IPv6 triggering packet is not reversed, and therefore the rule of reversing the header was not enforced by the document. At the time of writing the document we considered all ICMP messages to fall into the same category. Alex ------------------------------------------------------------------------------ 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 Dec 4 13:57:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09977; Wed, 4 Dec 96 13:57:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09970; Wed, 4 Dec 96 13:57:42 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA11907; Wed, 4 Dec 1996 13:50:10 -0800 Received: from relay4.UU.NET (relay4.UU.NET [192.48.96.14]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA24612; Wed, 4 Dec 1996 13:49:28 -0800 Received: from twinkie.agile.com by relay4.UU.NET with SMTP (peer crosschecked as: twinkie.agile.com [198.3.104.2]) id QQbsrn05230; Wed, 4 Dec 1996 16:49:08 -0500 (EST) Received: from moonpie.agile.com by twinkie.agile.com with SMTP (1.37.109.8/16.2.TW) id AA03154; Wed, 4 Dec 1996 16:47:40 -0500 Received: from aconta.agile.com ([198.3.105.52]) by moonpie.agile.com (4.1/SMI-4.1) id AA00604; Wed, 4 Dec 96 16:47:17 EST Received: by aconta.agile.com with Microsoft Mail id <01BBE267.BFD162A0@aconta.agile.com>; Thu, 5 Dec 1996 04:49:51 -0500 Message-Id: <01BBE267.BFD162A0@aconta.agile.com> From: Alex Conta To: "ipng@sunroof.eng.sun.com" , "'owner-ipng@sunroof.eng.sun.com'" Subject: (IPng 2553) RE: link MTU Date: Thu, 5 Dec 1996 04:49:50 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is not meant to be the authoritative confirmation. Just as an opinion, I think we followed a model that made sense, which = happened to be the IPv4 model. Why should the IP layer or for that matter any other = "user layer" of the link layer have any knowledge of the link layer = header length? What is relevant for a user of the link layer it is the maximum size of the user packet, i.e. = the maximum=20 size of a link layer packet that the link can transmit minus the length = of the link header.=20 I thought that it was and is clear throughout the IPv6 documents that = the MTU of a link at the IP layer is the maximum length of the IPv6 = packet on that link. The "IPv6 tunneling" specification is consistent = with that, in the definition and use of the "IPv6 tunnel MTU" as a = virtual link MTU. Obviously if there are other interpretations we need = a clearer definition. Alex =20 ---------- From: = owner-ipng@sunroof.eng.sun.com[SMTP:owner-ipng@sunroof.eng.sun.com] Sent: Wednesday, December 04, 1996 11:33 AM To: ipng@sunroof.eng.sun.com Subject: (IPng 2548) link MTU Hi, The inter-operability test at UNH has shown that there is a disagreement whether the link-layer header is included in the link MTU value for a given link. The discrepancy has been detected in the value of the MTU option of Router Advertisements sent by different routers. I guess the terminology definitions of ND and Path MTU Discovery specs suggest that the link MTU value includes only the maximum size of the data portion of link frame, i.e. IPv6 packet itself: packet - an IPv6 header plus payload. link MTU - the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed in one piece over a link. An authoritative conformation one way or another would help to resolve this tiny disagreement. Thanks, 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 ------------------------------------------------------------------------------ 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 Dec 4 14:10:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10018; Wed, 4 Dec 96 14:10:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10012; Wed, 4 Dec 96 14:10:06 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA14905; Wed, 4 Dec 1996 14:02:34 -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 OAA00038 for ; Wed, 4 Dec 1996 14:02:33 -0800 Received: from gungnir.fnal.gov ("port 37203"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01ICM98KB6K4000I9M@FNAL.FNAL.GOV> for ipng@sunroof.Eng.Sun.COM; Wed, 04 Dec 1996 16:02:31 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA28415; Wed, 04 Dec 1996 16:01:13 -0600 Date: Wed, 04 Dec 1996 16:01:13 -0600 From: Matt Crawford Subject: (IPng 2554) Re: link MTU In-Reply-To: "05 Dec 1996 04:49:50 EST." <"01BBE267.BFD162A0"@aconta.agile.com> To: "ipng@sunroof.eng.sun.com" Message-Id: <199612042201.QAA28415@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 AA10025; Wed, 4 Dec 96 14:11:52 PST Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10019; Wed, 4 Dec 96 14:11:29 PST Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA17145; Wed, 4 Dec 1996 14:03:55 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA19321; Wed, 4 Dec 1996 14:03:28 -0800 Date: Wed, 4 Dec 1996 14:03:28 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199612042203.OAA19321@bobo.eng.sun.com> To: dhaskin@BayNetworks.COM Subject: (IPng 2555) Re: link MTU 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 guess the terminology definitions of ND and Path MTU Discovery > specs suggest that the link MTU value includes only the maximum size > of the data portion of link frame, i.e. IPv6 packet itself: > > packet - an IPv6 header plus payload. > > link MTU - the maximum transmission unit, i.e., maximum packet > size in octets, that can be conveyed in one piece over > a link. > > An authoritative conformation one way or another would help to resolve > this tiny disagreement. I think the specs are authoritative enough - their definitions don't just "suggest" things - they define things. If you insert the definition for "packet" in the definition for "link MTU" you get something like this: link MTU - the maximum transmission unit, i.e., maximum size of in octets, that can be conveyed in one piece over a link. I don't understand how this can be mis-interpreted to include the link-layer header. What am I missing? 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 Thu Dec 5 01:46:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00440; Thu, 5 Dec 96 01:46:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00434; Thu, 5 Dec 96 01:45:46 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA24187; Thu, 5 Dec 1996 01:38:14 -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 BAA10311 for ; Thu, 5 Dec 1996 01:38:07 -0800 From: Masataka Ohta Message-Id: <199612050936.SAA11621@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA11621; Thu, 5 Dec 1996 18:35:53 +0859 Subject: (IPng 2556) Re: Draft IPng Working Group Agenda To: hinden@Ipsilon.COM (Bob Hinden) Date: Thu, 5 Dec 96 18:35:52 JST Cc: ipng@sunroof.eng.sun.com, hinden@Ipsilon.COM, deering@cisco.com In-Reply-To: <3.0.32.19961203151115.006fe16c@mailhost.ipsilon.com>; from "Bob Hinden" at Dec 3, 96 3:11 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob; > 8+8 Addressing Proposal / Mike O'Dell (45 min) If you think it's time to resume the discussion on alternative addressing architectures, could you please also discuss on existing proposals including mine? I think I need 5 minutes for the representation. Masataka Ohta ------------------------------------------------------------------------------ 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 Dec 5 04:44:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00563; Thu, 5 Dec 96 04:44:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00557; Thu, 5 Dec 96 04:44:00 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA07605; Thu, 5 Dec 1996 04:36:26 -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 EAA08651 for ; Thu, 5 Dec 1996 04:36:27 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id HAA13916; Thu, 5 Dec 1996 07:26:58 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA06638; Thu, 5 Dec 1996 07:26:52 -0500 Message-Id: <9612051226.AA06638@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: jinmei@backyard.wide.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: (IPng 2557) Re: [Q] ICMPv6 Echo message with Routing header In-Reply-To: Your message of "Wed, 04 Dec 96 10:36:52 PST." <199612041836.KAA18719@feller.mentat.com> Date: Thu, 05 Dec 96 07:26:52 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk TIm, I don't know about you and I have not been thru all of 1122 yet, but I think RFC 1122 is NULL and VOID for IPv6 and some of RFC 1123. I think this will be an issue for our customers too when we ship IPv6. I don't think they can depend on RFC 1122 and 1123 being completely in tact. I think someone should check the specs. After the IPng directorate the IETF was supposed to charter some effort to look at all affected specs by IPv6 but that has never taken place. RFC 1001/1002 is another case to check most likely too. /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 Dec 5 08:59:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00754; Thu, 5 Dec 96 08:59:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00748; Thu, 5 Dec 96 08:59:45 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA09779; Thu, 5 Dec 1996 08:52:12 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA29436 for ; Thu, 5 Dec 1996 08:52:12 -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 IAA23770; Thu, 5 Dec 1996 08:52:06 -0800 Message-Id: <3.0.32.19961205084803.006a9488@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 05 Dec 1996 08:49:27 -0800 To: Masataka Ohta From: Bob Hinden Subject: (IPng 2558) Re: Draft IPng Working Group Agenda Cc: ipng@sunroof.eng.sun.com, hinden@Ipsilon.COM, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >If you think it's time to resume the discussion on alternative >addressing architectures, could you please also discuss on existing >proposals including mine? > >I think I need 5 minutes for the representation. I will add you to the agenda. 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 Dec 5 09:28:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00777; Thu, 5 Dec 96 09:28:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00589; Thu, 5 Dec 96 05:08:13 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA10411; Thu, 5 Dec 1996 05:00:39 -0800 Received: from marino.backyard.wide.toshiba.co.jp (ceres.wide.toshiba.co.jp [202.249.10.113]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA12408 for ; Thu, 5 Dec 1996 05:00:39 -0800 Received: (from mailer@localhost) by marino.backyard.wide.toshiba.co.jp (8.7.5/8.7.3) id WAA01741; Thu, 5 Dec 1996 22:07:36 +0900 (JST) Received: from samber.backyard.wide.toshiba.co.jp(133.196.2.11) by marino.backyard.wide.toshiba.co.jp via smap (V1.3) id sma001739; Thu Dec 5 22:07:20 1996 Received: from brian.backyard.wide.toshiba.co.jp (root@brian.backyard.wide.toshiba.co.jp [133.196.2.32]) by samber.backyard.wide.toshiba.co.jp (8.7.5/8.7.3) with ESMTP id WAA20902; Thu, 5 Dec 1996 22:00:34 +0900 (JST) Message-Id: <199612051300.WAA20902@samber.backyard.wide.toshiba.co.jp> To: aconta@lucent.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2559) Re: [Q] ICMPv6 Echo message with Routing header In-Reply-To: Your message of "Thu, 5 Dec 1996 03:36:08 -0500" References: <01BBE25D.77828920@aconta.agile.com> X-Mailer: Mew version 1.06 on Emacs 19.34.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 05 Dec 1996 21:59:35 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, Dimitry and Alex, Thank you all for replying so quickly. I understood that a host is not required to reverse the received Routing header. Whether the host do so or not is its local decision. Moreover, from the security point of view, the host shouldn't reverse the packet(unless it's authenticated). Thanks. JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@backyard.wide.toshiba.co.jp ------------------------------------------------------------------------------ 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 Dec 5 17:46:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01960; Thu, 5 Dec 96 17:46:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01954; Thu, 5 Dec 96 17:46:40 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA15650; Thu, 5 Dec 1996 17:39:06 -0800 Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA21669 for ; Thu, 5 Dec 1996 17:39:03 -0800 Message-Id: <199612060139.RAA21669@mercury.Sun.COM> Received: from RALVM6 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5717; Thu, 05 Dec 96 20:38:57 EST Date: Thu, 5 Dec 96 17:59:03 EST From: "Karen Tracey" To: thartric@mentat.com, rstevens@kohala.com Cc: IPNG@SUNROOF.eng.sun.com Subject: (IPng 2560) Re: updated sockets API: draft-ietf-ipngwg-bsd-api-06.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Hartrick wrote: > 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? This was discussed in Montreal (maybe LA too, I wasn't there). >From the Montreal meeting minutes, under Spec Changes/Clarifications: > o Eliminate (reserve) the priority field (and exclude from > Authentication Header (AH) computation? > > Currently encourages hosts to sent more packets than will get through > to the destination. Encourages bad behavior. Deering suggests this > is a research topic and we should get more experience before > specifying. > > Discussion that it can be used now to distinguish control traffic now > (e.g. router updates, etc.). > > Would also be nice to have some reserved bits that could be used for > new features later. > > Neighbor discovery currently specifies a priority for ND packets. > > Group agreed to set the bits to all zeros now. Less clear about > excluding them from the AH. > > Discuss issue further on mailing list. > But I don't recall seeing any further discussion on this list? It seems that section 3.8 (Flow Information) could be simplified considerably if the priority bits were considered reserved, must be set to zero. I have a few other comments/questions on the api draft: 1 - In many sections (3.8, 3.9, 3.10, and others), information about what header files need to be #include'd is contained in the text discussion. In others (6.3, 6.4) the information is in the code snippets, where necessary #include's are listed. It would be nice if the draft were consistent. I prefer the 2nd method, for me it makes the information easier to find. 2 - Why was chosen to hold the prototypes, etc. for the new interface-related functions? My first guess for where to put/find these would have been . 3 - Why was a new constant, IF_MAXNAME, defined, when already has IFNAMSIZ that seems to define the same thing? 4 - There's a typo in the 1st sentence of section 4.1; the word name has an extra s tagged on the end. 5 - Section 4.3 states that the if_nameindex() function returns memory that was malloc'd by the function and can be freed by the caller. This makes alarm bells ring in my head. I think there are (were?) some environments where libraries may have their own heap space, and it isn't safe for the caller to free something that was malloc'd in a library routine. (I know I ran into this problem once, I just can't remember what the environment was.) getaddrinfo() also allocates memory that is returned to its caller. But getaddrinfo() has a companion function, freeaddrinfo(), that can be called to free the memory. Should a similar approach be taken with if_nameindex()? 6 - Section 6.4, in the discussion of getnameinfo(), it is noted that the caller must provide buffers large enough to hold the fully qualified domain hostname and full service name. But no information is given on how big these might be. The next section provides some #define's for the buffer sizes needed for inet_ntop. Should/can the same be done for the buffers needed for getnameinfo()? There is a maximum size of a fully qualified domain hostname, isn't there? Is there a limit on the size of a service name? 7 - The following text is found in section 6.5: If the af argument is AF_INET, the function accepts a string in the standard IPv4 dotted-decimal form: ddd.ddd.ddd.ddd where ddd is a one to three digit decimal number between 0 and 255. ------- Also there is mention of the address conversion failing if the input is not a valid dotted decimal string. This implies that inet_pton for AF_INET does not simply use inet_addr() under the covers, since inet_addr() seems to consider any numeric string "valid", and does things like interpret a leading 0 to mean octal representation. So, inet_pton() will not return the same value as inet_addr() for some input strings? Is this worth noting somewhere? Karen Tracey ------------------------------------------------------------------------------ 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 Dec 6 01:58:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02306; Fri, 6 Dec 96 01:58:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02300; Fri, 6 Dec 96 01:57:48 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA04135; Fri, 6 Dec 1996 01:50:13 -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 BAA23740 for ; Fri, 6 Dec 1996 01:50:12 -0800 From: Masataka Ohta Message-Id: <199612060948.SAA14928@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA14928; Fri, 6 Dec 1996 18:48:31 +0900 Subject: (IPng 2561) Re: Draft IPng Working Group Agenda To: hinden@Ipsilon.COM (Bob Hinden) Date: Fri, 6 Dec 96 18:48:29 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com, hinden@Ipsilon.COM, deering@cisco.com In-Reply-To: <3.0.32.19961205084803.006a9488@mailhost.ipsilon.com>; from "Bob Hinden" at Dec 5, 96 8:49 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob; > >If you think it's time to resume the discussion on alternative > >addressing architectures, could you please also discuss on existing > >proposals including mine? > > > >I think I need 5 minutes for the representation. > > I will add you to the agenda. > Thank you. My expired draft is available at: ftp://ftp.jain.ad.jp/pub/ids/draft-ohta-ipv6-addr-arch-00.txt Masataka Ohta ------------------------------------------------------------------------------ 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 Dec 6 07:25:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02507; Fri, 6 Dec 96 07:25:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02501; Fri, 6 Dec 96 07:25:24 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA03469; Fri, 6 Dec 1996 07:17:50 -0800 Received: from horus.imag.fr (horus.imag.fr [129.88.38.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA10616 for ; Fri, 6 Dec 1996 07:17:43 -0800 Received: (from richier@localhost) by horus.imag.fr (8.8.1/8.6.9) id QAA23359 for ipng@sunroof.eng.sun.com; Fri, 6 Dec 1996 16:17:40 +0100 (MET) Date: Fri, 6 Dec 1996 16:17:40 +0100 (MET) From: Jean-Luc Richier Message-Id: <199612061517.QAA23359@horus.imag.fr> Organization: IMAG, Grenoble, France X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.eng.sun.com Subject: (IPng 2562) Link-local addresses and names Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think that there is a problem which has been overlooked in the discussions about API, that is the way to map link-local addresses to names, or to global addresses. Today, the proposed IPv6 routing protocols (rip, ospf) use link-local addresses to design routers. Therefore all routing tables contains mostly link-local addresses. This is a big problem when one try to list the route tables : for exemple on my machine netstat -r lists all the gateways in a numeric form. There have been progress in defining a IpV6 MIB, and I try to imagine a network explorer command in an IPv6 snmp manager. The progam will discover the link-local addresses of the routers one hop away, but it will be unable to find their name, or to talk with them. To be able to modify this kind of program for IpV6, or to write a useful snmp-netstat program, we need a function which map link-local address, ``link name'' -> unique name - or global address (Also : how do we provide the ``link name'' ? it is not simply an index, we need a globally unique name.) I think that this is a important function, which should be part of gethostbyaddr and getnameinfo. Does somebody has proposed a solution to be able to identify a machine when one has only a link-local addresses and a link ? - I know the draft-ietf-ipngwg-linkname-00, but it does not seems to solve the problem if the asking machins in not directly on the link. Perhaps using source routed inquiries ? But I fear that this will create a lot of traffic - There is no easy solution to put the addr->name map in the DNS, as the adresses are only valid on one link, and no provision is done in the DNS map to provide a link information. -- Jean-Luc RICHIER (Jean-Luc.Richier@Imag.Fr richier@imag.fr) Laboratoire Logiciels, Systemes et Reseaux (LSR-IMAG) IMAG-CAMPUS, BP 53, F-38041 GRENOBLE Cedex 9 Tel : (33) 76 82 72 32 Fax : (33) 76 82 72 87 ------------------------------------------------------------------------------ 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 Dec 6 09:06:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02648; Fri, 6 Dec 96 09:06:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02642; Fri, 6 Dec 96 09:06:29 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA22026; Fri, 6 Dec 1996 08:58:54 -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 IAA16155 for ; Fri, 6 Dec 1996 08:58:53 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA20156; Fri, 6 Dec 1996 11:47:54 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA12091; Fri, 6 Dec 1996 11:47:52 -0500 Message-Id: <9612061647.AA12091@wasted.zk3.dec.com> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com, deering@cisco.com Subject: (IPng 2563) Re: Draft IPng Working Group Agenda In-Reply-To: Your message of "Tue, 03 Dec 96 15:11:17 PST." <3.0.32.19961203151115.006fe16c@mailhost.ipsilon.com> Date: Fri, 06 Dec 96 11:47:52 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, Can we give Bill Lenharth time to tell all what happened at UNH with IPv6 testing this week too? 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 Dec 6 10:31:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02900; Fri, 6 Dec 96 10:31:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02893; Fri, 6 Dec 96 10:31:14 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA12490; Fri, 6 Dec 1996 10:23:38 -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 KAA21085 for ; Fri, 6 Dec 1996 10:23:11 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id SAA06351; Fri, 6 Dec 1996 18:21:58 GMT Date: Fri, 6 Dec 1996 18:21:58 GMT Message-Id: <199612061821.SAA06351@oberon.di.fc.ul.pt> From: Pedro Roque To: Jean-Luc Richier Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2564) Link-local addresses and names In-Reply-To: <199612061517.QAA23359@horus.imag.fr> References: <199612061517.QAA23359@horus.imag.fr> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Jean-Luc" == Jean-Luc Richier writes: Jean-Luc> I think that there is a problem which has been Jean-Luc> overlooked in the discussions about API, that is the way Jean-Luc> to map link-local addresses to names, or to global Jean-Luc> addresses. Mapping link-local address to names can only be done using something like what is proposed in . Mapping link-local addresses to global addresses cannot be done deterministically. Jean-Luc> Today, the proposed IPv6 routing protocols (rip, ospf) Jean-Luc> use link-local addresses to design routers. Therefore Jean-Luc> all routing tables contains mostly link-local Jean-Luc> addresses. This is a big problem when one try to list Jean-Luc> the route tables : for exemple on my machine netstat -r Jean-Luc> lists all the gateways in a numeric form. Jean-Luc> There have been progress in defining a IpV6 MIB, and I Jean-Luc> try to imagine a network explorer command in an IPv6 Jean-Luc> snmp manager. The progam will discover the link-local Jean-Luc> addresses of the routers one hop away, but it will be Jean-Luc> unable to find their name, or to talk with them. Indeed. But there is nothing you can do about it, remotly, just having the link-local address. The queried system will have to be able to supply the mapping (assuming you use somethink like draft-harrington). Or do a proxy snmp query on the remote system asking for it's name. Jean-Luc> To be able to modify this kind of program for IpV6, or Jean-Luc> to write a useful snmp-netstat program, we need a Jean-Luc> function which map link-local address, ``link name'' -> Jean-Luc> unique name - or global address (Also : how do we Jean-Luc> provide the ``link name'' ? it is not simply an index, There is not such think as a unique link name. You can ways ask DNS for reverse resoltion of the prefixes assigned to the link i guess (nodes may have a different prespective of the link prefixes than routers... different nodes may have different prespectives even). Jean-Luc> we need a globally unique name.) I think that this is a Jean-Luc> important function, which should be part of Jean-Luc> gethostbyaddr and getnameinfo. The WG would need to consider Dan's draft as mandatory to implement first. I'd the impression on the last WG meeting that it is still not the case. Jean-Luc> Does somebody has proposed a solution to be able to Jean-Luc> identify a machine when one has only a link-local Jean-Luc> addresses and a link ? Yes. See above. ./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 Dec 6 17:28:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03628; Fri, 6 Dec 96 17:28:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03622; Fri, 6 Dec 96 17:28:12 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA11334; Fri, 6 Dec 1996 17:20:37 -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 RAA04140 for ; Fri, 6 Dec 1996 17:20:36 -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 RAA00985; Fri, 6 Dec 1996 17:20:34 -0800 Message-Id: <3.0.32.19961206171743.006f77c4@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 06 Dec 1996 17:17:49 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 2565) IPng Working Group Agenda Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached is the updated agenda. Bob ---------------------------------------------------------------- IPng Working Group Draft Agenda for San Jose IETF Meeting --------------------------------------- Monday 1:00-3:00pm (120 min) Introduction and Bash Agenda / Steve Deering (5 min) Document Status / Bob Hinden (10 min) ITU Addressing Request Status / Bob Hinden (1 min) Priority Field / Steve Deering (10 min) Default Hop Limit / Steve Deering (10 min) IPv6 over Token Ring (10 min) BSD API / Bob Gilligan (10 min) Simple IPsec API / Dan McDonald (5 min) Advanced API spec / Matt Thomas (15 min) Tunneling Spec / Alex Conta (10 min) Router Alert Option / Ran Atkinson (10 min) Header Compression spec / Micke Degermark (10 min) Host Anycast / Jim Bound (10 min) IPv6 Multicast Address Assignment draft / Bob Hinden (5 min) Monday 7:30-10:00pm 8+8 Addressing Proposal / Mike O'Dell (45 min) Alternative Addressing Architectures / Masataka Ohta (5 min) Multihoming / Source Address Selection / Steve Deering (30 min) Interface ID Proposal / Steve Deering (20 min) IPv6 MIB / Dimitry Haskin (15 min) Open for Additional Discussion from Monday Thursday 1:00-3:00pm Moving Base IPv6 Specs to Draft Standard / Steve Deering (30 min) IPv6 Packets over IPv4 Networks without Tunnels / Brian Carpenter (15 min) Multicast Routing / Thomas Narten (10 min) Router / Network Renumbering / Bob Hinden (10 min) Inter-Domain Routing (IDRP, BGP5, ?) / Bob Hinden (10 min) Open for Additional Discussion from Previous Sessions ------------------------------------------------------------------------------ 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 Dec 9 04:54:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05469; Mon, 9 Dec 96 04:54:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05463; Mon, 9 Dec 96 04:54:04 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA21937; Mon, 9 Dec 1996 04:46:25 -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 EAA25256 for ; Mon, 9 Dec 1996 04:46:15 -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 FAA25273; Mon, 9 Dec 1996 05:46:14 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.3/8.8.3) id FAA19914; Mon, 9 Dec 1996 05:46:13 -0700 (MST) Message-Id: <199612091246.FAA19914@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Mon, 9 Dec 1996 05:46:12 -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: "Karen Tracey" , thartric@mentat.com Subject: (IPng 2566) Re: updated sockets API: draft-ietf-ipngwg-bsd-api-06.txt Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In Karen Tracey's message of Dec 5, 5:59pm:] > > Tim Hartrick wrote: > > > 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? > > This was discussed in Montreal (maybe LA too, I wasn't there). > > ... > > Discuss issue further on mailing list. > > > > But I don't recall seeing any further discussion on this list? > > It seems that section 3.8 (Flow Information) could be simplified > considerably if the priority bits were considered reserved, must > be set to zero. I'd like a final working group consensus (this week?) before we rip this out of the draft. > I have a few other comments/questions on the api draft: > > 1 - In many sections (3.8, 3.9, 3.10, and others), information about > what header files need to be #include'd is contained in the > text discussion. In others (6.3, 6.4) the information is in > the code snippets, where necessary #include's are listed. It > would be nice if the draft were consistent. I prefer the 2nd > method, for me it makes the information easier to find. Agreed--the 2nd method is also more consistent with other documents like man pages and Posix. > 2 - Why was chosen to hold the prototypes, etc. for > the new interface-related functions? My first guess for where > to put/find these would have been . Either is fine with me, and perhaps is more consistent. > 3 - Why was a new constant, IF_MAXNAME, defined, when > already has IFNAMSIZ that seems to define the same thing? Good point--I missed IFNAMSIZ. > 4 - There's a typo in the 1st sentence of section 4.1; the > word name has an extra s tagged on the end. Fixed. > 5 - Section 4.3 states that the if_nameindex() function returns > memory that was malloc'd by the function and can be freed > by the caller. This makes alarm bells ring in my head. > I think there are (were?) some environments where libraries > may have their own heap space, and it isn't safe for the caller > to free something that was malloc'd in a library routine. > (I know I ran into this problem once, I just can't remember > what the environment was.) getaddrinfo() also allocates memory > that is returned to its caller. But getaddrinfo() has a companion > function, freeaddrinfo(), that can be called to free the memory. > Should a similar approach be taken with if_nameindex()? Either is fine with me. I am not aware of the problem you mention with libraries/malloc. > 6 - Section 6.4, in the discussion of getnameinfo(), it is noted > that the caller must provide buffers large enough to hold > the fully qualified domain hostname and full service name. > But no information is given on how big these might be. The > next section provides some #define's for the buffer sizes > needed for inet_ntop. Should/can the same be done for the > buffers needed for getnameinfo()? There is a maximum size of > a fully qualified domain hostname, isn't there? Is there a > limit on the size of a service name? I believe the DNS limits an FQDN to 255 characters, but I cannot find any related #define in . I also cannot find any limits on the service name size, in either the BSD sources or the Posix.1g spec. I'd think 255 is adequate for this also. > 7 - The following text is found in section 6.5: > > If the af argument is AF_INET, the function accepts a string in the > standard IPv4 dotted-decimal form: > > ddd.ddd.ddd.ddd > > where ddd is a one to three digit decimal number between 0 and 255. > ------- > > Also there is mention of the address conversion failing if the input > is not a valid dotted decimal string. This implies that inet_pton > for AF_INET does not simply use inet_addr() under the covers, since > inet_addr() seems to consider any numeric string "valid", and does > things like interpret a leading 0 to mean octal representation. So, > inet_pton() will not return the same value as inet_addr() for some > input strings? Is this worth noting somewhere? There was a note to this list months ago by Paul Vixie about some of the wierd input that inet_addr() will accept, and unless someone complained (I don't recall anyone complaining) he didn't plan on having inet_pton() accept some of the inputs that inet_addr() allows. And you are right, we should add some wording about this. > Karen Tracey Many thanks for the careful reading. 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 Mon Dec 9 11:15:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05950; Mon, 9 Dec 96 11:15:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05944; Mon, 9 Dec 96 11:15:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA00595; Mon, 9 Dec 1996 11:07:53 -0800 Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA09585 for ; Mon, 9 Dec 1996 11:07:39 -0800 Message-Id: <199612091907.LAA09585@mercury.Sun.COM> Received: from RALVM6 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5280; Mon, 09 Dec 96 14:07:22 EST Date: Mon, 9 Dec 96 14:06:55 EST From: "Karen Tracey" To: ipng@sunroof.eng.sun.com Subject: (IPng 2567) Re: updated sockets API: draft-ietf-ipngwg-bsd-api-06.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Both draft-ietf-ipngwg-bsd-api-06.txt (Basic Socket Interface Extensions for IPv6) and draft-stevens-advanced-api-00.txt (Advanced Sockets API for IPv6) now have sections named "Interface Identification". This is a little confusing, since the 2 drafts say somewhat different things. Is the intent to move this section to the "Basic" draft and remove it from the "Advanced" draft? The differences are: "Advanced" defines a new ioctl, SIOGIFINDEX, to map an interface name to an interface index. "Basic" defines a somewhat higer-level function, if_nametoindex(), to do the same thing. How exactly this function is implemented (with sysctl() or ioctl() or ...) is left to the implementation. With "Basic" now already addressing how to map interface name to index, it looks like sections 5.1 and 5.2 can be removed from "Advanced" and replaced with a pointer to the "Basic" spec. "Basic" defines some additional functions to do the reverse mapping and retrieve information about all interfaces. That's good, there is no conflict with what is in "Advanced". "Advanced" discusses, in sections 5.3 and 5.4, how to find out the receiving interface and specify the sending interface, using ancillary data. This isn't covered in "Basic" and seems like it should stay in "Advanced", since that is where all the discussion of ancillary data is. Are there now two ways for a multicast application to specify the sending interface? "Basic" defines the IPV6_MULTICAST_IF setsockopt option, and "Advanced" defines an ancillary data method to do the same thing? Can a multicast application use either/both? If yes to both, what is the behavior if both are used (which one overrides the other)? Thanks, Karen Tracey ------------------------------------------------------------------------------ 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 Dec 9 13:00:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06141; Mon, 9 Dec 96 13:00:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06135; Mon, 9 Dec 96 13:00:43 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA28682; Mon, 9 Dec 1996 12:53:03 -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 MAA27189 for ; Mon, 9 Dec 1996 12:52:26 -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 NAA25476; Mon, 9 Dec 1996 13:51:51 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.3/8.8.3) id NAA20527; Mon, 9 Dec 1996 13:51:51 -0700 (MST) Message-Id: <199612092051.NAA20527@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Mon, 9 Dec 1996 13:51:50 -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: "Karen Tracey" , ipng@sunroof.eng.sun.com Subject: (IPng 2568) Re: updated sockets API: draft-ietf-ipngwg-bsd-api-06.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Dec 9, 2:06pm you write:] > Both > > draft-ietf-ipngwg-bsd-api-06.txt (Basic Socket Interface Extensions for IPv6) > > and > > draft-stevens-advanced-api-00.txt (Advanced Sockets API for IPv6) > > now have sections named "Interface Identification". This is a little > confusing, since the 2 drafts say somewhat different things. Is the > intent to move this section to the "Basic" draft and remove it from > the "Advanced" draft? Yes. The interface ID stuff first appeared in the advanced API, as we needed it for received interface and outgoing interface. Then a few weeks ago on this list Steve Deering mentioned that if he had a chance to redo the multicasting interface he would specify the interface with some form of identifier and not with the local IP address, since some interfaces have no IP address. We then moved the interface ID stuff into from the advanced to the basic API. It will be removed from the next draft of the advanced API. When doing this I also realized two points. First, we shouldn't be specifying this feature using ioctl, as that's an implementation technique, not a "good" user interface. Instead we should specify the functions that do what we need, and how you implement these is up to you. If you want to use an ioctl, that's fine, but we shouldn't dictate an ioctl. Next, I realized that you can implement all three functions that are now part of the basic API in a 4.3BSD-Reno-derived kernel without any kernel changes whatsoever. They can be implemented as simple library functions that just call sysctl() with the NET_RT_IFLIST command in the PF_ROUTE domain. BSD kernels already have a positive index associated with every interface. Sorry for the confusion--I should have added some "rationale" to the last draft of the basic API when these appeared. > Are there now two ways for a multicast application to specify > the sending interface? "Basic" defines the IPV6_MULTICAST_IF > setsockopt option, and "Advanced" defines an ancillary data > method to do the same thing? Can a multicast application use > either/both? If yes to both, what is the behavior if both are > used (which one overrides the other)? Good question. My first guess is that the IPV6_MULTICAST_IF socket option defines the default, in the application does not specify an outgoing interface using ancillary data, else the ancillary data overrides the socket option for just that output operation. Comments? 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 Dec 10 00:26:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06763; Tue, 10 Dec 96 00:26:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06757; Tue, 10 Dec 96 00:26:45 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA02089; Tue, 10 Dec 1996 00:19:05 -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 AAA05423 for ; Tue, 10 Dec 1996 00:18:56 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id IAA20579; Tue, 10 Dec 1996 08:18:41 GMT Date: Tue, 10 Dec 1996 08:18:41 GMT Message-Id: <199612100818.IAA20579@oberon.di.fc.ul.pt> From: Pedro Roque To: ipng@sunroof.eng.sun.com Subject: (IPng 2569) 8+8 (further discussion) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Assuming that the WG decides to explore the 8+8 aternative (or 6+2+8 which seamed to have better support)... The main goal seamed to be to support renumbering and domain-multihoming. Given it you must be able to dynamic change the Routing Goop ( and with it the communication address ) being used by upper layer protocols. - If i understand clearly from both the draft and the presentation we have on upper layer protocols bindings: - source ESD - destination ESD - destination RG Generally i can think of two strategies to change the DRG: - Use the last value you received. - Use a "binding update" scheme Both this situations will have to be authenticated. i.e. you cannot use the last received RG on non-authenticated packets because: a) It would be a child's play to high-jack the connection b) The RG is not checksumed (and could possible be currupt). >From a pratical perpective, every single comunication on the internet will have to be authenticated for this to work. Is it pratical to assume that we are ready to fullfil this requirement ? I think the group should discuss this in this meeting if at all possible, since actually being able to do renumbering and multi-homing are the key parts of the proposal (without them all the draft "goals" section goes down) 2 - UDP It is very likely that UDP (stateful) applications break down. In non-connected UDP sockets the application usally keeps the destination address from the first received packet and uses it during communication. Not that i do believe that the issue cannot be solved but that will need to be documented. Basically i think we need to understand how we can use this with upper layer protocols which are doing the real service anyway. ./Pedro. --- PS: isn't "goop" a slang word ? or is just my poor english showing up again ? ------------------------------------------------------------------------------ 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 Dec 10 07:23:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06979; Tue, 10 Dec 96 07:23:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06973; Tue, 10 Dec 96 07:23:03 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA19802; Tue, 10 Dec 1996 07:15:23 -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 HAA15252 for ; Tue, 10 Dec 1996 07:15:19 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id QAA10731; Tue, 10 Dec 1996 16:15:15 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA09284; Tue, 10 Dec 1996 16:15:14 +0100 Message-Id: <9612101515.AA09284@dxcoms.cern.ch> Subject: (IPng 2570) Re: 8+8 (further discussion) To: roque@di.fc.ul.pt (Pedro Roque) Date: Tue, 10 Dec 1996 16:15:14 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199612100818.IAA20579@oberon.di.fc.ul.pt> from "Pedro Roque" at Dec 10, 96 08:18:41 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 Pedro, I don't think it's a requirement thyat the destination RG is covered by the checksum or authenticator. The ESD is supposed to be unique for all practical purposes - i.e.. more so than an ipv4 address Of course (sez Mike who is sitting next to me) if you *wanted* to make the locator "fragile" for some reason, you could include the RG - but this is not what we were talking about yesterday. 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 Tue Dec 10 07:58:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07003; Tue, 10 Dec 96 07:58:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06997; Tue, 10 Dec 96 07:57:54 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA25723; Tue, 10 Dec 1996 07:50:13 -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 HAA28840 for ; Tue, 10 Dec 1996 07:50:08 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id PAA21816; Tue, 10 Dec 1996 15:49:48 GMT Date: Tue, 10 Dec 1996 15:49:48 GMT Message-Id: <199612101549.PAA21816@oberon.di.fc.ul.pt> From: Pedro Roque To: "Brian Carpenter CERN-CN" Cc: roque@di.fc.ul.pt (Pedro Roque), ipng@sunroof.eng.sun.com Subject: (IPng 2571) Re: 8+8 (further discussion) In-Reply-To: <9612101515.AA09284@dxcoms.cern.ch> References: <199612100818.IAA20579@oberon.di.fc.ul.pt> <9612101515.AA09284@dxcoms.cern.ch> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> " Brian" == Brian Carpenter CERN-CN writes: Brian> Pedro, I don't think it's a requirement thyat the Brian> destination RG is covered by the checksum or Brian> authenticator. The ESD is supposed to be unique for all Brian> practical purposes - i.e.. more so than an ipv4 address Brian, You are answering the wrong question :-) The problem is not the ESD but Rooting "thing". - You have to change it during connections. - You can only change it to an authenticated value Brian> Of course (sez Mike who is sitting next to me) if you Brian> *wanted* to make the locator "fragile" for some reason, Brian> you could include the RG - but this is not what we were Brian> talking about yesterday. ./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 Dec 10 08:57:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07072; Tue, 10 Dec 96 08:57:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07066; Tue, 10 Dec 96 08:57:28 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA06488; Tue, 10 Dec 1996 08:49:47 -0800 Received: from torga.ci.uminho.pt (torga.ci.uminho.pt [193.136.16.251]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA22909 for ; Tue, 10 Dec 1996 08:49:00 -0800 Received: from pessoa by torga.ci.uminho.pt (5.4R3.10/140.2) id AA07334; Tue, 10 Dec 1996 16:47:17 +0100 Received: by pessoa.ci.uminho.pt (5.4R3.10/140.2) id AA22260; Tue, 10 Dec 1996 16:46:28 +0100 From: si8319@ci.uminho.pt (Paulo Jorge Valverde Viegas Costa) Message-Id: <9612101546.AA22260@pessoa.ci.uminho.pt> Subject: (IPng 2572) IPv6 Implementations To: ipng@sunroof.eng.sun.com Date: Tue, 10 Dec 1996 16:46:27 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 PGP6] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I am a student at Minho University, PORTUGAL. My reserch interests focus on IPv6. I develop a project in this area, and I having some trouble in get implementations of IPv6 in the following plataforms: - PC whith LINUX - Sun Workstation with Sun Sparc Architecture - Dec Station - Digital - PC's with Windows Architecture. Where do I get those implementations? Will you help me? Thanks, Paulo Valverde. ------------------------------------------------------------------------------ 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 Dec 10 09:54:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07140; Tue, 10 Dec 96 09:54:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07134; Tue, 10 Dec 96 09:54:06 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA20011; Tue, 10 Dec 1996 09:46:24 -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 JAA17434 for ; Tue, 10 Dec 1996 09:46:11 -0800 Received: from gungnir.fnal.gov ("port 33269"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01ICUDY9NA0U0003UM@FNAL.FNAL.GOV>; Tue, 10 Dec 1996 11:44:07 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id LAA09547; Tue, 10 Dec 1996 11:42:36 -0600 Date: Tue, 10 Dec 1996 11:42:36 -0600 From: Matt Crawford Subject: (IPng 2573) Re: 8+8 (further discussion) In-Reply-To: "10 Dec 1996 08:18:41 GMT." <"199612100818.IAA20579"@oberon.di.fc.ul.pt> To: Pedro Roque Cc: ipng@sunroof.eng.sun.com Message-Id: <199612101742.LAA09547@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{ Generally i can think of two strategies to change the DRG: > - Use the last value you received. > - Use a "binding update" scheme > > Both this situations will have to be authenticated. [...] > From a pratical perpective, every single comunication on the internet will > have to be authenticated for this to work. You learn the Dest. RG in the first place from DNS (if you are the initiator). One could imagine checking for changes through a secure DNS. This checking might be triggered by either an apparent failure of the connection or the receipt of an apparently valid packet on the connection which has different RG than expected. I think secure DNS is nearer at hand than universal ipsec. And remember, a transitional period where both RG's are valid is still possible. A weak validation of an RG change might consist of sending a message to the old address and getting a confirming response. > PS: isn't "goop" a slang word ? or is just my poor english showing up again ? Ta. Mas nao faz coisa. Matt ------------------------------------------------------------------------------ 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 Dec 10 10:22:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07190; Tue, 10 Dec 96 10:22:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07184; Tue, 10 Dec 96 10:22:20 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA27474; Tue, 10 Dec 1996 10:14:26 -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 KAA29172 for ; Tue, 10 Dec 1996 10:14:04 -0800 Received: (rja@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id KAA16636; Tue, 10 Dec 1996 10:13:05 -0800 Date: Tue, 10 Dec 1996 10:13:05 -0800 From: Ran Atkinson Message-Id: <199612101813.KAA16636@cornpuffs.cisco.com> To: roque@di.fc.ul.pt Subject: (IPng 2574) Re: 8+8 (further discussion) In-Reply-To: <199612101549.PAA21816@oberon.di.fc.ul.pt> References: <9612101515.AA09284@dxcoms.cern.ch> Organization: cisco Systems Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pedro, I do not follow the assertion that moving to 6+2+8 would imply that all traffic would need to be authenticated. It is not clear to me that moving to 6+2+8 introduces any additional security issues to those previously present in existing IPv6 specifications. 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 Tue Dec 10 10:31:14 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07233; Tue, 10 Dec 96 10:31:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07227; Tue, 10 Dec 96 10:31:01 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA29996; Tue, 10 Dec 1996 10:23:17 -0800 Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA02690 for ; Tue, 10 Dec 1996 10:23:04 -0800 Message-Id: <199612101823.KAA02690@mercury.Sun.COM> Received: from RALVM6 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 6456; Tue, 10 Dec 96 13:22:09 EST Date: Tue, 10 Dec 96 13:18:13 EST From: "Karen Tracey" To: rstevens@kohola.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2575) Re: updated sockets API: draft-ietf-ipngwg-bsd-api-06.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich Stevens wrote: > > > > It seems that section 3.8 (Flow Information) could be simplified > > considerably if the priority bits were considered reserved, must > > be set to zero. > > I'd like a final working group consensus (this week?) before we rip > this out of the draft. Good plan. It seems objections were raised after the Montreal minutes came out, so now there is a new proposal for what to do with the priority bits. Hopefully the details will be posted on the list. It sounded to me like the new proposal could still impact section 3.8. Only one bit was to be used by "senders", and that bit was to flag traffic as interactive. So it still might be possible to simplify section 3.8. What I would like is to hide the need to shift & mask things by defining macros to access the flow and priority fields. Applications could use the macros instead of having to manipulate the fields directly. I think that would be easier on application writers, and less error prone. > > 5 - Section 4.3 states that the if_nameindex() function returns > > memory that was malloc'd by the function and can be freed > > by the caller. This makes alarm bells ring in my head. > > I think there are (were?) some environments where libraries > > may have their own heap space, and it isn't safe for the caller > > to free something that was malloc'd in a library routine. > > (I know I ran into this problem once, I just can't remember > > what the environment was.) getaddrinfo() also allocates memory > > that is returned to its caller. But getaddrinfo() has a companion > > function, freeaddrinfo(), that can be called to free the memory. > > Should a similar approach be taken with if_nameindex()? > Either is fine with me. I am not aware of the problem you mention with > libraries/malloc. I wish I could remember what the environment was. I just have this firm conviction that library routines that allocate memory should have companion functions that free the memory, in order to avoid problems. > I believe the DNS limits an FQDN to 255 characters, but I cannot find > any related #define in . I also cannot find any limits on > the service name size, in either the BSD sources or the Posix.1g spec. > I'd think 255 is adequate for this also. Anybody know where the FQDN limit is defined/documented? Anyone know of a service name limit? If not, does anyone object to 255? > There was a note to this list months ago by Paul Vixie about some of the > wierd input that inet_addr() will accept, and unless someone complained > (I don't recall anyone complaining) he didn't plan on having inet_pton() > accept some of the inputs that inet_addr() allows. And you are right, > we should add some wording about this. I'm glad inet_pton() will get rid of inet_addr()'s odd behavior... > Many thanks for the careful reading. Thanks to you for the draft revisions! Karen Tracey ------------------------------------------------------------------------------ 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 Dec 10 11:32:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07336; Tue, 10 Dec 96 11:32:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07330; Tue, 10 Dec 96 11:31:51 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA16097; Tue, 10 Dec 1996 11:24: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 LAA02855 for ; Tue, 10 Dec 1996 11:23:57 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id TAA22502; Tue, 10 Dec 1996 19:21:06 GMT Date: Tue, 10 Dec 1996 19:21:06 GMT Message-Id: <199612101921.TAA22502@oberon.di.fc.ul.pt> From: Pedro Roque To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2576) Re: 8+8 (further discussion) In-Reply-To: <199612101742.LAA09547@gungnir.fnal.gov> References: <"199612100818.IAA20579"@oberon.di.fc.ul.pt> <199612101742.LAA09547@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Matt" == Matt Crawford writes: >> Generally i can think of two strategies to change the DRG: - >> Use the last value you received. - Use a "binding update" >> scheme >> >> Both this situations will have to be authenticated. [...] >> From a pratical perpective, every single comunication on the >> internet will have to be authenticated for this to work. Matt> You learn the Dest. RG in the first place from DNS (if you Matt> are the initiator). One could imagine checking for changes Matt> through a secure DNS. Periodic checking ? I don't think it would be a good idea. You want something that does not force you to be constantly sending inquires... Matt> This checking might be triggered by Matt> either an apparent failure of the connection or the receipt Matt> of an apparently valid packet on the connection which has Matt> different RG than expected. I think secure DNS is nearer at Matt> hand than universal ipsec. Matt> And remember, a transitional period where both RG's are Matt> valid is still possible. A weak validation of an RG change Matt> might consist of sending a message to the old address and Matt> getting a confirming response. The 2 goals on the table are (as far i undertand it): - Support on-the-fly renumbering - Support multi-homed domains without requiring a prefix to be announced by a different provider than the delegation source. I conclude you have to support "on-the-fly" address changes for upper layer protocols for the proposal to be worth the costs. Matt> Ta. Mas nao faz coisa. Matt :-) ./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 Dec 10 11:44:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07348; Tue, 10 Dec 96 11:44:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07342; Tue, 10 Dec 96 11:44:16 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA18946; Tue, 10 Dec 1996 11:36:36 -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 LAA08582 for ; Tue, 10 Dec 1996 11:36:19 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id TAA22534; Tue, 10 Dec 1996 19:29:03 GMT Date: Tue, 10 Dec 1996 19:29:03 GMT Message-Id: <199612101929.TAA22534@oberon.di.fc.ul.pt> From: Pedro Roque To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2577) Re: 8+8 (further discussion) In-Reply-To: <199612101813.KAA16636@cornpuffs.cisco.com> References: <9612101515.AA09284@dxcoms.cern.ch> <199612101549.PAA21816@oberon.di.fc.ul.pt> <199612101813.KAA16636@cornpuffs.cisco.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Ran" == Ran Atkinson writes: Ran> Pedro, I do not follow the assertion that moving to 6+2+8 Ran> would imply that all traffic would need to be authenticated. Ran> It is not clear to me that moving to 6+2+8 introduces any Ran> additional security issues to those previously present in Ran> existing IPv6 specifications. My reasoning is as follows: Goal: - on the fly reassignment of destination address used by a comunication peer (change in dest RG) two general ways to do it: - binding update scheme [works for current IPv6 also... makes one doubt that 8+8 has significative advantages] (only binding update gets authenticated) (doesn't work anyway since the host doesn't know that it need to change the address) - last received RG For this to work all comunication need to be authenticated As you never know when a change will occur. So my assumption is for this to make sense (i.e. for the mentioned goals to be achieved) you need to authenticate every single IP7 packet. ./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 Dec 10 14:28:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07497; Tue, 10 Dec 96 14:28:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07491; Tue, 10 Dec 96 14:28:37 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA25756; Tue, 10 Dec 1996 14:20:55 -0800 Received: from INET-03-IMC.itg.microsoft.com (mail3.microsoft.com [131.107.3.23]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA11013 for ; Tue, 10 Dec 1996 14:20:53 -0800 Received: by INET-03-IMC.itg.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BBE689.D3E5EE70@INET-03-IMC.itg.microsoft.com>; Tue, 10 Dec 1996 11:03:52 -0800 Message-Id: From: Richard Draves To: "'Karen Tracey'" , "'rstevens@kohola.com'" Cc: "'ipng@sunroof.Eng.Sun.COM'" Subject: (IPng 2578) Re: updated sockets API: draft-ietf-ipngwg-bsd-api-06.txt Date: Tue, 10 Dec 1996 11:00:12 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 11 TEXT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Either is fine with me. I am not aware of the problem you mention with >> libraries/malloc. > >I wish I could remember what the environment was. I just have this >firm conviction that library routines that allocate memory should >have companion functions that free the memory, in order to avoid >problems. > >This problem sometimes occurs in Windows environments. If the sockets DLL is >linked with one C runtime and the client EXE/DLL is linked with a different C >runtime, then the client can't free() memory malloc()'d in the sockets DLL. ------------------------------------------------------------------------------ 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 Dec 10 21:53:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08383; Tue, 10 Dec 96 21:53:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08377; Tue, 10 Dec 96 21:52:45 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA10318; Tue, 10 Dec 1996 21:45:05 -0800 Received: from wwwnni.us.newbridge.com (wwwnni.us.newbridge.com [204.177.219.11]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA01566 for ; Tue, 10 Dec 1996 21:45:04 -0800 Received: (from adm@localhost) by wwwnni.us.newbridge.com (8.6.12/8.6.12) id AAA16587; Wed, 11 Dec 1996 00:48:33 -0500 Received: from herndon-gw1(204.177.219.66) by wwwnni via smap (V1.3) id sma016585; Wed Dec 11 00:48:04 1996 Received: from hernmaster.us.newbridge.com ([138.120.108.6]) by herndon-gw1.us.newbridge.com via smtpd (for wwwnni.us.newbridge.com [204.177.219.11]) with SMTP; 11 Dec 1996 05:44:22 UT Received: from lobster.nni (lobster.us.newbridge.com [138.120.85.102]) by hernmaster.us.newbridge.com (8.6.12/8.6.12) with SMTP id AAA08353; Wed, 11 Dec 1996 00:44:22 -0500 Received: by lobster.nni (5.0/SMI-SVR4) id AA06159; Wed, 11 Dec 1996 00:41:56 +0500 From: jhalpern@us.newbridge.com (Joel Halpern) Message-Id: <9612110541.AA06159@lobster.nni> Subject: (IPng 2579) Re: 8+8 (further discussion) To: roque@di.fc.ul.pt (Pedro Roque) Date: Wed, 11 Dec 1996 00:41:55 -0500 (EST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199612100818.IAA20579@oberon.di.fc.ul.pt> from "Pedro Roque" at Dec 10, 96 08:18:41 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One minor point on "route reversal", and its prohibition. It should always be remembered that we typically allow (and ignore) a critical case of route reversal. If you receive a UDP packet and wish to respond, or when you receive an initial TCP SYN, you use the source address. That is route reversal. It is permitted. So, a similar degree of unauthenticated route reversal with 6+2+* would seem to make sense. On the other hand, I would agree with Pedro that allowing replacment of the stored routing goop for an existing TCP connection clearly does require authentication. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ 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 Dec 10 22:00:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08402; Tue, 10 Dec 96 22:00:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08396; Tue, 10 Dec 96 22:00:40 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA10872; Tue, 10 Dec 1996 21:53:00 -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 VAA02949 for ; Tue, 10 Dec 1996 21:52:59 -0800 Received: from sparky.IOL.UNH.EDU by iol.unh.edu (4.1/SMI-4.1) id AA11557; Wed, 11 Dec 96 00:46:36 EST Received: by sparky.IOL.UNH.EDU (SMI-8.6/SMI-SVR4) id AAA02513; Wed, 11 Dec 1996 00:56:02 -0500 Date: Wed, 11 Dec 1996 00:56:02 -0500 From: qv@sparky.iol.unh.edu (Quaizar Vohra) Message-Id: <199612110556.AAA02513@sparky.IOL.UNH.EDU> To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pedro, I agree that with 8+8 anyone can easily hijack an ongoing communication. We might avoid this by a security mechanism, but this still leaves the denial of service attack open. So we need authentication. Not only that, we also need the site-boundary router to leak the new routing goop in the site and phase out the old one. In the transport layer we need to maintain states about the new and old routing goops. If a site is multihomed, the communcating node will have to deal with multiple routing goops, which defeats the claim that 8+8 solves the multihoming issue. But to me the problem does not seem to lie with 8+8, but rather with renumbering (8+8 probably aggravates it). I don't see a way other than authenication that will help us and I hate to think that authentication will have to become mandatory in deployment too, causing people like us in academic communities who don't want to waste the extra bandwidth in security. No solution seems to occur to me. I think, let people pay the price of extra bandwidth if they want sessions to survive renumbering. People like us who use telnet and ftp can live with killed sessions across renumbering. 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 Dec 10 22:26:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08444; Tue, 10 Dec 96 22:26:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08437; Tue, 10 Dec 96 22:25:45 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA13370; Tue, 10 Dec 1996 22:18:04 -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 WAA08261 for ; Tue, 10 Dec 1996 22:18:04 -0800 Received: from spruce.ipsilon.com (dialin2.Ipsilon.COM [205.226.3.242]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id WAA14739; Tue, 10 Dec 1996 22:18:02 -0800 Message-Id: <3.0.32.19961210180037.006cc4ec@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 10 Dec 1996 22:17:56 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 2581) W.G. Last Call on "Header Compression for IPv6" Cc: hinden@Ipsilon.COM, deering@cisco.com 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 : Header Compression for IPv6 Author(s) : M. Degermark, B. Nordgren, S. Pink Filename : draft-degermark-ipv6-hc-02.txt Pages : 45 Date : 11/25/1996 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two weeks from today, on 12/24/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 Tue Dec 10 22:26:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08443; Tue, 10 Dec 96 22:26:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08431; Tue, 10 Dec 96 22:25:43 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA13365; Tue, 10 Dec 1996 22:18:02 -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 WAA08256 for ; Tue, 10 Dec 1996 22:18:02 -0800 Received: from spruce.ipsilon.com (dialin2.Ipsilon.COM [205.226.3.242]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id WAA14736; Tue, 10 Dec 1996 22:18:00 -0800 Message-Id: <3.0.32.19961210175622.006cc4ec@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 10 Dec 1996 22:17:54 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 2580) W.G. Last Call on "Basic Socket Interface Extensions for IPv6" Cc: hinden@Ipsilon.COM, deering@cisco.com 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 Informational: 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 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two weeks from today, on 12/24/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 Tue Dec 10 22:27:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08451; Tue, 10 Dec 96 22:27:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08445; Tue, 10 Dec 96 22:26:45 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA13460; Tue, 10 Dec 1996 22:19:05 -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 WAA08411 for ; Tue, 10 Dec 1996 22:19:05 -0800 Received: from spruce.ipsilon.com (dialin2.Ipsilon.COM [205.226.3.242]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id WAA14731; Tue, 10 Dec 1996 22:17:58 -0800 Message-Id: <3.0.32.19961210174334.006cbeec@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 10 Dec 1996 22:17:52 -0800 To: jburgan@BayNetworks.com From: Bob Hinden Subject: (IPng 2582) Request to Advance "Generic Packet Tunneling in IPv6 Specification" Cc: scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a RFC with Proposed Standard status: Title : Generic Packet Tunneling in IPv6 Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-ipv6-tunnel-05.txt Pages : 36 Date : 11/27/1996 This version of the draft reflects comments received during the working group last call. It was discussed at the IPng w.g. session held at the Dec '96 IETF and the working group agreed to submit it to the IESG for Proposed Standard status. Bob Hinden / Steve Deering IPng Working Group Co-Chairs ------------------------------------------------------------------------------ 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 Dec 10 22:39:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08496; Tue, 10 Dec 96 22:39:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08490; Tue, 10 Dec 96 22:38:59 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA14549; Tue, 10 Dec 1996 22:31:17 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA10384 for ; Tue, 10 Dec 1996 22:31:16 -0800 Received: from inner.net (lust.inner.net [199.33.248.1]) by inner.net (8.8.2/42) with ESMTP id GAA00389; Wed, 11 Dec 1996 06:31:12 GMT Message-Id: <199612110631.GAA00389@inner.net> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com, deering@cisco.com Subject: (IPng 2583) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" In-Reply-To: Your message of "Tue, 10 Dec 1996 22:17:54 PST." <3.0.32.19961210175622.006cc4ec@mailhost.ipsilon.com> X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Wed, 11 Dec 1996 01:31:11 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <3.0.32.19961210175622.006cc4ec@mailhost.ipsilon.com>, you write: >This is an ipng working group last call for comments on advancing the >following document to Informational: > > 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 > >Please send substantive comments to the ipng mailing list, and minor >editorial comments to the authors. This last call period will end two >weeks from today, on 12/24/96. getnameinfo() needs a flag to say "give me the printable numeric form" (needed to efficiently implement the "-n" flag). -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 Tue Dec 10 22:40:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08503; Tue, 10 Dec 96 22:40:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08497; Tue, 10 Dec 96 22:40:14 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA14677; Tue, 10 Dec 1996 22:32:33 -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 WAA10534 for ; Tue, 10 Dec 1996 22:32:28 -0800 From: Masataka Ohta Message-Id: <199612110630.PAA09504@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA09504; Wed, 11 Dec 1996 15:30:34 +0900 Subject: (IPng 2584) Re: 8+8 (further discussion) To: jhalpern@us.newbridge.com (Joel Halpern) Date: Wed, 11 Dec 96 15:30:33 JST Cc: roque@di.fc.ul.pt, ipng@sunroof.eng.sun.com In-Reply-To: <9612110541.AA06159@lobster.nni>; from "Joel Halpern" at Dec 11, 96 12:41 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Joel; > On the other hand, I would agree with Pedro that allowing replacment of > the stored routing goop for an existing TCP connection clearly does > require authentication. Not necessarily. It is good enough to check that the Internet Locator part of source address is registered to DNS forward path of the source host. So, first, use the Internet ID part to know the host name, and then, lookup AAAA RR of the host. If the Internet Locator of incoming packets is not listed up in AAAA RR, it's a bogus packets. Masataka Ohta ------------------------------------------------------------------------------ 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 Dec 11 07:23:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08808; Wed, 11 Dec 96 07:23:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08802; Wed, 11 Dec 96 07:23:06 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA28376; Wed, 11 Dec 1996 07:15:24 -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 HAA16503 for ; Wed, 11 Dec 1996 07:15:20 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id QAA26458 for ; Wed, 11 Dec 1996 16:15:19 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA15575; Wed, 11 Dec 1996 16:15:14 +0100 Message-Id: <9612111515.AA15575@dxcoms.cern.ch> Subject: (IPng 2585) Re: 8+8 (further discussion) To: ipng@sunroof.eng.sun.com Date: Wed, 11 Dec 1996 16:15:14 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <199612110630.PAA09504@necom830.hpcl.titech.ac.jp> from "Masataka Ohta" at Dec 11, 96 03:30:33 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 Even more generally, wherever you get the new RG from must be a trusted source. If the source is DNS, it must be an authenicated DNS. Brian > > On the other hand, I would agree with Pedro that allowing replacment of > > the stored routing goop for an existing TCP connection clearly does > > require authentication. > > Not necessarily. > > It is good enough to check that the Internet Locator part of > source address is registered to DNS forward path of the source > host. > > So, first, use the Internet ID part to know the host name, and then, > lookup AAAA RR of the host. If the Internet Locator of incoming packets > is not listed up in AAAA RR, it's a bogus packets. > > Masataka Ohta > ------------------------------------------------------------------------------ > 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 Wed Dec 11 09:49:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08936; Wed, 11 Dec 96 09:49:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08476; Tue, 10 Dec 96 22:34:32 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA14079; Tue, 10 Dec 1996 22:26:51 -0800 Received: from lobster (lobster.corpeast.baynetworks.com [192.32.253.3]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA09721 for ; Tue, 10 Dec 1996 22:26:51 -0800 Received: from pobox.BayNetworks.com (pobox [192.32.151.199]) by lobster (SMI-8.6/SMI-SVR4) with SMTP id BAA19051; Wed, 11 Dec 1996 01:29:52 -0500 for Received: from sundance.engeast by pobox.BayNetworks.com (SMI-8.6/SMI-SVR4) id BAA21559; Wed, 11 Dec 1996 01:25:41 -0500 Received: by sundance.engeast (4.1/SMI-4.1) id AA01507; Wed, 11 Dec 96 01:25:41 EST Message-Id: <9612110625.AA01507@sundance.engeast> From: Jeffrey Burgan To: Bob Hinden Cc: jburgan@BayNetworks.COM, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Subject: (IPng 2586) Re: Request to Advance "Generic Packet Tunneling in IPv6 Specification" In-Reply-To: Your message of "Tue, 10 Dec 1996 22:17:52 PST." <3.0.32.19961210174334.006cbeec@mailhost.ipsilon.com> Date: Wed, 11 Dec 1996 01:25:40 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, > The chairs of the IP Next Generation working group, on behalf of the > working group, request that the following document be published as a RFC > with Proposed Standard status: > > Title : Generic Packet Tunneling in IPv6 Specification I'll process this. Thanks, Jeff ------------------------------------------------------------------------------ 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 Dec 11 13:59:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09423; Wed, 11 Dec 96 13:59:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09417; Wed, 11 Dec 96 13:59:02 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA24105; Wed, 11 Dec 1996 13:51:19 -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 NAA21570 for ; Wed, 11 Dec 1996 13:51:17 -0800 From: Masataka Ohta Message-Id: <199612112149.GAA10266@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA10266; Thu, 12 Dec 1996 06:49:29 +0900 Subject: (IPng 2587) Re: 8+8 (further discussion) To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Thu, 12 Dec 96 6:49:29 JST Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9612111515.AA15575@dxcoms.cern.ch>; from "Brian Carpenter CERN-CN" at Dec 11, 96 4:15 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian; > Even more generally, wherever you get the new RG > from must be a trusted source. If the source is DNS, > it must be an authenicated DNS. If you insists on having real security, yes. But, if we need weak security only, with which most of us are satisfied (or, at least, familiar) today, we don't need secure DNS. The reality today is that we are using weak security over weak DNS. Masataka Ohta ------------------------------------------------------------------------------ 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 Dec 11 15:36:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09566; Wed, 11 Dec 96 15:36:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09560; Wed, 11 Dec 96 15:36:40 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA15614; Wed, 11 Dec 1996 15:28:57 -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 PAA25245 for ; Wed, 11 Dec 1996 15:28:56 -0800 From: Masataka Ohta Message-Id: <199612112327.IAA11011@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA11011; Thu, 12 Dec 1996 08:27:04 +0900 Subject: (IPng 2588) Re: 8+8 (further discussion) To: roque@di.fc.ul.pt (Pedro Roque) Date: Thu, 12 Dec 96 8:27:04 JST Cc: crawdad@FNAL.GOV, ipng@sunroof.eng.sun.com In-Reply-To: <199612101921.TAA22502@oberon.di.fc.ul.pt>; from "Pedro Roque" at Dec 10, 96 7:21 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> Generally i can think of two strategies to change the DRG: - > >> Use the last value you received. - Use a "binding update" > >> scheme > >> > >> Both this situations will have to be authenticated. [...] > >> From a pratical perpective, every single comunication on the > >> internet will have to be authenticated for this to work. > > Matt> You learn the Dest. RG in the first place from DNS (if you > Matt> are the initiator). One could imagine checking for changes > Matt> through a secure DNS. > > Periodic checking ? > I don't think it would be a good idea. You want something that does > not force you to be constantly sending inquires... The changes should be initiated on periodically advertised RG announcements. Normal DNS may be consulted to see that the RG advertisement is not reliable (though unlikely). Masataka Ohta ------------------------------------------------------------------------------ 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 Dec 11 17:04:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09740; Wed, 11 Dec 96 17:04:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09734; Wed, 11 Dec 96 17:03:49 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA02978; Wed, 11 Dec 1996 16:56:07 -0800 Received: from gatekeeper.PDD.3Com.com (gatekeeper.pdd.3com.com [193.130.120.3]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA22733 for ; Wed, 11 Dec 1996 16:56:04 -0800 Received: from isolan.pdd.3com.com by gatekeeper.PDD.3Com.com; Thu, 12 Dec 1996 00:55:56 GMT From: Rob Pickering Message-Id: <10271.9612120053@zig.pdd.3com.com> Subject: (IPng 2589) Re: 8+8 (further discussion) To: mohta@necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 12 Dec 1996 00:53:38 +0000 (GMT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199612112327.IAA11011@necom830.hpcl.titech.ac.jp> from "Masataka Ohta" at Dec 12, 96 08:27:04 am X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masataka Ohta Said: > > > > > Periodic checking ? > > I don't think it would be a good idea. You want something that does > > not force you to be constantly sending inquires... > > The changes should be initiated on periodically advertised RG > announcements. Normal DNS may be consulted to see that the RG > advertisement is not reliable (though unlikely). Doesn't the idea of having RG announcements going all over the network to end stations re-introduce many of the problems that 8+8 is trying to solve? A better way to do this would be to have a router close to the bad RG destination return an ICMP unreachable "RG invalid" message which means, in effect, go and re-evaluate your RG for this ESD. This sort of brings me to a point about the 8+8 draft that I didn't really understand. All of the text about multihoming a site with providers arranging to tunnel to the alternate provider in case of link failure seemed to be less resilient than current multihome arrangements. It covers the case of one of the provider - subscriber links dropping out, but fails to address the main reason that people want this kind of service: to protect against complete failure of one of the provider's networks and (a secondary effect but as they are paying for two links) to load balance between providers. If the provider which owns your RG announcement has major problems then your packets won't get down the tunnel to your backup. It should be possible to return multiple DNS AAAA answers, one for each permutation of RG. A source would pick one of these as a destination, and on receipt of an "RG invalid" control message would fall down the list to try another one (which had RG via another provider). Is there some scaling problem here? I know that it means that 50% of connection attempts would fail at the first packet exchange and need to retry with different RG, but this is only two extra packets on the first exchange between a host pair where a transient failed path exists. Hopefully the record for the failed RG could be timed out of the DNS quickly to prevent persistence of this behaviour. -- Rob Pickering. ------------------------------------------------------------------------------ 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 Dec 11 18:20:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09848; Wed, 11 Dec 96 18:20:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09842; Wed, 11 Dec 96 18:20:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA15390; Wed, 11 Dec 1996 18:12:53 -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 RAA27427 for ; Wed, 11 Dec 1996 17:10:20 -0800 From: Masataka Ohta Message-Id: <199612120108.KAA11377@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA11377; Thu, 12 Dec 1996 10:08:39 +0900 Subject: (IPng 2590) Re: 8+8 (further discussion) To: rjp@pdd.3com.com (Rob Pickering) Date: Thu, 12 Dec 96 10:08:39 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <10271.9612120053@zig.pdd.3com.com>; from "Rob Pickering" at Dec 12, 96 12:53 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Pickering; > > The changes should be initiated on periodically advertised RG > > announcements. Normal DNS may be consulted to see that the RG > > advertisement is not reliable (though unlikely). > > Doesn't the idea of having RG announcements going all > over the network to end stations re-introduce many of the problems > that 8+8 is trying to solve? Sorry I don't know how RG's are propagated. But, what's wrong with accepting multiple RGs from all the providers? > A better way to do this would be to have a router close to the bad > RG destination return an ICMP unreachable "RG invalid" message which > means, in effect, go and re-evaluate your RG for this ESD. Isn't it enough that RGs from bad providers expire? > This sort of brings me to a point about the 8+8 draft that I didn't > really understand. Which draft? Mine or Mike's? Mike's current draft is no good for protection against the piracy, because it can't lookup DNS with ID part only. > All of the text about multihoming a site with > providers arranging to tunnel to the alternate provider in case of > link failure seemed to be less resilient than > current multihome arrangements. I agree. > If the provider which owns your RG announcement has major problems > then your packets won't get down the tunnel to your backup. > > It should be possible to return multiple DNS AAAA answers, > one for each permutation of RG. That's exactly what we must have (though we should better have some indirection mechanism for the locator). But it is necessary at the receiver side for the protecton against piracy, not at the sender side. Masataka Ohta ------------------------------------------------------------------------------ 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 Dec 12 03:29:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10322; Thu, 12 Dec 96 03:29:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10316; Thu, 12 Dec 96 03:29:03 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA27711; Thu, 12 Dec 1996 03:21:20 -0800 Received: from ec-unix-1.ec.co.za (ec-unix-1.ec.co.za [196.26.166.162]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA09497 for ; Thu, 12 Dec 1996 03:21:14 -0800 Received: from startrek ([196.26.166.164]) by ec-unix-1.ec.co.za (8.6.12/8.6.9) with SMTP id NAA00254 for ; Thu, 12 Dec 1996 13:23:55 +0200 Received: by startrek with Microsoft Mail id <01BBE82F.ED9284D0@startrek>; Thu, 12 Dec 1996 13:25:22 -0000 Message-Id: <01BBE82F.ED9284D0@startrek> From: Brendan Swart To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 2591) ipng - any working samples around for Linux. Date: Thu, 12 Dec 1996 13:25:21 -0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk HI all, We wish to build an IPng network here in our classroom, we have Linux, = NT 4 and Netware 4.1 servers. Does anyone know of where I might be able to get some software, so as = that we can begin with building our network. We are planning an IPv4 to = IPv6 course, and we want to include hands on sessions, but this won't = happen if we are unable to get some source for IPng. Regards Brendan Swart=09 (Lecturer for the International Institute for Research) ------------------------------------------------------------------------------ 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 Dec 12 07:38:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10589; Thu, 12 Dec 96 07:38:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10583; Thu, 12 Dec 96 07:38:42 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA17648; Thu, 12 Dec 1996 07:30:59 -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 HAA04625 for ; Thu, 12 Dec 1996 07:30:59 -0800 Received: from spruce.ipsilon.com (dialin5.Ipsilon.COM [205.226.3.245]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id HAA09506; Thu, 12 Dec 1996 07:30:24 -0800 Message-Id: <3.0.32.19961210224844.006cebe4@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 12 Dec 1996 07:29:50 -0800 To: iana@isi.edu From: Bob Hinden Subject: (IPng 2592) IPv6 Default Registration Cc: hinden@Ipsilon.COM, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear IANA, On behalf of the IPng working group of the IETF, we would like to request that the IANA add to its assigned numbers registry the following IPv6 value: Default Maximum "Hop Limit" with a value of 64 (decimal) The IPv6 "Hop Limit" is defined in RFC1884 as: 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero. This is similar to the max TTL value that is registered for IPv4. Regards, Bob Hinden / Steve Deering IPng Working Group Co-Chairs ------------------------------------------------------------------------------ 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 Dec 12 10:46:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10944; Thu, 12 Dec 96 10:46:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10938; Thu, 12 Dec 96 10:46:15 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA25622; Thu, 12 Dec 1996 10:38:30 -0800 Received: from ganymede.PDD.3Com.com (ganymede.pdd.3com.com [161.71.120.164]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA19167 for ; Thu, 12 Dec 1996 10:38:21 -0800 Message-Id: <8094.199612121837@ganymede.PDD.3Com.com> Received: from icarus.pdd.3com.com by ganymede.PDD.3Com.com; Thu, 12 Dec 1996 18:37:51 GMT Comments: Authenticated sender is From: "Rob Pickering" To: Masataka Ohta Date: Thu, 12 Dec 1996 09:41:58 -0800 Subject: (IPng 2593) Re: 8+8 (further discussion) Cc: ipng@sunroof.eng.sun.com Priority: normal X-Mailer: Pegasus Mail for Win32 (v2.42a) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masataka Ohta wrote: >[In reply to my comments]: > > Doesn't the idea of having RG announcements going all > > over the network to end stations re-introduce many of the problems > > that 8+8 is trying to solve? > > Sorry I don't know how RG's are propagated Well Mike's draft suggests that this happens via the DNS with RG records and AA records. > > A better way to do this would be to have a router close to the bad > > RG destination return an ICMP unreachable "RG invalid" message > > which means, in effect, go and re-evaluate your RG for this ESD. > > Isn't it enough that RGs from bad providers expire? No. Under the above scheme, this would mean that an end-station would need to keep polling the DNS AAAA record of a node it was talking to if it wanted to keep connections alive over a provider or, in the case of a multi-homed host, route change. This doesn't seem very efficient. In any case for the DNS to reflect changing RGs in a timely fashion, the RG (and hence the derived AAAA) would need to have a very short TTL. This is fine if it is being temporarily wound down because a provider switch is about to occur, but not good if all mutlihomed sites have to have permanently low TTLs such that much more DNS traffic gets generated. > > This sort of brings me to a point about the 8+8 draft that I > > didn't really understand. > > Which draft? Mine or Mike's? Sorry for the confusion, Mike's > Mike's current draft is no good for protection against the piracy, > because it can't lookup DNS with ID part only. Mike's draft doesn't talk at all about reverse lookup (PTR) records which would in any case be necessary. If you arrange to provide PTR records for all RG:ESD pairs that a host has e.g. host.dom.ain AAAA : host.dom.ain AAAA : and ..IP6.INT. PTR host.dom.ain. ..IP6.INT. PTR host.dom.ain. and a packet exchange is going on with : as the remote address. The route via dies and a host unreachable is received. The stack then does a DNS query for ..IP6.INT and gets host.dom.ain, which then forward resolves to the two AAAA records. : is ruled out because we know it is dead, so we substitute : and continue the conversation. This has some security as it will only use full addresses which are in the list of AAAA records for the host. -- Rob Pickering ------------------------------------------------------------------------------ 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 Dec 12 12:14:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11052; Thu, 12 Dec 96 12:14:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11046; Thu, 12 Dec 96 12:13:50 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA16775; Thu, 12 Dec 1996 12:06:07 -0800 Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA25341 for ; Thu, 12 Dec 1996 12:06:03 -0800 Message-Id: <199612122006.MAA25341@mercury.Sun.COM> Received: from RALVM6 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9990; Thu, 12 Dec 96 15:05:56 EST Date: Thu, 12 Dec 96 13:56:42 EST From: "Karen Tracey" To: rstevens@kohala.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2594) Re: updated sockets API: draft-ietf-ipngwg-bsd-api-06.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich Stevens wrote: > Sorry for the confusion--I should have added some "rationale" to the > last draft of the basic API when these appeared. Thanks for the explanation. I kind of assumed that was what was going on, I just wanted to make sure the differences were going to be resolved. > > Are there now two ways for a multicast application to specify > > the sending interface? "Basic" defines the IPV6_MULTICAST_IF > > setsockopt option, and "Advanced" defines an ancillary data > > method to do the same thing? Can a multicast application use > > either/both? If yes to both, what is the behavior if both are > > used (which one overrides the other)? > > Good question. My first guess is that the IPV6_MULTICAST_IF socket > option defines the default, in the application does not specify an > outgoing interface using ancillary data, else the ancillary data > overrides the socket option for just that output operation. Comments? Sounds good to me. I think it needs to be specified somewhere, though. Else I could see some implementations ignoring the ancillary data if IPV6_MULTICAST_IF had been specified earlier. Karen Tracey ------------------------------------------------------------------------------ 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 Dec 12 18:42:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11635; Thu, 12 Dec 96 18:42:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11629; Thu, 12 Dec 96 18:42:16 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA03152; Thu, 12 Dec 1996 18:34:33 -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 SAA09458 for ; Thu, 12 Dec 1996 18:34:32 -0800 Received: from spruce.ipsilon.com (dialin4.Ipsilon.COM [205.226.3.244]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id SAA06029; Thu, 12 Dec 1996 18:33:57 -0800 Message-Id: <3.0.32.19961212111459.006d0db8@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 12 Dec 1996 18:33:20 -0800 To: sob@harvard.edu From: Bob Hinden Subject: (IPng 2595) IPng Working Group Reply to the ITU Request Cc: ipng@sunroof.eng.sun.com, hinden@Ipsilon.COM, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott, Attached is the response from the IPng working group to the ITU request for an IPv6 address prefix. Robert Hinden IPng Working Group Document Editor ------------------------------------------------------------------------- Internet Engineering Task Force IP Next Generation Working Group December 11, 1996 Mr. H. V. Bartine AT&T Bell Labs, Room 4K-316 101 Crawfords Corner Road Holmdel, NJ 07733-3030 Subject: Response to ITU SG 7 Request for IPv6 Addressing Code Point The IETF received a request from ITU-Telecommunication Standardization Sector STUDY GROUP 17, Rapporteur Q3/7 on 17 July 1995. The ITU requested an IPv6 Format Prefix for X.121 Public Data Network Addresses. It also suggested that ITU-T Study Group 2 may also make a similar request for E.164 addresses. The IP Next Generation working group of the IETF discussed the request at the working group meeting held on June 24, 1996 in Montreal. The working group concluded that X.121 Public Network addresses are not Internetwork addresses and that a Format Prefix (code point) was not warranted at this time. Consequentially the working group concluded that a better approach would be to treat the X.121 addresses in a manner similar to how IPv6 runs other networks technologies such as Ethernet, FDDI, Token Ring, etc. A definition of interface identifiers from the X.121 addresses should be created. The BSD digits of the X.121 address would be converted to binary and used as an Interface Identifier. An IPv6 over X.121 Public Data Networks document could be written in a manner similar to RFC1972 "A Method for the Transmission of IPv6 Packets over Ethernet Networks" or RFC-2019 "Transmission of IPv6 Packets Over FDDI". This approach would be compatible with the IPv6 control functions as defined in RFC-1970 "Neighbor Discovery for IP Version 6 (IPv6)". It would also support the creation of small independent subnetworks (e.g., clouds) in the X.121 Public Data Networks instead a single very large subnetwork. At the working group meeting an alternative approach was also suggested that would make use of the AFI for X.121 addresses in the NSAP addressing plan. This would fit into the framework defined in RFC-1888 "OSI NSAPs and IPv6". This alternative provides another approach to support running IPv6 over public networks that use X.121 addressing. The IPng working group would also like to invite representatives from ITU-T SG7 to attend the next IETF meeting and to present the IP Next Generation working group their thoughts on how IPv6 could be run over the public data networks. We look forward to your response in this manner. Contact Person: Robert M. Hinden Ipsilon Networks, Inc. 232 Java Drive Sunnyvale, CA 94089 TEL: +1 408 990-2004 email: hinden@ipsilon.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 Thu Dec 12 19:56:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11733; Thu, 12 Dec 96 19:56:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11727; Thu, 12 Dec 96 19:55:54 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA10987; Thu, 12 Dec 1996 19:48:11 -0800 Received: from palrel1.hp.com (palrel1.hp.com [15.253.72.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA27362 for ; Thu, 12 Dec 1996 19:48:10 -0800 Received: from hpindlm.cup.hp.com (daemon@hpindlm.cup.hp.com [15.13.95.89]) by palrel1.hp.com with SMTP (8.7.5/8.7.3) id TAA14112 for ; Thu, 12 Dec 1996 19:48:09 -0800 (PST) Received: from localhost by hpindlm.cup.hp.com with SMTP (1.38.193.5/15.5+IOS 3.20+cup+OMrelay) id AA25141; Thu, 12 Dec 1996 19:48:07 -0800 Message-Id: <9612130348.AA25141@hpindlm.cup.hp.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2596) Last call for Basic Socket API Date: Thu, 12 Dec 1996 19:48:07 -0800 From: Erik Scoredos Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Howdy Jim, et al.: I believe that the wording in Section 4.3 "Socket Address Structure for 4.4BSD-Based Systems" on page 7 of draft-ietf-ipngwg-bsd-api-06.txt is inconsistent with POSIX 1003.1g/D6.5. Where the IPNG working group draft says: Note that the size of the sockaddr_in6 structure is larger than the size of the sockaddr structure. Applications that use the sockaddr_in6 structure need to be aware that they cannot use sizeof(sockaddr) to allocate a buffer to hold a sockaddr_in structure. They should use sizeof(sockaddr_in6) instead. Posix says in section 6.4.1.2.2 "The sockaddr structure": Note that the size of the sa_data element is unspecified, and its content and format depend on the address family. Applications that initialize a sockaddr structure must use a protocol-specific variant of this structure rather than a sockaddr structure. Could we remove the statement that the "sockaddr_in6 structure is larger than the size of the sockaddr structure?" Thanks, Eric Scoredos (rio@cup.hp.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 Thu Dec 12 21:12:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11895; Thu, 12 Dec 96 21:12:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11889; Thu, 12 Dec 96 21:11:51 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA18090; Thu, 12 Dec 1996 21:04:07 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA17539 for ; Thu, 12 Dec 1996 21:04:06 -0800 Received: from inner.net (lust.inner.net [199.33.248.1]) by inner.net (8.8.2/42) with ESMTP id DAA00689; Fri, 13 Dec 1996 03:58:14 GMT Message-Id: <199612130358.DAA00689@inner.net> To: Erik Scoredos Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2597) Re: Last call for Basic Socket API In-Reply-To: Your message of "Thu, 12 Dec 1996 19:48:07 PST." <9612130348.AA25141@hpindlm.cup.hp.com> X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Thu, 12 Dec 1996 22:58:13 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <9612130348.AA25141@hpindlm.cup.hp.com>, you write: >I believe that the wording in Section 4.3 "Socket Address Structure >for 4.4BSD-Based Systems" on page 7 of draft-ietf-ipngwg-bsd-api-06.txt >is inconsistent with POSIX 1003.1g/D6.5. > >Where the IPNG working group draft says: > > Note that the size of the sockaddr_in6 structure is larger than the > size of the sockaddr structure. Applications that use the > sockaddr_in6 structure need to be aware that they cannot use > sizeof(sockaddr) to allocate a buffer to hold a sockaddr_in > structure. They should use sizeof(sockaddr_in6) instead. > >Posix says in section 6.4.1.2.2 "The sockaddr structure": > > Note that the size of the sa_data element is unspecified, and > its content and format depend on the address family. Applications > that initialize a sockaddr structure must use a protocol-specific > variant of this structure rather than a sockaddr structure. > >Could we remove the statement that the "sockaddr_in6 structure >is larger than the size of the sockaddr structure?" Perhaps the text should read "... structure is typically larger ...". The statement in the API spec is mostly a warning, and a useful one IMO. -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 Fri Dec 13 05:29:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12079; Fri, 13 Dec 96 05:29:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12070; Fri, 13 Dec 96 05:29:12 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA23675; Fri, 13 Dec 1996 05:21:25 -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 FAA27896 for ; Fri, 13 Dec 1996 05:21:23 -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 GAA03973; Fri, 13 Dec 1996 06:21:22 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.3/8.8.3) id GAA27010; Fri, 13 Dec 1996 06:21:21 -0700 (MST) Message-Id: <199612131321.GAA27010@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Fri, 13 Dec 1996 06:21:21 -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: Craig Metz , Erik Scoredos Subject: (IPng 2598) Re: Last call for Basic Socket API Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Could we remove the statement that the "sockaddr_in6 structure > >is larger than the size of the sockaddr structure?" > > Perhaps the text should read "... structure is typically larger ...". > The statement in the API spec is mostly a warning, and a useful one IMO. Absolutely. Despite what Posix says, every implementation that I have seen allocates 16 bytes for a sockaddr structure, and I'll bet there is a bunch of code out there that assumes that a sockaddr_in structure fits in a sockaddr structure, and this will break with IPv6. I think the warning is justified. 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 Fri Dec 13 09:39:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12293; Fri, 13 Dec 96 09:39:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12287; Fri, 13 Dec 96 09:39:42 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA28988; Fri, 13 Dec 1996 09:31:56 -0800 Received: from snoopy.vetmed.auburn.edu (snoopy.vetmed.auburn.edu [131.204.122.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA15469 for ; Fri, 13 Dec 1996 09:31:57 -0800 Received: from griffon (griffon [131.204.122.53]) by snoopy.vetmed.auburn.edu (8.7.5/8.7.1) with SMTP id LAA13630; Fri, 13 Dec 1996 11:31:53 -0600 (CST) Message-Id: <199612131731.LAA13630@snoopy.vetmed.auburn.edu> X-Sender: birknmc@mailhost.vetmed.auburn.edu X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Dec 1996 11:32:12 -0600 To: ipng@sunroof.eng.sun.com From: "Matthias C.F. Birkner" Subject: (IPng 2599) Proposal for using the Flow Label Cc: Liam Murphy Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is the abstract from my Master's thesis, I would very much appreciate the group's thoughts on whether this proposal is worth pursuing. If anyone would like more information on the work, please let me know and I'll provide a fuller version. Thanks very much, Matt Birkner ABSTRACT In recent years the Internet has become increasingly popular. This increased popularity, combined with a broader range of applications, has revealed several shortcomings in the current version of the Internet Protocol, IPv4. In response the Internet community is developing the "next generation" of IP, IPv6. One of the new features of IPv6 is the ability to identify a stream of data within the Internet, making it possible to offer different qualities of service to different applications. A new protocol (the ImpRes protocol) is proposed in this thesis to take advantage of this ability by reserving network resources for a data stream ``on-the-fly". Using the IPv6 flow label field and a proposed IPv6 Hop-by-Hop option header field, a data stream can establish state information in network nodes, and adapt to changing network conditions or user requests by dynamically modifying the state information during the lifetime of the stream. Initial simulation results suggest that the proposed ImpRes protocol is a viable method for supporting better-than-best-effort services in an IPv6 environment. ------------------------------------------------------------------------------- Matthias C.F. Birkner birknmc@vetmed.auburn.edu Pathobiology Dept., Auburn University If they are the pillars of our community, we'd better keep a sharp eye on the roof. ------------------------------------------------------------------------------- ------------------------------------------------------------------------------ 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 Dec 13 11:49:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12503; Fri, 13 Dec 96 11:49:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12487; Fri, 13 Dec 96 11:42:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA27841; Fri, 13 Dec 1996 11:34:50 -0800 Received: from toysrus-bh.tru.com (toysrus-bh.tru.com [206.34.177.66]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA06542 for ; Fri, 13 Dec 1996 11:34:48 -0800 Received: (from uucp@localhost) by toysrus-bh.tru.com (8.6.12/8.6.11) id OAA16533 for ; Fri, 13 Dec 1996 14:35:03 -0500 Received: from news.tru.com by toysrus-bh.tru.com via smap (V1.3) id sma016508; Fri Dec 13 14:34:52 1996 Received: from msg01psp.tru.com by mailgate.tru.com; (5.65v3.2/1.1.8.2/21Mar96-0504PM) id AA04193; Fri, 13 Dec 1996 14:32:27 -0500 Received: by msg01psp.tru.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBE903.0C8DE4A0@msg01psp.tru.com>; Fri, 13 Dec 1996 14:36:38 -0500 Message-Id: From: "England, John" To: "'ipng@sunroof.eng.sun.com'" Cc: "Weinberg, Adam" Subject: (IPng 2600) FW: Notification: Inbound Mail Failure - Address not found Date: Fri, 13 Dec 1996 14:36:34 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The correct Internet address is weinbera2@toysrus.com >------------------- ( Toys R Us Postmaster ) -------------------- >John England tel: 201-331-2817 fax: 201-335-1639 >61 Walsh Dr, Parsippany NJ 07054 INTERNET: englandj@toysrus.com >---------- From: System Administrator[SMTP:postmaster@toysrus.com] >Sent: Thursday, December 12, 1996 7:33 PM >To: Postmaster >Subject: Notification: Inbound Mail Failure - Address not found > >A mail message was not sent because the following address(es) could not be >found: > > WeinbergA@toysrus.com > >The message that caused this notification was: > > To: ; ; > ; ; ; > ; ; ; > ; ; > ; ; > ; ; ; > ; ; ; > ; > From: > Subject: Perfect Joke > > > ------------------------------------------------------------------------------ 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 Dec 16 05:26:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15068; Mon, 16 Dec 96 05:26:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15062; Mon, 16 Dec 96 05:26:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA08927; Mon, 16 Dec 1996 05:18:45 -0800 Received: from mailhub.axion.bt.co.uk (bt-sys.bt.co.uk [132.146.5.4]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA11690 for ; Mon, 16 Dec 1996 05:18:46 -0800 Received: from gideon.bt.co.uk (actually gideon.bt-sys.bt.co.uk) by mailhub.axion.bt.co.uk with SMTP (PP); Mon, 16 Dec 1996 11:11:05 +0000 Received: from localhost by gideon.bt.co.uk (5.x/SMI-SVR4) id AA29570; Mon, 16 Dec 1996 11:06:42 GMT Date: Mon, 16 Dec 1996 11:06:41 +0000 (GMT) From: George Tsirtsis To: ipng@sunroof.eng.sun.com Subject: (IPng 2601) Archive gelp Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I know that some time ago you had a conversation about IPv4 to IPv6 Address Translators were you rejected the idea. Could you please tell me in which month/year that debate took place so I can send a request to the mailing list? Thanks George ------------------------------------------------------------------------------ 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 Dec 16 06:13:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15099; Mon, 16 Dec 96 06:13:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15093; Mon, 16 Dec 96 06:12:58 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA12041; Mon, 16 Dec 1996 06:05:09 -0800 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA21286 for ; Mon, 16 Dec 1996 06:05:06 -0800 Received: from matisse.ibp.fr (matisse.ibp.fr [132.227.61.26]) by ibp.ibp.fr (8.8.4/jtpda-5.2) with SMTP id PAA27629 ; Mon, 16 Dec 1996 15:04:17 +0100 (MET) Date: Mon, 16 Dec 1996 15:04:17 +0100 (MET) Message-Id: <199612161404.PAA27629@ibp.ibp.fr> X-Sender: eh@hera.ibp.fr X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Matthias C.F. Birkner" , ipng@sunroof.eng.sun.com From: "Eric HORLAIT (MASI-CNRS)" Subject: (IPng 2602) Re: Proposal for using the Flow Label Cc: Liam Murphy Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:32 13/12/96 -0600, Matthias C.F. Birkner wrote: > This is the abstract from my Master's thesis, I would very much > appreciate the group's thoughts on whether this proposal is worth > pursuing. If anyone would like more information on the work, please > let me know and I'll provide a fuller version. > > Thanks very much, > Matt Birkner > I'm interested in knowing about your thesis. First "natural" question in this context: what is your feeling about RSVP? relationship with ImpRes? You spoke about simulation results; did you try some implementations? Eric ---------------------- Professeur Eric HORLAIT ------------------------ Universite Pierre et Marie Curie Tel: 33-1-44-27-73-83 Institut Blaise Pascal - Labo MASI Fax: 33-1-44-27-62-86 4, place Jussieu e-mail: Eric.Horlait@masi.ibp.fr 75252 PARIS Cedex 05 Telex: UPMCSIX 200-145 F http://www-masi-net.ibp.fr/~eh ----------------------------------------------------------------------- ------------------------------------------------------------------------------ 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 Dec 16 10:18:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15562; Mon, 16 Dec 96 10:18:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15556; Mon, 16 Dec 96 10:18:04 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA22752; Mon, 16 Dec 1996 10:10:14 -0800 Received: from snoopy.vetmed.auburn.edu (snoopy.vetmed.auburn.edu [131.204.122.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA00558 for ; Mon, 16 Dec 1996 10:09:59 -0800 Received: from griffon (griffon [131.204.122.53]) by snoopy.vetmed.auburn.edu (8.7.5/8.7.1) with SMTP id MAA10262; Mon, 16 Dec 1996 12:08:32 -0600 (CST) Message-Id: <199612161808.MAA10262@snoopy.vetmed.auburn.edu> X-Sender: birknmc@mailhost.vetmed.auburn.edu X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Dec 1996 12:08:42 -0600 To: "Eric HORLAIT (MASI-CNRS)" , ipng@sunroof.eng.sun.com From: "Matthias C.F. Birkner" Subject: (IPng 2603) Re: Proposal for using the Flow Label Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 03:04 PM 12/16/96 +0100, you wrote: [snip] > >I'm interested in knowing about your thesis. I've made the thesis available in postscript form from both my homepage (www.vetmed.auburn.edu/~birknmc) and my resume page (www.vetmed.auburn.edu/~birknmc/resume.html). If you have trouble getting it that way let me know and we'll come up with a "plan B". :) >First "natural" question in this context: what is your feeling about RSVP? >relationship with ImpRes? I believe that ImpRes is compatible with RSVP. It's certainly not intended as a replacement. I did not see any discussion of data-transport mechanisms while I was reading the RSVP specs (though there may have been some since then) and so feel that ImpRes could be one method to provide that transportation. I have not pursued this yet though so I'm not sure what modifications, if any, would be required. > You spoke about simulation results; did you try >some implementations? So far we've only done simulations, and there's some expansion that needs to be done there before I'll be comfortable doing an implementation. I'm hoping to continue working on the proposal after the holidays so maybe we'll be able to get to the implementation stage before too much longer. :) Let me know if I can provide any further information. Matt ------------------------------------------------------------------------------- Matthias C.F. Birkner birknmc@vetmed.auburn.edu Pathobiology Dept., Auburn University If they are the pillars of our community, we'd better keep a sharp eye on the roof. ------------------------------------------------------------------------------- ------------------------------------------------------------------------------ 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 Dec 16 10:46:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15617; Mon, 16 Dec 96 10:46:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14874; Mon, 16 Dec 96 01:45:17 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA27461; Mon, 16 Dec 1996 01:37:28 -0800 Received: from bimota.imada.math.human.nagoya-u.ac.jp (gshi2.info.human.nagoya-u.ac.jp [133.6.144.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA11453 for ; Mon, 16 Dec 1996 01:37:22 -0800 Received: from bimota.imada.math.human.nagoya-u.ac.jp (localhost [127.0.0.1]) by bimota.imada.math.human.nagoya-u.ac.jp (8.7.5/3.4W2) with ESMTP id SAA03220; Mon, 16 Dec 1996 18:34:12 +0900 (JST) Message-Id: <199612160934.SAA03220@bimota.imada.math.human.nagoya-u.ac.jp> To: rstevens@kohala.com Cc: kmt@vnet.ibm.com, ipng@sunroof.eng.sun.com Subject: (IPng 2604) Re: updated sockets API: draft-ietf-ipngwg-bsd-api-06.txt Reply-To: koji@math.human.nagoya-u.ac.jp In-Reply-To: Your message of "Mon, 9 Dec 1996 13:51:50 -0700" References: <199612092051.NAA20527@kohala.kohala.com> X-Mailer: Mew version 1.54 on Emacs 19.28.3, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Dec 1996 18:33:54 +0900 From: Koji Imada - je4owb/2 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> ">" == W Richard Stevens writes: >> Yes. The interface ID stuff first appeared in the advanced API, as we >> needed it for received interface and outgoing interface. Then a few >> weeks ago on this list Steve Deering mentioned that if he had a chance >> to redo the multicasting interface he would specify the interface with >> some form of identifier and not with the local IP address, since some >> interfaces have no IP address. We then moved the interface ID stuff >> into from the advanced to the basic API. It will be removed from the >> next draft of the advanced API. The interface ID stuff appearing in basic API, Why Interface to bound address mapping functions don't? How can I decide which interface to use for multicast and others(some with advanced API). I think way to get Interface information(such as address) should be in basic API. I must use ioctl's to get information of interfaces if such functions are not part of basic API. Is this wrong or unnecessary? Adding functions to get/set All information about interfaces to basic API will be another problem. But "basic" information of interface should be obtained with basic API if there is interface ID stuff. How about this? -- Koji Imada - je4owb/2 koji@math.human.nagoya-u.ac.jp ------------------------------------------------------------------------------ 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 Dec 16 10:52:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15676; Mon, 16 Dec 96 10:52:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14901; Mon, 16 Dec 96 01:57:17 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA28076; Mon, 16 Dec 1996 01:49:28 -0800 Received: from bimota.imada.math.human.nagoya-u.ac.jp (gshi2.info.human.nagoya-u.ac.jp [133.6.144.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA13004 for ; Mon, 16 Dec 1996 01:49:24 -0800 Received: from bimota.imada.math.human.nagoya-u.ac.jp (localhost [127.0.0.1]) by bimota.imada.math.human.nagoya-u.ac.jp (8.7.5/3.4W2) with ESMTP id SAA03770; Mon, 16 Dec 1996 18:46:42 +0900 (JST) Message-Id: <199612160946.SAA03770@bimota.imada.math.human.nagoya-u.ac.jp> To: hinden@ipsilon.com Cc: jburgan@baynetworks.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Subject: (IPng 2605) Re: Request to Advance "Generic Packet Tunneling in IPv6Specification" Reply-To: koji@math.human.nagoya-u.ac.jp In-Reply-To: Your message of "Tue, 10 Dec 1996 22:17:52 -0800" References: <3.0.32.19961210174334.006cbeec@mailhost.ipsilon.com> X-Mailer: Mew version 1.54 on Emacs 19.28.3, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Dec 1996 18:46:27 +0900 From: Koji Imada - je4owb/2 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Why "Tunnel Encapsulation Limit" option is destination option in 4.1.1 in draft-ietf-ipngwg-ipv6-tunnel-05.txt? I think it is appropriate for hop-by-hop option if highest-order 2 bits of option type is set to 00. It may be slight performance loss on router other than tunnel entry-point node. But I can't understand reason to make exception for option processing rule. -- Koji Imada - je4owb/2 koji@math.human.nagoya-u.ac.jp ------------------------------------------------------------------------------ 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 Dec 16 14:22:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16423; Mon, 16 Dec 96 14:22:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16417; Mon, 16 Dec 96 14:22:33 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA24960; Mon, 16 Dec 1996 14:14:43 -0800 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA28017 for ; Mon, 16 Dec 1996 14:14:43 -0800 Received: from twinkie.agile.com by relay2.UU.NET with SMTP (peer crosschecked as: twinkie.agile.com [198.3.104.2]) id QQbujw06959; Mon, 16 Dec 1996 17:14:13 -0500 (EST) Received: from moonpie.agile.com by twinkie.agile.com with SMTP (1.37.109.8/16.2.TW) id AA13786; Mon, 16 Dec 1996 17:12:37 -0500 Received: from aconta.agile.com ([198.3.105.52]) by moonpie.agile.com (4.1/SMI-4.1) id AA14992; Mon, 16 Dec 96 17:12:30 EST Received: by aconta.agile.com with Microsoft Mail id <01BBEBD9.3CFC0300@aconta.agile.com>; Tue, 17 Dec 1996 05:14:54 -0500 Message-Id: <01BBEBD9.3CFC0300@aconta.agile.com> From: Alex Conta To: "hinden@ipsilon.com" , "'koji@math.human.nagoya-u.ac.jp'" Cc: "jburgan@baynetworks.com" , "scoya@cnri.reston.va.us" , "deering@cisco.com" , "ipng@sunroof.Eng.Sun.COM" Subject: (IPng 2606) Re: Request to Advance "Generic Packet Tunneling in IPv6Specification" Date: Mon, 16 Dec 1996 17:14:25 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As far as the performance penalty of a hop by hop header, such a header takes or forces a packet from the "fast path" to the "slow path" in a router. This may imply switching a packet's processing between two different engines, so the performance penalty is higher than just the cost of processing an additional header in the same engine. The information carried by the "tunnel encapsulation limit" option is relevant to tunnel end nodes, not to tunnel intermediate nodes - a tunnel may have many intermediate nodes - which is why a "hop by hop" header is not considered an appropriate place for the option. A destination header carrying the "tunnel encapsulation limit" is processed by the end nodes of a tunnel (and its inner tunnels if they exist). Alex Conta ---------- From: owner-ipng@sunroof.Eng.Sun.COM[SMTP:owner-ipng@sunroof.Eng.Sun.COM] Sent: Monday, December 16, 1996 4:46 AM To: hinden@ipsilon.com Cc: jburgan@baynetworks.com; scoya@cnri.reston.va.us; deering@cisco.com; ipng@sunroof.Eng.Sun.COM Subject: (IPng 2605) Re: Request to Advance "Generic Packet Tunneling in IPv6Specification" Why "Tunnel Encapsulation Limit" option is destination option in 4.1.1 in draft-ietf-ipngwg-ipv6-tunnel-05.txt? I think it is appropriate for hop-by-hop option if highest-order 2 bits of option type is set to 00. It may be slight performance loss on router other than tunnel entry-point node. But I can't understand reason to make exception for option processing rule. -- Koji Imada - je4owb/2 koji@math.human.nagoya-u.ac.jp ------------------------------------------------------------------------------ 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 Mon Dec 16 17:32:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16884; Mon, 16 Dec 96 17:32:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16878; Mon, 16 Dec 96 17:31:49 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA08469; Mon, 16 Dec 1996 17:24:00 -0800 Received: from docws001.shl.com (docws001.shl.com [159.249.56.252]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id RAA16962 for ; Mon, 16 Dec 1996 17:23:59 -0800 Received: from dalmsdoc02.shl.com (dalmsdoc02.shl.com [159.249.142.248]) by docws001.shl.com (8.7.3/8.7.3) with SMTP id TAA112394 for ; Mon, 16 Dec 1996 19:25:04 -0600 Received: by dalmsdoc02.shl.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BBEB87.06F9B100@dalmsdoc02.shl.com>; Mon, 16 Dec 1996 19:26:25 -0600 Message-Id: X-Ms-Tnef-Correlator: From: MEHRFAR Eddie To: "'ipng@sunroof.Eng.Sun.COM'" Subject: (IPng 2607) Re: Last call for Basic Socket API Date: Mon, 16 Dec 1996 19:12:33 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 10 TEXT, 34 UUENCODE X-Ms-Attachment: WINMAIL.DAT 0 00-00-1980 00:00 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Has anybody done any work related to multi-media in IPv6??. Can you please refer me to any documentation (RFC, etc.) with regard to IPv6 specs for multi-media?? Thanks. K. Eddie Mehrfar MCI Systemhouse begin 600 WINMAIL.DAT M>)\^(AH!`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <` M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`0F `0`A````,D4W-# V M1#9%,48Y0T8Q,3@R1D4P,#@P-48U0S5#,40`/P19L#``<0I0```!X`"! !````90```$A!4T%.64)/1%E$3TY% M04Y95T]22U)%3$%414143TU53%1)+4U%1$E!24Y)4%8V/S]#04Y93U503$5! M4T52149%4DU%5$]!3EE$3T-5345.5$%424].*%)&0RQ%5$,I5TE42%(````` M`P`0$ `````#`!$0``````(!"1 !````F $``)0!``"M`@``3%I&=3=/. * "H$-L0M@;F0;@4&1Y(&0"(&4@PB"R=P6P:R :8 M@= F `"!T;R!M=6QT5&DM M!X!D!S @"X @`$E0=C8_/RX@KB *A1C@`Z!Y"& @"U#N92"@(8 :8&8$D"+0 M(8#G(K$AHB%08W4'@ (P%^ ":0(@("A21D,L8B 2`&,N*2'0&1!H'2(A9PL1 M(J(CTB!S<'\%D 0@`A F`2+X)! *A53A$N[`0,`#33]/P``'@`]``$````%````4D4Z M( `````+`"D``0````L`(P```````@%_``$````]````/&,]55,E83U-0TDE M<#U32$PE;#U32$PO55-!5S P,2\P,# P,C(U1$!D86QM Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16936; Mon, 16 Dec 96 18:12:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16930; Mon, 16 Dec 96 18:12:06 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA14872; Mon, 16 Dec 1996 18:04:17 -0800 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA01664 for ; Mon, 16 Dec 1996 18:04:17 -0800 Received: from scooby-doo.cisco.com ([171.68.53.29]) by lint.cisco.com (8.6.12/CISCO.SERVER.1.1) with SMTP id SAA08766; Mon, 16 Dec 1996 18:04:07 -0800 Message-Id: <3.0.32.19961216210402.0069e108@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 16 Dec 1996 21:04:07 -0500 To: George Tsirtsis From: Paul Ferguson Subject: (IPng 2608) Re: Archive gelp 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 don't believe it was an issue of anyone specifically rejecting the idea, per se, but rather that the IPng/NGTRANS working group(s) deciding that the transition methodology which was preferable was to run dual IPv4/IPv6 stacks during the transition process. This is not to say that an IPv4/IPv6 NAT device would not be a nifty gadget, just trying to highlight what I believe to be the situation. :-) - paul At 11:06 AM 12/16/96 +0000, George Tsirtsis wrote: >Hello, > >I know that some time ago you had a conversation about IPv4 to IPv6 >Address Translators were you rejected the idea. Could you please tell me >in which month/year that debate took place so I can send a request to the >mailing list? > >Thanks >George > ------------------------------------------------------------------------------ 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 Dec 16 20:55:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17014; Mon, 16 Dec 96 20:55:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17008; Mon, 16 Dec 96 20:55:23 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA01897; Mon, 16 Dec 1996 20:47:32 -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 UAA05597 for ; Mon, 16 Dec 1996 20:47:33 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA30235; Mon, 16 Dec 1996 23:38:58 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14113; Mon, 16 Dec 1996 23:38:56 -0500 Message-Id: <9612170438.AA14113@wasted.zk3.dec.com> To: Paul Ferguson Cc: George Tsirtsis , ipng@sunroof.eng.sun.com Subject: (IPng 2609) Re: Archive gelp In-Reply-To: Your message of "Mon, 16 Dec 96 21:04:07 EST." <3.0.32.19961216210402.0069e108@lint.cisco.com> Date: Mon, 16 Dec 96 23:38:55 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just a nit... I have to now do Tech Direction type presentations to engineers for IPv6 and for customers sometimes (not a lot of folks know it yet) and I use two words exclusively avoiding two others. 1. Hybrid Stack not Dual. 2. IPv4/IPv6 Interoperation not Transition (Coexistence is so so). I find people get the wrong idea about a dual stack at least on my host. Its like integrated and a "hybrid". Most other implementors I know did the same thing on Hosts. I find people freak when they hear transition and on Intranets IPv4 will not disappear before I leave this insane business and go live in the mountains so I say "interoperation". p.s. I am working on response to last renumbering question but have to check a few places I know there is a problem and don't look at it every day in our setup scripts when they install the OS. /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 Dec 17 03:20:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17219; Tue, 17 Dec 96 03:20:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17213; Tue, 17 Dec 96 03:20:38 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA03971; Tue, 17 Dec 1996 03:12: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 DAA11157 for ; Tue, 17 Dec 1996 03:12:47 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id MAA15522 for ; Tue, 17 Dec 1996 12:12:45 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA26467; Tue, 17 Dec 1996 12:12:45 +0100 Message-Id: <9612171112.AA26467@dxcoms.cern.ch> Subject: (IPng 2610) Re: Archive gelp To: ipng@sunroof.eng.sun.com Date: Tue, 17 Dec 1996 12:12:45 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <3.0.32.19961216210402.0069e108@lint.cisco.com> from "Paul Ferguson" at Dec 16, 96 09:04:07 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 We specifically set aside further discussion of *packet* translation at an early stage in the discusssion of the transition (a.k.a. coexistence) models. We never discussed IPv4/IPv6 NAT and I can't attach any meaning to the phrase. This belongs on the ngtrans list. Brian Carpenter >--------- Text sent by Paul Ferguson follows: > > I don't believe it was an issue of anyone specifically rejecting the idea, > per se, but rather that the IPng/NGTRANS working group(s) deciding that > the transition methodology which was preferable was to run dual IPv4/IPv6 > stacks during the transition process. > > This is not to say that an IPv4/IPv6 NAT device would not be a nifty > gadget, just trying to highlight what I believe to be the situation. :-) > > - paul > > At 11:06 AM 12/16/96 +0000, George Tsirtsis wrote: > > >Hello, > > > >I know that some time ago you had a conversation about IPv4 to IPv6 > >Address Translators were you rejected the idea. Could you please tell me > >in which month/year that debate took place so I can send a request to the > >mailing list? > > > >Thanks > >George > > > > ------------------------------------------------------------------------------ > 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 Dec 17 09:22:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17537; Tue, 17 Dec 96 09:22:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17379; Tue, 17 Dec 96 07:57:14 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA26772; Tue, 17 Dec 1996 07:49:23 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA21274 for ; Tue, 17 Dec 1996 07:49:23 -0800 Received: from ietf.ietf.org by ietf.org id aa26927; 17 Dec 96 9:38 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: (IPng 2611) I-D ACTION:draft-ietf-ipngwg-ipv6-tunnel-06.txt Date: Tue, 17 Dec 1996 09:38:45 -0500 Message-Id: <9612170938.aa26927@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-06.txt Pages : 36 Date : 12/16/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-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-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-ipv6-tunnel-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: <19961217092859.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-tunnel-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961217092859.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 Tue Dec 17 10:42:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19060; Tue, 17 Dec 96 10:42:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19054; Tue, 17 Dec 96 10:42:32 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA02092; Tue, 17 Dec 1996 10:34:38 -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 KAA01100 for ; Tue, 17 Dec 1996 10:34:26 -0800 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id KAA28915; Tue, 17 Dec 1996 10:34:17 -0800 Message-Id: <3.0.32.19961217091733.006d6d30@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 17 Dec 1996 10:33:36 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 2612) W.G. Last Call on "IPv6 Router Alert Option" Cc: hinden@Ipsilon.COM, deering@cisco.com 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 : IPv6 Router Alert Option Author(s) : D. Katz, R. Atkinson Filename : draft-ietf-ipngwg-ipv6router-alert-00.txt Pages : 4 Date : 11/18/1996 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two weeks from today, on 12/31/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 Tue Dec 17 12:45:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19187; Tue, 17 Dec 96 12:45:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19181; Tue, 17 Dec 96 12:45:09 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA28786; Tue, 17 Dec 1996 12:37:18 -0800 Received: from malmo.trab.se (malmo.trab.se [131.115.48.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA21771 for ; Tue, 17 Dec 1996 12:37:16 -0800 Received: (from root@localhost) by malmo.trab.se (8.7.5/TRAB-primary-1) id VAA23429 for ipng@sunroof.eng.sun.com; Tue, 17 Dec 1996 21:37:13 +0100 (MET) Message-Id: <199612172037.VAA23429@malmo.trab.se> X400-Received: by mta trab.se in /c=SE/admd=400net/prmd=Telia/; converted ( (1)(0)(10021)(7)(1)(0)(6)(6), (1)(0)(10021)(7)(1)(0)(6)(1)); Relayed; 17 Dec 1996 21:37:09 +0100 X400-Received: by /c=SE/admd=400net/prmd=Telia/; converted ( (1)(0)(10021)(7)(1)(0)(6)(6), (1)(0)(10021)(7)(1)(0)(6)(1)); Relayed; 17 Dec 1996 21:37:09 +0100 X400-Received: by /c=se/admd=400net/prmd=mailbus/; Relayed; 17 Dec 1996 21:38:36 +0100 X400-Mts-Identifier: [/c=se/admd=400net/prmd=mailbus/; 850855117] Content-Return: Allowed X400-Content-Type: P2-1988 ( 22 ) Conversion: Allowed Original-Encoded-Information-Types: (1)(0)(10021)(7)(1)(0)(6), (1)(0)(10021)(7)(1)(0)(1) Priority: normal Disclose-Recipients: Prohibited Alternate-Recipient: Allowed X400-Originator: Gunnar.N.Bostrom@telia.se X400-Recipients: non-disclosure; Sensitivity: Company-Confidential Date: 17 Dec 1996 21:38:36 +0100 From: Gunnar Bostrom To: ipng@sunroof.eng.sun.com (Reply requested) Subject: (IPng 2613) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk unsubsrcibe ipng ------------------------------------------------------------------------------ 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 Dec 17 19:31:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19826; Tue, 17 Dec 96 19:31:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19820; Tue, 17 Dec 96 19:31:08 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA14060; Tue, 17 Dec 1996 19:23:17 -0800 Received: from palrel3.hp.com (palrel3.hp.com [15.253.88.10]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA10257 for ; Tue, 17 Dec 1996 19:23:17 -0800 Received: from hpindlm.cup.hp.com (daemon@hpindlm.cup.hp.com [15.13.95.89]) by palrel3.hp.com with SMTP (8.7.5/8.7.3) id TAA27988 for ; Tue, 17 Dec 1996 19:22:05 -0800 (PST) Received: from localhost by hpindlm.cup.hp.com with SMTP (1.38.193.5/15.5+IOS 3.20+cup+OMrelay) id AA19487; Tue, 17 Dec 1996 19:22:00 -0800 Message-Id: <9612180322.AA19487@hpindlm.cup.hp.com> To: "W. Richard Stevens" Cc: Craig Metz , ipng@sunroof.eng.sun.com Subject: (IPng 2614) Re: Last call for Basic Socket API In-Reply-To: Your message of "Fri, 13 Dec 1996 06:21:21 MST." <199612131321.GAA27010@kohala.kohala.com> Date: Tue, 17 Dec 1996 19:21:59 -0800 From: Erik Scoredos Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >Could we remove the statement that the "sockaddr_in6 structure > > >is larger than the size of the sockaddr structure?" > > > > Perhaps the text should read "... structure is typically larger ...". > > The statement in the API spec is mostly a warning, and a useful one IMO. > Absolutely. Despite what Posix says, every implementation that I have > seen allocates 16 bytes for a sockaddr structure, and I'll bet there > is a bunch of code out there that assumes that a sockaddr_in structure > fits in a sockaddr structure, and this will break with IPv6. I think > the warning is justified. > Rich Stevens Since no one else is jumping in here, I guess I'll have to, sigh. I agree entirely with the warning; I think that it's essential. The problem I see is referring implicitly to an implementation specific sizeof the sockaddr. IMO, Posix is asserting that the sockaddr is a protocol-independent structure whose representation is implementation dependent. It could be the sizeof sockaddr_in, but it could also be sizeof sockaddr_in6, or some other arbitrary size. Otherwise, it would not be protocol-independent. We should be wary of references to specific implementations such as 4.x BSD where they are not necessary. You cannot use the construct sizeof(sockaddr), by rule, not because the new sockaddr_in6 is bigger than the 4.3 BSD socket.h implementation of sockaddr. Afterall, it's improper to use sizeof(sockaddr) for IPv4 applications. Can't we just say something like: Note that the sockaddr is a protocol-independent structure. Applications that use the sockaddr_in6 structure need to be aware that they cannot use sizeof(sockaddr) to allocate a buffer to hold a sockaddr_in structure. They should use sizeof(sockaddr_in6) instead. Salute, 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 Tue Dec 17 22:01:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19898; Tue, 17 Dec 96 22:01:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19892; Tue, 17 Dec 96 22:01:44 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA25114; Tue, 17 Dec 1996 21:53:54 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA04765 for ; Tue, 17 Dec 1996 21:53:52 -0800 Received: from inner.net (lust.inner.net [199.33.248.1]) by inner.net (8.8.2/42) with ESMTP id EAA00750; Wed, 18 Dec 1996 04:34:52 GMT Message-Id: <199612180434.EAA00750@inner.net> To: Erik Scoredos Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2615) Re: Last call for Basic Socket API In-Reply-To: Your message of "Tue, 17 Dec 1996 19:21:59 PST." <9612180322.AA19487@hpindlm.cup.hp.com> X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Tue, 17 Dec 1996 23:34:51 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <9612180322.AA19487@hpindlm.cup.hp.com>, you write: >Can't we just say something like: > > Note that the sockaddr is a protocol-independent structure. > Applications that use the sockaddr_in6 structure need to be aware > that they cannot use sizeof(sockaddr) to allocate a buffer to hold > a sockaddr_in structure. They should use sizeof(sockaddr_in6) instead. I'd omit the first sentence, the rest sounds OK to me. -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 Wed Dec 18 01:54:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20077; Wed, 18 Dec 96 01:54:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20071; Wed, 18 Dec 96 01:54:26 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA11053; Wed, 18 Dec 1996 01:46:34 -0800 Received: from mailhub.axion.bt.co.uk (mailhub.axion.bt.co.uk [132.146.5.4]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA17900 for ; Wed, 18 Dec 1996 01:46:32 -0800 Received: from gideon.bt.co.uk (actually gideon.bt-sys.bt.co.uk) by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 18 Dec 1996 09:42:07 +0000 Received: from localhost by gideon.bt.co.uk (5.x/SMI-SVR4) id AA02811; Wed, 18 Dec 1996 09:37:22 GMT Date: Wed, 18 Dec 1996 09:37:22 +0000 (GMT) From: George Tsirtsis To: bound@zk3.dec.com Cc: Paul Ferguson , George Tsirtsis , ipng@sunroof.eng.sun.com Subject: (IPng 2616) Re: Archive gelp In-Reply-To: <9612170438.AA14113@wasted.zk3.dec.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 16 Dec 1996 bound@zk3.dec.com wrote: > Just a nit... I have to now do Tech Direction type presentations to > engineers for IPv6 and for customers sometimes (not a lot of folks know > it yet) and I use two words exclusively avoiding two others. > > 1. Hybrid Stack not Dual. > 2. IPv4/IPv6 Interoperation not Transition (Coexistence is so so). > > I find people get the wrong idea about a dual stack at least on my host. > Its like integrated and a "hybrid". Most other implementors I know did > the same thing on Hosts. When you say "hybrid" what exactly do you mean? Is it like a dos/linux system where you have to reboot the machine in order to go from the one to the other, or you have both IPv4 and IPv6 running on the same time and a mechanism that understands when to use the one and when the other? > I find people freak when they hear transition and on Intranets IPv4 will > not disappear before I leave this insane business and go live in the > mountains so I say "interoperation". O.K. you say it! But do you really mean it? :) > p.s. I am working on response to last renumbering question but have to > check a few places I know there is a problem and don't look at it every > day in our setup scripts when they install the OS. > > /jim George Tsirtsis -------------------------------------------------------------------------- Network Research Tel : 0044-1473-640756 BT Labs Fax : 0044-1473-640709 Ipswich e-mail: george@gideon.bt.co.uk --------The views in this message are mine and mine only--------- -------------------------------------------------------------------------- ------------------------------------------------------------------------------ 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 Dec 18 02:23:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20123; Wed, 18 Dec 96 02:23:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20117; Wed, 18 Dec 96 02:23:36 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA13347; Wed, 18 Dec 1996 02:15:44 -0800 Received: from horus.imag.fr (horus.imag.fr [129.88.38.2]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id CAA21558 for ; Wed, 18 Dec 1996 02:15:27 -0800 Received: (from richier@localhost) by horus.imag.fr (8.8.1/8.6.9) id KAA05133; Wed, 18 Dec 1996 10:57:36 +0100 (MET) Date: Wed, 18 Dec 1996 10:57:36 +0100 (MET) From: Jean-Luc Richier Message-Id: <199612180957.KAA05133@horus.imag.fr> In-Reply-To: Craig Metz's message as of Dec 11, 1:31. Organization: IMAG, Grenoble, France X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: hinden@Ipsilon.COM, deering@cisco.com Subject: (IPng 2617) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <3.0.32.19961210175622.006cc4ec@mailhost.ipsilon.com>, you write: >This is an ipng working group last call for comments on advancing the >following document to Informational: > > 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 > >Please send substantive comments to the ipng mailing list, and minor >editorial comments to the authors. This last call period will end two >weeks from today, on 12/24/96. About getnameinfo: DRAFT> Note that this function does not know the protocol of the socket DRAFT> address structure. Normally this is not a problem because the same DRAFT> port is assigned to a given service for both TCP and UDP. But there DRAFT> exist historical artifacts that violate this rule (e.g., ports 512, DRAFT> 513, and 514). I think that this is wrong. There is a lot of official services which exist only in tcp, and answering "ftp" for udp socket 21 is clearly incorrect. The correct answer is either 21 or signalling an error. Therefore I suggest adding a 7th parameter to getnameinfo, for providing hints, either a flag, or a pointer to a structure like the parameter of getaddrinfo, with the type : struct addrinfo { int ai_flags; /* AI_PASSIVE, AI_CANONNAME */ int ai_family; /* PF_xxx */ int ai_socktype; /* SOCK_xxx */ int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ size_t ai_addrlen; /* length of ai_addr */ char *ai_canonname; /* canonical name for hostname */ struct sockaddr *ai_addr; /* binary address */ struct addrinfo *ai_next; /* next structure in linked list */ }; - ai_socktype can be used to specify the socket type (STREAM or DGRAM) - ai_flags can be used to specify if one wish fully qualified names, non qualified names, a numeric form (as suggested by Craig Metz) .. - ai_family could be used for genericity (PF_ISO ??) PS: there is certainly too many fields in this hints structure for getnameinfo One can define a new hint structure, but is it useful ? -- Jean-Luc RICHIER (Jean-Luc.Richier@Imag.Fr richier@imag.fr) Laboratoire Logiciels, Systemes et Reseaux (LSR-IMAG) IMAG-CAMPUS, BP 53, F-38041 GRENOBLE Cedex 9 Tel : (33) 76 82 72 32 Fax : (33) 76 82 72 87 ------------------------------------------------------------------------------ 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 Dec 18 11:51:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20601; Wed, 18 Dec 96 11:51:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20595; Wed, 18 Dec 96 11:51:46 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA04856; Wed, 18 Dec 1996 11:43:53 -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 LAA04033 for ; Wed, 18 Dec 1996 11:43:41 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA22338; Wed, 18 Dec 1996 14:30:41 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14767; Wed, 18 Dec 1996 14:30:39 -0500 Message-Id: <9612181930.AA14767@wasted.zk3.dec.com> To: George Tsirtsis Cc: Paul Ferguson , ipng@sunroof.eng.sun.com Subject: (IPng 2618) Re: Archive gelp In-Reply-To: Your message of "Wed, 18 Dec 96 09:37:22 GMT." Date: Wed, 18 Dec 96 14:30:38 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >When you say "hybrid" what exactly do you mean? Is it like a dos/linux >system where you have to reboot the machine in order to go from the one to >the other, or you have both IPv4 and IPv6 running on the same time and a >mechanism that understands when to use the one and when the other? Meaning some layers support duplicate modules like ip_output.c and ip6_output.c, but there is only one tcp_output.c module in the kernel. >> I find people freak when they hear transition and on Intranets IPv4 will >> not disappear before I leave this insane business and go live in the >> mountains so I say "interoperation". >O.K. you say it! But do you really mean it? :) Yes I do. /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 Dec 18 16:43:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21118; Wed, 18 Dec 96 16:43:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21112; Wed, 18 Dec 96 16:43:28 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA10123; Wed, 18 Dec 1996 16:35:37 -0800 Received: from mailhost4.BayNetworks.COM (lobster.corpeast.baynetworks.com [192.32.253.3]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA11277 for ; Wed, 18 Dec 1996 16:35:36 -0800 Received: from pobox.BayNetworks.com (pobox [192.32.151.199]) by mailhost4.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with SMTP id TAA27877; Wed, 18 Dec 1996 19:39:48 -0500 (EST) for Posted-Date: Wed, 18 Dec 1996 19:39:48 -0500 (EST) Received: from andover.engeast by pobox.BayNetworks.com (SMI-8.6/SMI-SVR4) id MAA22322; Wed, 18 Dec 1996 12:29:30 -0500 Date: Wed, 18 Dec 1996 12:29:30 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199612181729.MAA22322@pobox.BayNetworks.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2619) IPV6 over PPP Cc: dhaskin@mailhost4.BayNetworks.COM, eallen@mailhost4.BayNetworks.COM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, This is just to let you no that there will be a small change in the IPv6-over-PPP spec. The PPP Extentions working group wants to modify the way one case of tocken negotiation (when only one end of PPP connection is able to generate a random number) is handled. Below is a message from the chair of the PPP WG to this effect. Btw, this is an opportunity to provide additional comments on the spec. Dimitry ----- Begin Included Message ----- >From karl@carp.morningstar.com Tue Dec 17 19:56 EST 1996 Posted-Date: Tue, 17 Dec 1996 16:55:18 -0800 (PST) Date: Tue, 17 Dec 1996 16:56:41 -0800 X-UIDL: 850871114.016 From: Karl Fox To: dhaskin@BayNetworks.com, eallen@BayNetworks.com Subject: RFC 2023 Reply-To: Karl Fox Organization: Ascend Communications Content-Type: text Content-Length: 1496 The problem in RFC 2023 pointed up by Steven Bade in the ietf-ppp mailing list is a fatal flaw; PPP Configure-Ack messages are required to be unmodified versions of the Configure-Request messages that prompt them. RFC 2023 is therefore being converted to `historic' status and a new, corrected RFC will be cut. To this end, please submit a new Internet Draft identical to the last one you submitted but with the following change: On page 5, in section 4.1, change the following paragraph If the two Interface-Tokens are different but the received Interface-Token is zero, a Configure-Ack is sent with a non-zero Interface-Token value suggested for use by the remote peer. Such a suggested Interface-Token MUST be different from the Interface- Token of the last Configure-Request sent to the peer. to If the two Interface-Tokens are different but the received Interface-Token is zero, a Configure-Nak is sent with a non-zero Interface-Token value suggested for use by the remote peer. Such a suggested Interface-Token MUST be different from the Interface- Token of the last Configure-Request sent to the peer. Note the two-letter change from Configure-Ack to Configure-Nak. I apologize having to submit the two of you to this inconvenience; this error should have been caught in last call. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 ----- 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 Dec 20 08:07:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23808; Fri, 20 Dec 96 08:07:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23802; Fri, 20 Dec 96 08:07:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA03344; Fri, 20 Dec 1996 07:59:40 -0800 Received: from mailhost4.BayNetworks.COM (lobster.corpeast.baynetworks.com [192.32.253.3]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA13152 for ; Fri, 20 Dec 1996 07:59:39 -0800 Received: from pobox.BayNetworks.com (pobox [192.32.151.199]) by mailhost4.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with SMTP id LAA17014 Posted-Date: Fri, 20 Dec 1996 11:03:51 -0500 (EST) Received: from andover.engeast by pobox.BayNetworks.com (SMI-8.6/SMI-SVR4) id KAA01375; Fri, 20 Dec 1996 10:59:04 -0500 Date: Fri, 20 Dec 1996 10:59:04 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199612201559.KAA01375@pobox.BayNetworks.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2620) larger AS/RD space for v6? Cc: bgp@ans.net Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, There was a discussion on the IDR list to whether a larger than a 2-byte AS/RD number space is needed to for IPv6. The discution was prompted by a BGP4+ proposal for v6. I'd like to solicit input from a larger IPv6-minded audience on this subgect. The following are snippets from the pro-con arguments: - The current 2-byte AS number space is sufficient. It doesn't look like we'll have a shortage of ASs any time soon. Currently there are only 1897 ASes in routing system. Study done by Ramesh Govindan and Anoop Reddy (govindan@isi.edu, areddy@isi.edu) shows that new domain pops up every 12 hours. That is ~700 domains per year. If the consumption rate of AS space stays comparable to what we have today, then ~7,000 domains per 10 years... We have a lot of life yet before we need to think about introducing a larger AS/RD space and the backward compatibility issues associated with this. - A larger AS/RD space is needed for IPv6 Somebody (some whole group of bodies) once thought that a 32-bit IP address would hold off for a long time.... Today, there are very strong incentives towards organizations becoming multi-homed, both for perceived or real increases in reliability and/or simply because it is often easier to justify "portable" address space if you're multi-homed. Given these incentives and the proliferation of Internet exchanges, I think it is highly questionable whether a linear model is sufficient to estimate AS number consumption. The backword compatibility is not an issue for IPv6 at this point so it is an opportunity to adopt a large than a 2-byte AS/RD number space for v6. If we underestimate IPv6 RD space consumtion rate it may actually become a painful backword compatibility issue in the future. Comments? 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 Fri Dec 20 08:29:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23846; Fri, 20 Dec 96 08:29:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23840; Fri, 20 Dec 96 08:29:32 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA06612; Fri, 20 Dec 1996 08:21:36 -0800 From: bmanning@ISI.EDU Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA21565 for ; Fri, 20 Dec 1996 08:21:35 -0800 Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 20 Dec 1996 08:21:28 -0800 Posted-Date: Fri, 20 Dec 1996 08:20:12 -0800 (PST) Message-Id: <199612201620.AA22085@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Fri, 20 Dec 1996 08:20:12 -0800 Subject: (IPng 2621) Re: larger AS/RD space for v6? To: dhaskin@baynetworks.com (Dimitry Haskin) Date: Fri, 20 Dec 1996 08:20:12 -0800 (PST) Cc: ipng@sunroof.eng.sun.com, bgp@ans.net In-Reply-To: <199612201559.KAA01375@pobox.BayNetworks.com> from "Dimitry Haskin" at Dec 20, 96 10:59:04 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 > There was a discussion on the IDR list to whether a larger than a 2-byte > AS/RD number space is needed to for IPv6. The discution was prompted by > a BGP4+ proposal for v6. I'd like to solicit input from a larger > IPv6-minded audience on this subgect. > BGP4+ should be IDRP and use RDIs. -- --bill ------------------------------------------------------------------------------ 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 Dec 20 08:33:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23880; Fri, 20 Dec 96 08:33:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23874; Fri, 20 Dec 96 08:33:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA07333; Fri, 20 Dec 1996 08:25:39 -0800 Received: from metro.isi.edu (metro.isi.edu [38.245.76.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA23488 for ; Fri, 20 Dec 1996 08:25:38 -0800 Received: from metro.isi.edu by metro.isi.edu (5.65c/5.61+local-23) id ; Fri, 20 Dec 1996 11:25:32 -0500 Message-Id: <199612201625.AA05946@metro.isi.edu> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: ipng@sunroof.eng.sun.com, bgp@ans.net Subject: (IPng 2622) Re: larger AS/RD space for v6? In-Reply-To: Your message of "Fri, 20 Dec 1996 10:59:04 EST." <199612201559.KAA01375@pobox.BayNetworks.com> X-Phone: +1 703 812 3704 Date: Fri, 20 Dec 1996 11:25:32 EST From: "John W. Stewart III" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk this issue is probably more relevant to the IDR WG than IPNG, but... i think that bgp4++ should include the ability to carry RDIs (variable-length ASs) the bgp4++ proposal on the table includes multi-protocol extensions. this significantly extends the lifetime of bgp4. to extend the lifetime of a protocol but keep one of the number spaces (specifically ASs) small and fixed is, in my opinion, unwise /jws > Folks, > > There was a discussion on the IDR list to whether a larger than a 2-byte > AS/RD number space is needed to for IPv6. The discution was prompted by > a BGP4+ proposal for v6. I'd like to solicit input from a larger > IPv6-minded audience on this subgect. > > The following are snippets from the pro-con arguments: > > - The current 2-byte AS number space is sufficient. > > It doesn't look like we'll have a shortage of ASs any time soon. > Currently there are only 1897 ASes in routing system. > Study done by Ramesh Govindan and Anoop Reddy (govindan@isi.edu, > areddy@isi.edu) shows that new domain pops up every 12 hours. That is > ~700 domains per year. If the consumption rate of AS space stays > comparable to what we have today, then ~7,000 domains per 10 years... > > We have a lot of life yet before we need to think about introducing > a larger AS/RD space and the backward compatibility issues associated > with this. > > > - A larger AS/RD space is needed for IPv6 > > Somebody (some whole group of bodies) once thought that a 32-bit IP > address would hold off for a long time.... > > Today, there are very strong incentives towards organizations becoming > multi-homed, both for perceived or real increases in reliability > and/or simply because it is often easier to justify "portable" address > space if you're multi-homed. Given these incentives and the > proliferation of Internet exchanges, I think it is highly questionable > whether a linear model is sufficient to estimate AS number consumption. > > The backword compatibility is not an issue for IPv6 at this point so > it is an opportunity to adopt a large than a 2-byte AS/RD number space > for v6. If we underestimate IPv6 RD space consumtion rate it may actually > become a painful backword compatibility issue in the future. > > > Comments? > > 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 ------------------------------------------------------------------------------ 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 Dec 20 09:07:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23955; Fri, 20 Dec 96 09:07:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23949; Fri, 20 Dec 96 09:07:47 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA14850; Fri, 20 Dec 1996 08:59:51 -0800 Received: from ftp.com (ftp.com [128.127.2.122]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA07548 for ; Fri, 20 Dec 1996 08:59:51 -0800 Received: from ftp.com by ftp.com ; Fri, 20 Dec 1996 11:59:49 -0500 Received: from mailserv-2high.ftp.com by ftp.com ; Fri, 20 Dec 1996 11:59:49 -0500 Received: from everest.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id LAA15868; Fri, 20 Dec 1996 11:59:50 -0500 Received: by everest.ftp.com with Microsoft Mail id <01BBEE6D.5F325280@everest.ftp.com>; Fri, 20 Dec 1996 12:00:19 -0500 Message-Id: <01BBEE6D.5F325280@everest.ftp.com> From: Shishir To: "'ipng@sunroof.Eng.Sun.com'" Subject: (IPng 2623) IPv6 supporting platforms ! Date: Fri, 20 Dec 1996 12:00:18 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am trying to set up a UNIX box that will support IPv6 so I can do some testing. Can anyone suggest one ? Thanks ! Shishir Belbase Sr. Support Engineer FTP Software, Inc. shishpop@ftp.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 Dec 20 09:22:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23982; Fri, 20 Dec 96 09:22:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23976; Fri, 20 Dec 96 09:22:20 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA18012; Fri, 20 Dec 1996 09:14:22 -0800 Received: from snoopy.agile.com ([198.3.105.68]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA13723 for ; Fri, 20 Dec 1996 09:14:14 -0800 Received: by snoopy.agile.com with Microsoft Exchange (IMC 4.0.837.3) id <01BBEE6F.5A68F8B0@snoopy.agile.com>; Fri, 20 Dec 1996 12:14:30 -0500 Message-Id: From: "Harrington, Dan" To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 2624) RE: IPv6 supporting platforms ! Date: Fri, 20 Dec 1996 12:14:29 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 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 Shishir, The IPNG Home Page listed at the bottom of this mail message contains a list of IPv6 implementations...that's probably the best starting place for you. Good luck! Dan > ------------------------------------------------------------------------------ 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 Dec 20 09:46:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24043; Fri, 20 Dec 96 09:46:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24037; Fri, 20 Dec 96 09:46:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA23220; Fri, 20 Dec 1996 09:38:39 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA23847 for ; Fri, 20 Dec 1996 09:38:38 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id MAA13250; Fri, 20 Dec 1996 12:38:22 -0500 Date: Fri, 20 Dec 1996 12:38:22 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9612201238.ZM13248@seawind.bellcore.com> In-Reply-To: bmanning@ISI.EDU "(IPng 2621) Re: larger AS/RD space for v6?" (Dec 20, 8:20am) References: <199612201620.AA22085@zed.isi.edu> X-Mailer: Z-Mail (3.2.1 10oct95) To: bmanning@ISI.EDU Subject: (IPng 2625) Re: larger AS/RD space for v6? Cc: bgp@ans.net, 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 Bill, The statement that "BGP4+ should be IDRP and use RDIs" may be fine, but should not be related to what EGP will be used for IPv6. One of the clear feed-back we received from implementors and early adopters was that "it has to be the same". That is, IPv6 should be using whatever IPv4 is using. Which may well mean BGP4 plus minimal extensions, as long as IPv4 has not yet started using IDRP. Note that the rationale here is "use existing skills". Adding a prefix of the type "1234:5678:9ABC//48" to an existing reachability lists does not require many new skills. Switching from one numbering scheme (16 bits AS number) to another (RDI) does -- you have to make up a new numbering plan. -- Christian Huitema ------------------------------------------------------------------------------ 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 Dec 20 11:34:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24262; Fri, 20 Dec 96 11:34:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24256; Fri, 20 Dec 96 11:34:20 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA20846; Fri, 20 Dec 1996 11:26:24 -0800 Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA10685 for ; Fri, 20 Dec 1996 11:26:24 -0800 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id OAA16089; Fri, 20 Dec 1996 14:26:04 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma016001; Fri Dec 20 14:25:46 1996 Received: from mako.us.newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id OAA21120; Fri, 20 Dec 1996 14:25:44 -0500 Received: from lobster.nni by mako.us.newbridge.com (4.1/SMI-4.1) id AA04640; Fri, 20 Dec 96 14:24:04 EST Received: by lobster.nni (5.0/SMI-SVR4) id AA26127; Fri, 20 Dec 1996 14:23:22 +0500 Date: Fri, 20 Dec 1996 14:23:22 +0500 From: jhalpern@us.newbridge.com (Joel Halpern) Message-Id: <9612201923.AA26127@lobster.nni> To: ipng@sunroof.eng.sun.com, dhaskin@BayNetworks.COM Subject: (IPng 2626) Re: larger AS/RD space for v6? Cc: bgp@ans.net X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I will note that some people are concernedrelative to the 8+8 proposal that either 14 bits may not be enough space for the top, or that 45 bits may not be enough for the full provider heirarchy. While the presence of heirarchy will allow some reuse of policy identification (AS) space, I would hate to be too heavily dependent on that. If we need thousands of top level entities, and absurd numbers of "ISP"s with policy, it would seem likely to me that at some point we will need more than 16 bits worth of policy space identifier. When will we need that is definitely an open question. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ 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 Dec 20 11:51:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24289; Fri, 20 Dec 96 11:51:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24276; Fri, 20 Dec 96 11:51:24 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA24848; Fri, 20 Dec 1996 11:43:28 -0800 Received: from ncc.ripe.net (ncc.ripe.net [193.0.0.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA16753 for ; Fri, 20 Dec 1996 11:43:28 -0800 Received: from office.ripe.net by ncc.ripe.net with SMTP id AA23674 (5.65a/NCC-2.40); Fri, 20 Dec 1996 20:42:54 +0100 Message-Id: <9612201942.AA23674@ncc.ripe.net> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: ipng@sunroof.eng.sun.com, bgp@ans.net From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: (IPng 2627) Re: larger AS/RD space for v6? In-Reply-To: Your message of "Fri, 20 Dec 1996 10:59:04 EST." <199612201559.KAA01375@pobox.BayNetworks.com> Date: Fri, 20 Dec 1996 20:42:48 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 20 Dec 1996 10:59:04 -0500 Dimitry Haskin wrote: > There was a discussion on the IDR list to whether a larger than a 2-byte > AS/RD number space is needed to for IPv6. The discution was prompted by > a BGP4+ proposal for v6. I'd like to solicit input from a larger > IPv6-minded audience on this subgect. ... > Study done by Ramesh Govindan and Anoop Reddy (govindan@isi.edu, > areddy@isi.edu) shows that new domain pops up every 12 hours. That is > ~700 domains per year. If the consumption rate of AS space stays > comparable to what we have today, then ~7,000 domains per 10 years... Another datapoint: The RIPE NCC started issuing ASes from our latest block on May 21 Today we have issued 224 AS numbers from that block - that's more than one per day and the pace is increasing rather than decreasing. Each of these requests has been evaluated according to RFC1930. Keeping in mind that there are multiple regional registries, and that there's no reason not to expect the pace of this to double every 10 months (just like the rest of the net does), I'm feeling a little uncomfortable with this, certainly because it takes a *protocol change* to widen the number space later. Since we have to make a protocol change anyway, I think it is wise to bite the bullet and go for 32 bits while we have the chance and it would take minimal effort. Geert Jan ------------------------------------------------------------------------------ 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 Dec 20 12:08:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24307; Fri, 20 Dec 96 12:08:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24301; Fri, 20 Dec 96 12:08:10 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA28622; Fri, 20 Dec 1996 12:00:15 -0800 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA22364 for ; Fri, 20 Dec 1996 12:00:12 -0800 Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.3/8.6.12) with SMTP id OAA05700; Fri, 20 Dec 1996 14:59:52 -0500 (EST) Message-Id: <199612201959.OAA05700@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Geert Jan de Groot Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2628) Re: larger AS/RD space for v6? In-Reply-To: Your message of "Fri, 20 Dec 1996 20:42:48 +0100." <9612201942.AA23674@ncc.ripe.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 Dec 1996 14:59:51 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Geert Jan de Groot writes: > Since we have to make a protocol change anyway, I think it is wise > to bite the bullet and go for 32 bits while we have the chance and > it would take minimal effort. A good idea. I strongly agree. Perry ------------------------------------------------------------------------------ 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 Dec 20 12:50:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24383; Fri, 20 Dec 96 12:50:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24377; Fri, 20 Dec 96 12:50:32 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA07149; Fri, 20 Dec 1996 12:42:37 -0800 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA05371 for ; Fri, 20 Dec 1996 12:42:38 -0800 Received: (dkatz@localhost) by puli.cisco.com (8.6.12/8.6.5) id MAA11174; Fri, 20 Dec 1996 12:42:36 -0800 Date: Fri, 20 Dec 1996 12:42:36 -0800 From: Dave Katz Message-Id: <199612202042.MAA11174@puli.cisco.com> To: ipng@sunroof.eng.sun.com, bgp@ans.net Subject: (IPng 2629) BGP/IDRP/IPv6 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Our recent proposal to extend BGP4 to support multiple protocols has raised a discussion about broader issues involving the future of interdomain routing protocols. The early draft we released obviously did not touch on any of these issues. I'm going to attempt to lay out what I think the issues and options are. At this point there are basically three deltas between BGP4 and IDRP: 1) Multiprotocol support 2) Extended AS/RD support 3) Independent transport There is a near-term requirement for multiprotocol support. There is a potential need for the extended AS/RD support, although if it is necessary it will be some time before it is needed. Getting rid of TCP would be nice but there is little technical requirement for doing so. Of these, the only one that I can see being done in a truly backward compatible fashion would be the multiprotocol support (as evidenced by our proposal). The others would require a new protocol/version. The independent transport is something that can be deployed on a pairwise basis without global impact. Extending the RD space will require a global transition. The obvious transition plan is to deploy the protocol but to continue to use 16 bit RDs; once all vestiges of BGP4 are gone the extended space can come into use. (There is also a semi-delta, confederations; there is a draft on the table to extend BGP4 in this way, and experimental code deployed.) Given these functional differences, there are a couple of questions that that I can think of: 1) Should we extend BGP4 for multiprotocol support, or should we do that support as part of a next generation protocol? Making multiprotocol support an extension of BGP4 has the advantage that it decouples the development and deployment of this functionality from the others. However, it has been posited that bundling the multiprotocol support with the other changes would require only a single transition, which could be an advantage. 2) Should the next generation protocol be IDRP, or something that looks startlingly like BGP, or should there be one at all (at least one that smells like BGP/IDRP)? Given that at this point there is so little difference in functionality between IDRP (as published) and BGP (with the proposed multiprotocol extensions), it seems fair to ask the question of whether it is worthwhile to go forward with IDRP per se. One alternative would be to spin BGP one more time to bring it semantically in line with IDRP (adding extended RDs and perhaps changing out the transport). Another option would be to do nothing beyond the multiprotocol extension, with the expectation that we will not need the extended RDs, or that we will need to do something more radical before the extended RD feature is needed. IMHO, the right course of action is to do the multiprotocol extension to BGP4 quickly so that interdomain routing would not stand in the way of IPv6 deployment. This can be done independently of any other work. If the extended RD is necessary, I think the minimal impact approach is to implement XDRP, a protocol that looks remarkably like BGP in all respects except the RD field and perhaps the transport if it is desirable. Developing and deploying a new protocol in order to get 1.5 features seems like an unnecessary complication. It is worth noting that multihomed, non-transit domains do not need AS numbers. I'd like to hear what the ISPs (who will be the ones to deploy this stuff) have to say about the subject. It seems to me as though IPv6 will be easier to deploy as an incremental add-on to the existing BGP4 then if it were bundled in an incompatible (if perhaps almost-compatible) protocol, but I'll let the ISPs speak for themselves. --Dave ------------------------------------------------------------------------------ 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 Dec 20 12:53:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24398; Fri, 20 Dec 96 12:53:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24392; Fri, 20 Dec 96 12:53:32 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA07617; Fri, 20 Dec 1996 12:45:36 -0800 From: bmanning@ISI.EDU Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA06280 for ; Fri, 20 Dec 1996 12:45:36 -0800 Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 20 Dec 1996 12:45:33 -0800 Posted-Date: Fri, 20 Dec 1996 12:44:17 -0800 (PST) Message-Id: <199612202044.AA22354@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Fri, 20 Dec 1996 12:44:17 -0800 Subject: (IPng 2630) Re: larger AS/RD space for v6? To: GeertJan.deGroot@ripe.net (Geert Jan de Groot) Date: Fri, 20 Dec 1996 12:44:17 -0800 (PST) Cc: dhaskin@baynetworks.com, ipng@sunroof.eng.sun.com, bgp@ans.net In-Reply-To: <9612201942.AA23674@ncc.ripe.net> from "Geert Jan de Groot" at Dec 20, 96 08:42:48 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 > I'm feeling a little uncomfortable with this, certainly because it > takes a *protocol change* to widen the number space later. > > Since we have to make a protocol change anyway, I think it is wise > to bite the bullet and go for 32 bits while we have the chance and > it would take minimal effort. > > Geert Jan > If we take this tack, we are asking to redo this discussion in about a decade. If we are going to make the change, then lets do RDI's which are much more flexable and have a much larger scaling factor. -- --bill ------------------------------------------------------------------------------ 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 Dec 20 13:17:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24519; Fri, 20 Dec 96 13:17:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24513; Fri, 20 Dec 96 13:17:43 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA12352; Fri, 20 Dec 1996 13:09:47 -0800 From: bmanning@ISI.EDU Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA13227 for ; Fri, 20 Dec 1996 13:09:47 -0800 Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 20 Dec 1996 13:09:46 -0800 Posted-Date: Fri, 20 Dec 1996 13:08:30 -0800 (PST) Message-Id: <199612202108.AA22483@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Fri, 20 Dec 1996 13:08:30 -0800 Subject: (IPng 2631) Re: larger AS/RD space for v6? To: huitema@bellcore.com (Christian Huitema) Date: Fri, 20 Dec 1996 13:08:30 -0800 (PST) Cc: bmanning@ISI.EDU, bgp@ans.net, ipng@sunroof.eng.sun.com In-Reply-To: <9612201238.ZM13248@seawind.bellcore.com> from "Christian Huitema" at Dec 20, 96 12:38:22 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 > > Bill, > > The statement that "BGP4+ should be IDRP and use RDIs" may be fine, but > should not be related to what EGP will be used for IPv6. One of the clear > feed-back we received from implementors and early adopters was that "it > has to be the same". That is, IPv6 should be using whatever IPv4 is > using. Which may well mean BGP4 plus minimal extensions, as long as IPv4 > has not yet started using IDRP. > > Note that the rationale here is "use existing skills". Adding a prefix of > the type "1234:5678:9ABC//48" to an existing reachability lists does not > require many new skills. Switching from one numbering scheme (16 bits AS > number) to another (RDI) does -- you have to make up a new numbering plan. > > -- > Christian Huitema > I have heard this type of argument before... when the EGP apologists were attempting to temper the changes BGP brought to the table. Quantum state changes are actaully easier to do than analog shifts. -- --bill ------------------------------------------------------------------------------ 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 Dec 20 13:37:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24581; Fri, 20 Dec 96 13:37:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23439; Fri, 20 Dec 96 00:22:19 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA21843; Fri, 20 Dec 1996 00:14:25 -0800 Received: from tjok.tbit.dk (tjok.tbit.dk [194.182.135.79]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA08749 for ; Fri, 20 Dec 1996 00:14:23 -0800 Received: from pcn.tbit.dk (pcn.tbit.dk [194.182.135.33]) by tjok.tbit.dk (8.7.5/8.7.3) with ESMTP id JAA06253 for ; Fri, 20 Dec 1996 09:15:05 +0100 (MET) Received: from localhost (pcn@localhost) by pcn.tbit.dk (8.7.5/8.7.3) with ESMTP id SAA27707 for ; Fri, 20 Dec 1996 18:14:30 +0100 (MET) Date: Fri, 20 Dec 1996 18:14:27 +0100 (MET) From: "Peder Chr. Norgaard" To: ipng@sunroof.eng.sun.com Subject: (IPng 2632) IPv6 and PPP - discussing randomly chosen interface tokens Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk With the opening of the IPv6-over-PPP document I would suggest a discussion of a specific topic: the question of using randomly chosen interface tokens. Now, to be true, RFC 2023 does not specify that an implementation MUST use a new, randomly chosen interface token every time it starts a new session; but it certainly suggests so. I would much prefer a strategy for interface tokens that behaves more the way Neighbor Discovery works on broadcast interfaces: that the interface token is initialized from a built-in (like a MAC address) or adminitratively assigned value and that only the case of duplicate tokens on the link changes this. Why? Because I cannot see why it is a good idea that addresses on PPP lines change every time the line goes down. Please recall that interface tokens in the future IPv6 world with renumbering are not only used for link-local addresses; they are also intended to form the basis for the generation of global scope addresses. Should every line fall-out make it necessary for the communication nodes to feed new addresses back into DNS? Of course, I may be wrong - there may be some very good reasons for using changing interface tokens in PPP. If that is the case these reasons should be specified in the standard. Or I may read the RFC2023 wrong - it may not be the intention to use changing interface tokens; in that case I would ask for a more precise text on the topic. best regards Peder Chr. N=F8rgaard Systems Programmer, M. Sc. Telebit Communications A/S tel: +45 86 28 81 77 - 49 Skanderborgvej 234 fax: +45 86 28 81 86 DK-8260 Viby J Denmark e-mail: pcn@tbit.dk ------------------------------------------------------------------------------ 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 Dec 20 13:49:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24599; Fri, 20 Dec 96 13:49:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24076; Fri, 20 Dec 96 09:55:09 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA25045; Fri, 20 Dec 1996 09:47:12 -0800 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA27402 for ; Fri, 20 Dec 1996 09:47:13 -0800 Received: from elmo.uu.net by relay2.UU.NET with ESMTP (peer crosschecked as: elmo.UU.NET [153.39.245.203]) id QQbuxz24934; Fri, 20 Dec 1996 12:47:09 -0500 (EST) Received: from elmo.uu.net (localhost.UU.NET [127.0.0.1]) by elmo.uu.net (8.7.5/8.7.3) with ESMTP id MAA20792; Fri, 20 Dec 1996 12:47:04 -0500 (EST) Message-Id: <199612201747.MAA20792@elmo.uu.net> To: dhaskin@BayNetworks.COM (Dimitry Haskin) Cc: ipng@sunroof.eng.sun.com, bgp@ans.net Subject: (IPng 2633) Re: larger AS/RD space for v6? In-Reply-To: Your message of "Fri, 20 Dec 1996 10:59:04 EST." <199612201559.KAA01375@pobox.BayNetworks.com> Date: Fri, 20 Dec 1996 12:47:04 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk if we're gonna whack bgp, then making more is probably a Good Idea. i know we certainly have issues with customers needing an AS and there being push-back. -mo ------------------------------------------------------------------------------ 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 Dec 20 14:07:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24644; Fri, 20 Dec 96 14:07:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24238; Fri, 20 Dec 96 11:05:08 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA14036; Fri, 20 Dec 1996 10:57:11 -0800 Received: from scam.XCF.Berkeley.EDU (scam.XCF.Berkeley.EDU [128.32.43.201]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA00020 for ; Fri, 20 Dec 1996 10:57:08 -0800 Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by scam.XCF.Berkeley.EDU (8.7.5/8.7.3) with SMTP id KAA22082; Fri, 20 Dec 1996 10:52:26 -0800 Message-Id: <199612201852.KAA22082@scam.XCF.Berkeley.EDU> X-Authentication-Warning: scam.XCF.Berkeley.EDU: Host localhost.Berkeley.EDU [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com, bgp@ans.net Subject: (IPng 2634) Re: larger AS/RD space for v6? In-Reply-To: Your message of "Fri, 20 Dec 1996 12:47:04 EST." <199612201747.MAA20792@elmo.uu.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <22079.851107945.1@scam.XCF.Berkeley.EDU> Date: Fri, 20 Dec 1996 10:52:26 -0800 From: Eric Hollander Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >if we're gonna whack bgp, then making more is probably >a Good Idea. i know we certainly have issues with >customers needing an AS and there being push-back. it would really suck to go through the nightmare of an ipv6 transition, and then find out a couple years later that we need to do another big transition to some larger asn space. we might as well do both at the same time, even if this only means moving from 16 to 32 bits, instead of some more general scheme. maybe we could just define that all currently issued asns are 00xx, where xx are the two bytes of the current asn. e ------------------------------------------------------------------------------ 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 Dec 20 14:41:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24712; Fri, 20 Dec 96 14:41:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24706; Fri, 20 Dec 96 14:40:52 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA00752; Fri, 20 Dec 1996 14:32:55 -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 OAA11010 for ; Fri, 20 Dec 1996 14:32:46 -0800 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA31752; Fri, 20 Dec 1996 17:30:55 -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 RAA37716 for ; Fri, 20 Dec 1996 17:30:56 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA10840; Fri, 20 Dec 1996 17:33:17 -0500 Message-Id: <9612202233.AA10840@ludwigia.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2635) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" In-Reply-To: Your message of "Tue, 10 Dec 1996 22:17:54 PST." <3.0.32.19961210175622.006cc4ec@mailhost.ipsilon.com> Date: Fri, 20 Dec 1996 17:33:17 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK, here's my $0.02 on the document. Overall I think it is quite good. It's nice to be at the point of fine-tuning. Also, some of the things I'm bringing up may have been mentioned before, but some have not. So bear with me. First, Neither the basic or advanced API spec seems to provide a way to obtain the Hop Limit on a *received* datagram. I think this is something we should provide, since some routing protocols may want to verify that updates they are receiving are from directly attached neighbors. They could use the same Hop Limit == 255 trick as ND. I don't really care which document it goes in, though it would seem to fit with advanced API and ancillary data. Having said that, however, however, it seems OSPFv6 just multicasts to the link-local address with a Hop Limit of 1, and RIPng doesn't bother. So maybe this point is moot now. :-( Now, staring with the first sentence in the introduction: :-) > While IPv4 addresses are 32 bits long, IPv6 nodes are identified by ^^^^^ Shouldn't that say "interfaces"? > 128-bit addresses. The socket interface make the size of an IP ^^^^ "makes" > u_char s6_addr[16]; /* IPv6 address */ Don't some folks get bent out shape when they see "u_char" in a spec? Why isn't this a u_int8_t? (This comment applies throughout.) > The ordering of elements in this structure is specifically designed ^^^^ s/this/the sockaddr_in6/ > #define SIN6_LEN > > struct sockaddr_in6 { > u_char sin6_len; /* length of this struct */ > u_char sin6_family; /* AF_INET6 */ The only place in the draft where sin6_len is mentioned is in this section. If we want to promote application portability, then we might want to add "#ifdef SIN6_LEN" code snippets throughout the document (where appropriate) so that folks on non-4.4 systems do the right thing with the sin6_len field as they develope code on 4.3-derived systems. Would that clutter up the document too much? There are only a few places in the current examples where that is needed I think. > 0:0:0:0:0:FFFF. IPv4-mapped addresses are written as follows: > > ::FFFF: > > These addresses are often generated automatically by the > gethostbyname() function when the specified host has only IPv4 > addresses (as described in Section 6.1). Is this paragraph needed? It seems a bit misleading (is gethostbyname really the routine that does this, or is this buried elsewhere in the DNS code?) and doesn't strike me as being particularly relevant to programmers anyway. > and priority from the packets they receive. The header fields of an > actively opened TCP connection are set by assigning in the > sin6_flowinfo field of the destination address sockaddr_in6 structure > passed in the connect() function. The same technique can be used I have some concerns with the above. I don't think we really understand (yet) all the pieces for making Flow Labels work. That is, it is clear that the kernel will have some say in what Flow Labels get used (for uniqueness if nothing else). So I don't think we are in a position to say right now that the user can specify the Flow Label simply by putting in random values in the field. The OS kernel may want to restrict who uses what Flow Id. For instance, it might not want some random user to piggy back its packets on the Flow used by a video server. > recvfrom(), recvmsg(), and accept() functions. An application may > specify the flow label and priority to use in transmitted packets of > a passively accepted TCP connection, by setting the sin6_flowinfo > field of the address passed to the bind() function. I think its premature to say this as well. > IPV6_FLOWINFO_FLOWLABEL > IPV6_FLOWINFO_PRIORITY How about defining macros for manipulating these fields? The advanced API document is full of such macros. For example, how about changing: > recv_flow = ntohl(sin6.sin6_flowinfo & IPV6_FLOWINFO_FLOWLABEL); > recv_prio = ntohl(sin6.sin6_flowinfo & IPV6_FLOWINFO_PRIORITY) >> 24; to recv_flow = ntohl(EXTRACT_FLOW_LABEL(&sin6)); recv_prio = ntohl(EXTRACT_PRIORITY(&sin6)); I think this would reduce programming errors me thinks. > address of UDP packets and TCP connections, applications often want > the system select the source address for them. With IPv4, one ^^ missing "to" > Be aware that the IPv4 INADDR_xxx constants are all defined in host > byte order but the IPv6 IN6ADDR_xxx constants and the IPv6 > in6addr_xxx externals are defined in network byte order. What other INADDR_xxx addresses are there besides loopback (the only other one mentioned in the document)? Does it make sense to define some of the pre-defined link-local multicast groups for instance? > struct sockaddr_in6 sin6; > . . . > sin6.sin6_family = AF_INET6; > sin6.sin6_flowinfo = 0; > sin6.sin6_port = htons(23); > sin6.sin6_addr = in6addr_loopback; /* structure assignment */ > . . . How about adding "#ifdef SIN6_LEN" code to the example. > IPV6_ADD_MEMBERSHIP > > Join a multicast group on a specified local interface. If > the interface index is specified as 0, the kernel chooses the > local interface by looking up the multicast group in the > normal IPv6 routing table and using the resulting interface. The wording of the last sentence seems awfully implementation dependent (and thus possibly incorrect). Shouldn't the API simply say the kernel picks an interface in this case? > - The second way to set this option is to set the environment > variable RES_OPTIONS, as in RES_OPTIONS=inet6. This method > affects any processes that see this environment variable. Hmm. Which shell are you assuming above? :-) How about adding a "for example, in my_fave_shell, ..." Also, I wasn't entirely clear what precedence applied when various combinations of the "three ways to set RES_USE_INET6" were in use. It's not too hard to make a guess at what a reasonable ordering should be, but I think the document should spell this out. > When the RES_USE_INET6 option is set, two changes occur: > > - gethostbyname(host) first calls gethostbyname2(host, AF_INET6) > looking for AAAA records, and if this fails it then calls > gethostbyname2(host, AF_INET) looking for A records. I'm a bit confused. Is the above saying that gethostname returns A records only if no AAAA records exist? I think this may be broken. If a host has both v4 and v6 addresses, it seems to me that gethostbyname() should return both types of addresses. This is important if some of the addresses aren't working. When opening TCP connections, for instance, an application is supposed to try all the addresses until if finds one that work. The above doesn't permit that. If none of the AAAA records work, the A records aren't tried (i.e., they weren't returned). > > - gethostbyname2(host, AF_INET) always returns IPv4-mapped IPv6 > addresses with the h_length member of the hostent structure set > to 16. Does it continue to also supply regular (non IPv4-mapped) AAAA addresses as well? (I suspect that it does, but it might help to add a sentence to that effect.) > struct hostent *gethostbyaddr(const char *src, int len, int af); > > One possible source of confusion is the handling of IPv4-mapped IPv6 > addresses and IPv4-compatible IPv6 addresses. Current thinking > involves the following logic: Not what is meant by "current thinking". Is this an open issue we need to nail down? Also, I found the "current thinking" rules confusing. Is this a proposal for what gethostbyaddr() should do? If so: > - If af is AF_INET6, and if len equals 16, and if the IPv6 address > is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6 > address, then skip over the first 12 bytes of the IPv6 address, > set af to AF_INET, and set len to 4. And then what, query the DNS for a PTR record? I think it might help to write this out as pseudo-code, or at least enumerated so that its clear what steps are executed in what circumstances. > The return value from the function is 0 upon success or a nonzero > error code. The following names are the nonzero error codes from > getaddrinfo(): And how do programmers know what (integer) codes map to which (string) errors? strerror()? > int getaddrinfo(const char *hostname, const char *servname, > const struct addrinfo *hints, > struct addrinfo **res); What happens if the user supplies hostname and servname, but in the hints section doesn't specific ai_socktype. Is this legal? What does the call return? I'm worried about the case where there are both UDP and TCP ports allocated to the same service name. Will the system pick one at random? If so, this won't promote portability (i.e., it works in my machine, I can't imagine why it doesn't on yours). Maybe we should say that a TCP connection is assumed if both UDP and TCP are valid and the caller didn't specify. Either that, or return an error. > structures. To return this information to the system the function > freeaddrinfo() is called: In light of the discussion about using free() to return storage obtained indirectly via another call (to the library), I'm surprised that we have a freeaddrinfo() but no freenameindex(). This doesn't seem consistent. Should we then go the whole nine yards and provide "free" routines for all the routines that return dynamically allocated storage? > int getnameinfo(const struct sockaddr *sa, size_t salen, > char *host, size_t hostlen, > char *serv, size_t servlen); Shouldn't the "char *host" and "char *serv" be "const" as well? > Note that this function does not know the protocol of the socket > address structure. Normally this is not a problem because the same > port is assigned to a given service for both TCP and UDP. But there > exist historical artifacts that violate this rule (e.g., ports 512, As others have noted, this is not true. The TCP and UDP port numbering spaces are independent. > The function does not > modify the buffer pointed to by dst if the conversion fails. The The above appears in at least two places. Is there any reason for this requirement? It seems like an implementation detail to me. Why would an application care? Why is that specified in the API? > const char *inet_ntop(int af, const void *src, > char *dst, size_t size); > will store the resulting text string. The size argument specifies > the size of this buffer. The application must specify a non-NULL dst > argument. For IPv6 addresses, the buffer must be at least 46-octets. > For IPv4 addresses, the buffer must be at least 16-octets. In order I don't understand why the size argument is included. Why isn't dst required to be "big enough" for the af. That's what the program should do anyway. There are other functions (e.g., if_indextoname(unsigned int ifindex, char *ifname)) that don't include a size argument. I don't have strong feelings as to which way is the right way to do things, but I don't much care for the inconsistency. Is there some rational I'm missing here? > For IPv4 addresses, the buffer must be at least 16-octets. In order > to allow applications to easily declare buffers of the proper size to > store IPv4 and IPv6 addresses in string form, implementations should > provide the following constants, made available to applications that > include : > > #define INET_ADDRSTRLEN 16 > #define INET6_ADDRSTRLEN 46 Any chance we can generalize that into a macro that takes "af" as an arg, and returns the number of bytes the af needs? Or has it been decided that the inet_* routines can't be made to work for types other than INET and INET6, so trying making the general is pointless? 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 Fri Dec 20 15:00:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24780; Fri, 20 Dec 96 15:00:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24774; Fri, 20 Dec 96 14:59:55 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA04769; Fri, 20 Dec 1996 14:51:59 -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 OAA16802 for ; Fri, 20 Dec 1996 14:52:00 -0800 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id OAA28201; Fri, 20 Dec 1996 14:51:23 -0800 Message-Id: <3.0.32.19961220144909.0077241c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 20 Dec 1996 14:49:17 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 2636) Updated IPng Web Pages Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just completed updating the IPng web pages. The URL is http://playground.sun.com/ipng It now includes info on the 6bone, new implementations, and updated pointers to specifications. I think I got all of the changes people sent me. If I missed yours, please let me know and I will add them. 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 Dec 20 15:37:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24832; Fri, 20 Dec 96 15:37:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24826; Fri, 20 Dec 96 15:37:14 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA13518; Fri, 20 Dec 1996 15:29:17 -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 PAA27945 for ; Fri, 20 Dec 1996 15:29:17 -0800 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id PAA29898; Fri, 20 Dec 1996 15:29:15 -0800 Message-Id: <3.0.32.19961220152614.0077a39c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 20 Dec 1996 15:26:56 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 2637) Interim IPng Working Group Meeting Cc: hinden@Ipsilon.COM, deering@cisco.com, deering@parc.xerox.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPng working group will hold an interim working group meeting on Feb 27 and 28, 1997 in the San Francisco bay area. his is the Thursday and Friday prior to the IPv6 testing at Connectethon. The meeting location and hotel information will be sent out in early January. The main agenda topic will be a detailed discussion on Mike O'Dells 8+8 proposal. This is described in which can be found in the internet draft directories. Please RSVP so we can make sure the meeting facility is adequate. We hope to also have the meeting broadcast on the MBONE. Bob Hinden / Steve Deering IPng Working Group Co-Chairs ------------------------------------------------------------------------------ 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 Dec 20 17:49:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25075; Fri, 20 Dec 96 17:49:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25069; Fri, 20 Dec 96 17:49:23 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA05929; Fri, 20 Dec 1996 17:41:28 -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 RAA28343 for ; Fri, 20 Dec 1996 17:41:28 -0800 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id RAA04405; Fri, 20 Dec 1996 17:41:26 -0800 Message-Id: <3.0.32.19961220173842.00724ff0@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 20 Dec 1996 17:38:46 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 2638) IPng Working Group Minutes Cc: hinden@Ipsilon.COM, minutes@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_851161126==_" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --=====================_851161126==_ Content-Type: text/plain; charset="us-ascii" Attached are the minutes from last weeks IPng meeting. Please send me corrections and I will update. I would also like wish everyone a Happy Holiday! Bob _______________________cut here_______________________________________ --=====================_851161126==_ Content-Type: text/plain; charset="us-ascii" IPng Working Group Meeting December 1996 IETF San Jose, CA Robert Hinden / Ipsilon Networks Steve Deering / Cisco Systems Co-Chairs Minutes taken by Robert Hinden -------------------------------------------------------------------- Agenda -------------------------------------------------------------------- Monday 1:00-3:00pm Introduction and Bash Agenda / Steve Deering (5 min) Document Status / Bob Hinden (10 min) ITU Addressing Request Status / Bob Hinden (1 min) Priority Field / Steve Deering (10 min) Default Hop Limit / Steve Deering (10 min) IPv6 over Token Ring (10 min) BSD API / Bob Gilligan (10 min) Simple IPsec API / Dan McDonald (5 min) Advanced API spec / Matt Thomas (15 min) Tunneling Spec / Alex Conta (10 min) Header Compression spec / Micke Degermark (10 min) Host Anycast / Jim Bound (10 min) IPv6 Multicast Address Assignment draft / Bob Hinden (5 min) Monday 7:30-10:00pm 8+8 Addressing Proposal / Mike O'Dell (45 min) Alternative Addressing Architectures / Masataka Ohta (5 min) Multihoming / Source Address Selection / Steve Deering (30 min) Interface ID Proposal / Steve Deering (20 min) IPv6 MIB / Dimitry Haskin (15 min) Thursday 1:00-3:00pm IPSEC Report on UNH Interoperability Event 8+8 Proposal Router Alert Option / Ran Atkinson (10 min) Moving Base IPv6 Specs to Draft Standard / Steve Deering (30 min) IPv6 Packets over IPv4 Networks without Tunnels / Brian Carpenter (15 min) Multicast Routing / Thomas Narten (10 min) Router and Network Renumbering / Geert Jan De Groot & Bob Hinden Inter-Domain Routing (IDRP, BGP5, ?) / Bob Hinden (10 min) Address Prefix Notation / Alain Durand (5 min) Unspecified Address in Neighbor Discovery (5 min) ------------------------------------------------------------------ Introduction and Bash Agenda / Steve Deering ------------------------------------------------------------------ Steve Deering introduced the meeting. He said he now works for the "borg" (e.g., Cisco systems). He introduced Bob Hinden from Ipsilon Networks (who said had not been assimilated (yet)). Summarized sessions and 6bone BOF. Reviewed agenda. Asked for additional or removal of agenda items. Question was raised about discussing TAG switching use of IPv6 flow label. Deering said depends on outcome of Tag switching BOF. Short report on a new implementation of IPv6 for Linux, done at INRIA, and to be available for research use. It was announced by Jean Bolot. Further info can be found at http://www.inria.fr/rodeo/IPv6/ ------------------------------------------------ Document Status / Bob Hinden ------------------------------------------------ The following RFC's were published with Proposed Standard status: - RFC1970, Neighbor Discovery for IP Version 6 (IPv6) - RFC1971, IPv6 Stateless Address Autoconfiguration - RFC1981, Path MTU Discovery for IP version 6 - RFC2019, A Method for the Transmission of IPv6 Packets over FDDI Networks - RFC2023, IP Version 6 over PPP The following RFC's were published with Experimental status: - RFC1888, OSI NSAPs and IPv6 The following document was advanced to Proposed Standard by the IESG (but has not been published as an RFC yet): - An IPv6 Provider-Based Unicast Address Format ------------------------------------------------ ITU Addressing Request Status / Bob Hinden ------------------------------------------------ Hinden reported that he had not done this yet, but would do it prior to the Thursday IPng session. He did complete this by the Thursday session. The reply is included here. Internet Engineering Task Force IP Next Generation Working Group December 11, 1996 Mr. H. V. Bartine AT&T Bell Labs, Room 4K-316 101 Crawfords Corner Road Holmdel, NJ 07733-3030 Subject: Response to ITU SG 7 Request for IPv6 Addressing Code Point The IETF received a request from ITU-Telecommunication Standardization Sector STUDY GROUP 17, Rapporteur Q3/7 on 17 July 1995. The ITU requested an IPv6 Format Prefix for X.121 Public Data Network Addresses. It also suggested that ITU-T Study Group 2 may also make a similar request for E.164 addresses. The IP Next Generation working group of the IETF discussed the request at the working group meeting held on June 24, 1996 in Montreal. The working group concluded that X.121 Public Network addresses are not Internetwork addresses and that a Format Prefix (code point) was not warranted at this time. Consequentially the working group concluded that a better approach would be to treat the X.121 addresses in a manner similar to how IPv6 runs other networks technologies such as Ethernet, FDDI, Token Ring, etc. A definition of interface identifiers from the X.121 addresses should be created. The BCD digits of the X.121 address would be converted to binary and used as an Interface Identifier. An IPv6 over X.121 Public Data Networks document could be written in a manner similar to RFC1972 "A Method for the Transmission of IPv6 Packets over Ethernet Networks" or RFC-2019 "Transmission of IPv6 Packets Over FDDI". This approach would be compatible with the IPv6 control functions as defined in RFC-1970 "Neighbor Discovery for IP Version 6 (IPv6)". It would also support the creation of small independent subnetworks (e.g., clouds) in the X.121 Public Data Networks instead a single very large subnetwork. At the working group meeting an alternative approach was also suggested that would make use of the AFI for X.121 addresses in the NSAP addressing plan. This would fit into the framework defined in RFC-1888 "OSI NSAPs and IPv6". This alternative provides another approach to support running IPv6 over public networks that use X.121 addressing. The IPng working group would also like to invite representatives from ITU-T SG7 to attend the next IETF meeting and to present the IP Next Generation working group their thoughts on how IPv6 could be run over the public data networks. We look forward to your response in this manner. Contact Person: Robert M. Hinden Ipsilon Networks, Inc. 232 Java Drive Sunnyvale, CA 94089 TEL: +1 408 990-2004 email: hinden@ipsilon.com ------------------------------------------------ Priority Field / Steve Deering ------------------------------------------------ Deering proposed at the Montreal meeting to change the definition of the priority field and make it reserved. The original intent was to: - Generalized "drop-preference" provides the wrong incentive, encourages sending packet that won't be delivered - Potential other uses for those bits (e.g., "RED" bit, Clark's in/out-of-profile bit, ISP-private use. This proposal was disliked by people who want to favor interactive traffic over dialup or wireless links. Steve Deering proposed a new definition: - Declare that 4 bits of Priority are rewritable by routers/ISPs for private purposes (and exclude from authentication header). - Priority bits have no significance to receivers - Convention: Sender sets low order bit to mean interactive traffic. o Delay more important than throughput o Suggests that routers/ISPs use other bits before touching the "interactive bit". o Affects queuing only, not routing (since re-writable). Deering will write up as a email message and send to list. ------------------------------------------------ Default Hop Limit / Steve Deering ------------------------------------------------ At last meeting we discussed a proposal to make default hop limit to 256. Discussion on mailing list came to conclusion that 64 would be better choice. Deering proposed that we make this the default value. Working group agreed to 64. Document editor will send email to IANA to add this parameter to IANA registry for IPv6 defaults. Christian Huitema suggested that routers should not advertise any default hop limit value without being explicitly configured. Discussion. There was not a consensus reached on this topic. Will be discussed further on the email list. ------------------------------------------------ IPv6 over Token Ring / Bob Hinden ------------------------------------------------ Bob Hinden discussed remaining issues with "IPv6 over Token Ring" draft. The main issues are how to handle mixed media bridging and token ring source routing. Conclusion was to add section describing how to handle mixed media bridging. Main issue is the selection of MTU. Default (without any configuration) should be 1500. There may not be perfect solutions but it important to document issue so device can be configured correctly. Does token ring source route takes up space in packet, so MTU becomes smaller. Thomas Narten offered to own getting these issues resolved and getting a new version of the draft. A working group last call will be done when this ID is out. ------------------------------------------------ BSD API / Bob Gilligan ------------------------------------------------ Rich Stevens is now co-author. Split advanced features to a separate document. Changes from previous version include: - Added section on interface identification (in sync w/ Advanced API spec). - Change multicast setsockopt() options to use interface identifiers. Previously used IPv6 addresses which do not work in all cases. - Added descriptions of gethostbyname(), gethostbyname2(), and resolver options. This matches the new version of bind (4.9.4). - Posix-free description of getaddrinfo() to match Posix 1003.1g (but Posix is definitive spec) - Added description of getnameinfo(). This is inverse function to getaddrinfo(), not in Posix 1003.1ga - Renamed inet6_isipv4addr() to inet6_isipv4mapped() to make name more clearly describe function. - Small working clarifications. Gilligan commented that change the priority field definition would require this specification to change too. Document editor will do a working group last call on this document. Goal is to publish an informational RFC. ------------------------------------------------ Simple IPsec API / Dan McDonald ------------------------------------------------ IPsec is mandatory to implement in IPv6. Reviewed basic concepts of IPsec functions and terminology. Summarized API functions: - All socket options are at the IPPROTO_IP or IPPROT_IPV6 level. - Categories are the actual options to be set are IP{,V6}_AUTH_LEVEL, IP{,V6}_ESP_TRANS_LEVEL, and IP{,V6}_ESP_NETWORK_LEVEL - Levels are the values for IPSEC_LEVEL_NONE, IPSEC_LEVEL_AVAL, IPSEC_LEVEL_USE, IPSEC_LEVEL_REQUIRE, IPSEC_LEVEL_UNNIQUE - Need one additional level for special apps. Change terminology to call it "payload" instead of "transport" because it may not always be a transport protocol. This work is being done in IPsec group and will be advanced there. ------------------------------------------------ Advanced API spec / Matt Thomas ------------------------------------------------ Check if w.g. is happy with advanced API spec. Matt poised several questions to the working group: - Scope. Would be nice to extend definition of scope to extend. - Does WINSOC copy this work? Not too much. This follows POSIX, WINSOC does not. - Neither API doc has any mechanism to set the "flow id". Think it belongs in this API doc or one of the other API documents. Deering thought this would be correct place to put it. There needs to be a kernel function to pick flow labels inorder to make they don't collide. Matt Crawford offered to help add this. - Should there be a mechanism to retrieve routing table information (e.g., routing socket). Comment was made that this is beyond scope of this specification. Should be in another document. ------------------------------------------------ Tunneling Spec / Alex Conta ------------------------------------------------ Changes since last version: - Replace term recursive tunneling with nested tunneling. - Add text to ICMP related to nested tunneling packets. - Clarify that refers to point-to-point tunnels only. - IPv6 tunnels must end in a unicast address. - Clarified security section to discuss use of security headers and how they are processed. - Clarified usage of ICMP packet too big to max (576, tunnel MTU). - Typos fixed and other small changes. Would like to forward to IESG. No one had any objections to moving this document forward. Document editor will submit to IESG for a proposed standard. ------------------------------------------------ Header Compression spec / Micke Degermark ------------------------------------------------ Changes from previous version (v01->v02) - Packet types FULL HEADER, COMPRESSED_NON_TO, COMPRESSED_TCP, COMPRESSED_TCP_MODELTA - Use of length fields - UDP checksum not sent when zero - 0-bit in TCP change mask. TIMPSTAMP options ruins compression otherwise. When OPTIONS change, set 0-bit and send whole OPTION. - Header request (for TCP) - Hook for passing sequence numbers by additional header compression on top of UDP. - Small changes to demultiplexing procedure - Defined the ranges of configuration. parameters. Believes that point-to-point mechanisms are stable now and would like the draft to go to proposed standard. CRTP draft relies on this draft. There are still problems on multi-access networks. Will a separate document be issued. Yes, but additional problems need to be solved. There is now an implementation on BSD. Document editor will do a working group last call. ------------------------------------------------ Host Anycast / Jim Bound ------------------------------------------------ Need for host anycast addresses to support cluster type of technology, load balancing for servers, and need to support distributed process migration. Also support dynamic address reassignment for an existing network connection for both TCP and UDP. Support multilink and multihoming dynamic address changes. Support for nomadic computing. Proposes to: - Add "p" bit to mobile binding Update IPv6 destination option - Use the replay protection and security inherent in IPv6 mobility specification. - Define the enhancements needed for implementations Deering asked how these would be routed? Need to define ICMP extensions to handle of routing of host anycast addresses. Discussion about need for specifying routing behavior. ------------------------------------------------ IPv6 Multicast Address Assignment draft / Bob Hinden ------------------------------------------------ Published an internet draft with initial fleshed out IPv6 multicast address assignments. Intent is to send this to IANA as initial list of addresses to be published. One issue raised by this document is that except for Neighbor Discovery solicited node addresses, all of the other multicast address assignments fit into the low order 32 bits of the IPv6 multicast address. This lead to a discussion about 1:1 mapping between multicast addresses and MAC addresses. Discussion about alternative of expanding address space to include ND solicited node address or to shrinking it to not conflict with other multicast mappings. Hinden and Deering will propose to the mailing list that the ND solicited node address be changed to fit into a longer prefix (reduce the unique part to fit into less than 32 bits) --------------------------------------------------------- Monday 7:30-10:00pm --------------------------------------------------------- --------------------------------------------------------- 8+8 Addressing Proposal / Mike O'Dell --------------------------------------------------------- Motivations - IPv6 gives us a bigger version of a problem we currently don't solve - Need aggressive topological aggregation going forward - CIDRv6 isn't the answer for several reasons o CIDR efficiency decays over time o Multihomming is become more and more prevalent o Forced renumbering will succumb to market pressure (e.g., won't happen) Origins of the Proposal - Old idea , Doesn't claim to invent. - XNS certainly had the locator and identifier idea - IPv4 went the other way - Personally believes that XNS got it right - Others have discussed this before in IPng discussions - This work was catalyzed by an email from Dave Clark Important Notions - Split address into two pieces - One part reflects topological attachment to the Global Internet - One part is topologically-invariant, known as an "End System Designator" or ESD - Current proposal divides the 16 bytes in half, hence "8+8" - Strong distinction between "public topology" and "private topology" - The site is the fundamental unit of attachment to the global internet. - Large Structures, fundamental large-scale aggregation object - Deep equivalence of rehoming and multihoming (Fall back to alternate path is a type of rehoming). - Provides for transparent rehoming of Sites and Resellers o End tyranny of CIDR - Make multihoming an explicit service o Upstream providers have to do something explicit to heal failures. o Users pay for it. - Dynamic Insertion of Routing Goop by border routers o End systems don't usually have to know own routing goop o Certainly "can" know it, but site border routers can impose exit policy - Upward delegation of DNS o Automatic propagation of Routing Goop for Site-external resolution provides for easy delegation of IN-ADDR.APRA inverse lookups End System Designators Properties (ESD's) - Globally Unique (but no more than IPv4, IEEE MAC is good enough) - Designates an End System interface - real or virtual - End systems may be designated by multiple ESD's - An ESD may not necessarily designate a particular physical computer o Neighbor discovery provides for virtual address translation o Service location possibilities - ESD's are not guaranteed to be perfectly time-invariant o Altered only by some site internal topology changes Structure of ESD's - 15 bits of Private topology partition 32,768 distinct partitions in the private topology Population of each partition limited by IEEE MAC address space - 1 Mode bit determines format of 48 bit identity token 0 implies 48 bit MAC address 1 implies top bits of identity token imply subtype - 48 bit identity token Mode 0 : IEEE MAC 48 bit address Mode 1 : 45 IETF Node ID which is densely assigned Mode 2 : Identity token is officially assigned, nor RFC1918 IPv4 address, right justified, zero padded - Other values reserved Structures for Sites - Sites can be very large and complex. - Sites are cheap, so needing more than one isn't really a hardship - Lots of topology design options - Public topology transit networks can also be sites - PTP provides for network-internal designations of elements which are part of public topology Routing Goop - RG is hierarchical locator - Forest of spanning trees with flat-routed between root of the trees - Conceptually flows outward from the originating large structure Questions is this different from CIDR? Yes and no. Comment that this this needs a different/better description. Very hard to understand in it's current form. Long discussion. No clear outcome. - Provides a framework for allowing the network to self organize - Large Structures encapsulate significant topological aggregation o Intentionally not a lot of them, only 14 bits allocated for LSID o Limit worst-case flat-routing for top-level region o Provide "routes of last resort" for default-free routers Next version of document will be clearer and simpler. Mike O'Dell thought it would be 6+2+8. Long discussion. Many questions. Chairs will make a decision on how to proceed. --------------------------------------------------------- Alternative Addressing Architectures / Masataka Ohta --------------------------------------------------------- Complete Separation between Locators and ID | 64bits | 64bits | +---------------------+----------------------+ | ILOC | IID | +---------------------+----------------------+ ^ ^ | | Locate (structurally subnet) | in the global internet | | Identify a host with global Internet Wrote ID a year ago that is available at: ftp://ftp.jain.ad.jp/pub/ids/draft-ohta-ipv6-addr-arch-00.txt Problem with Mikes 8+8 - ID's have no hierarchical structure - 48 bits are not enough for globally unique ID Warts with Site Renumbering - The locator of the hosts in the site changes - Intra-site topology is unaffected - Global unique ID which depends on site local topology is fine Warts with Mobility and Multicast - Encapsulation (MTU) - Subnet model at foreign subnet - Multicast addresses are location independent - IDs must be globally unique independent of site local topology Topology Independent ID - Removes mobility warts - Removes multicast warts - Enables full process migration - Enables site renumbering, of course. - Thus, is the way to go. Discussion comparing this proposal with 8+8. Conclusion is that they are very similar. Deering concluded that there could be separation between global info, site info, and identifier. ------------------------------------------------------- Multihoming / Source Address Selection / Steve Deering ------------------------------------------------------- There was much discussion of this topic on the mailing list over the past few months. Deering presented a particular model of a multihomed host, in which interfaces are grouped by links, links are grouped by sites, and sites are grouped into the global scope. Discussed the weak and strong models of multihomed hosts: - strong: (1) a host must not send a packet whose source address does not belong to the origination interface. (2) a host must not accept a packet whose destination address does not belong to the arrival interface. - weak: (1) a host may send a packet whose source address belongs to any interface on that host. (2) a host may accept a packet whose destination address belongs to any interface on that host. Multicast uses strong model -- necessary for source-sensitive multicast routing, and to avoid duplicate reception. Concludes that unicast SHOULD use weak model, but with source-address selection rules that ensure that source address differs from origination interface address only in unusual circumstances, e.g., when responding to a ping of a receive-only interface. Noted that the weak model is "less weak" in IPv6 than in IPv4 -- even in the weak model, must not violate IPv6 address scope constraints (link-local, site-local). However, this does *not* mean that source and destination addresses must have the same scope, and Deering recommended not adopting such an unnecessary constraint. Strong support for weak addressing model with strong scoping rules. Expects to have a draft in early part of new year. --------------------------------------------------------- Interface ID Proposal / Steve Deering --------------------------------------------------------- Discussion on KRE's draft. Now that current API drafts don't use addresses to identify interfaces, this may not be needed. Discussion. Deering took poll. No one supported keeping proposal. It will not be moved forward. --------------------------------------------------------- IPv6 MIB / Dimitry Haskin --------------------------------------------------------- Updated MIB2 to IPv6. Allows to implement IPv6 MIB without requiring any changes to the SNMPv2 SMI and compliant SNMP implementations. Drawback: IPv6 address as an instance-identifier uses 16 sub-identifiers. IPv6 (network layer) interface identification - An 32 bit integer in the 1 to 2147483647 range IPv6 MIB Groups - IPv6 General - ICMPv6 - UDP for IPv6 - TCP for IPv6 IPv6 General Group - ipv6IfTable - Info on entity IPv6 interfaces - ipv6IfStatsTable - Info on traffic statistics - ipv6AddrPrefixTable - Info on address prefixes that are associated with the IPv6 interfaces. - ipv6AddrTable - Addressing information relevant to the entity's IPv6 interfaces - ipv6RouteTable - Contains an entry for each valid IPv6 unicast route - ipv6NetToMediaTable - IPv6 address to media address equivalencies ICMP, UDP, TCP groups contain info on protocols, changed to include IPv6 addresses. --------------------------------------------------------------- Thursday 1:00-3:00pm --------------------------------------------------------------- --------------------------------------------------------------- Router Alert Option --------------------------------------------------------------- Discussed briefly and group agreed to do a working group last call. --------------------------------------------------------------- IPSEC --------------------------------------------------------------- Heard rumor that IPSEC w.g. was considering changing IPSEC to not include the flow label. Working group thought that it was important that this change be discussed in the IPng working group prior to any change in IPSEC. --------------------------------------------------------------- Report on UNH Interoperability Event --------------------------------------------------------------- Tested base spec, neighbor discovery, routing, MTU path discovery, applications, and tunneling Participants included: DEC, SUN, HP, IBM, Bay Networks, Cisco Systems, WIDE, FTP Software, Sumitomo ,Fujitsu, Hitachi, and INRIA. Most implementations supported basic specifications, neighbor discovery was supported by 2/3 of participants. Serious problems were found less than 1/4 of participants. Future plans for IPv6 testing will be IPv6 testing at Connectatheon 1997 (March 1-6, 1997) and Network+Interop - Las Vegas (first week of May 1997). --------------------------------------------------------------- Moving Base IPv6 Specs to Draft Standard / Steve Deering --------------------------------------------------------------- Discussed whether w.g. thought we should advance basic protocols to Draft Standard. Mentioned that we will have to show evidence of implementations of all features. Question about impact of 8+8 proposal. Chairs agreed to generate a list of changes which are being considered to the basic specifications. --------------------------------------------------------------- 8+8 Proposal --------------------------------------------------------------- Chairs proposed to allocate a Format Prefix for 8+8 addresses. Implementations would have special pseudo checksum rules for this FP. Would allow us to experiment with 8+8 without making a final commitment. Discussion about impact of using 8+8 proposal on various parts of IPv6 architecture. Issues raised include: - IPv6 over Foo - DHCP impact - TCP pseudo checksum calculation - DNS changes - How routers would put new "Routing Goop" in addresses - Size of identifier - Are MAC addresses used as identifiers are globally unique Chairs proposed to hold a interim meeting before the next IETF to discuss 8+8 in more detail. Working group agreed. Details to be announced on mailing list. ----------------------------------------------------------------- IPv6 Packets over IPv4 Networks without Tunnels / Brian Carpenter ----------------------------------------------------------------- Brian Carpenter presented an overview of the draft written by Cyndi Jung and himself. The basic notion is to use an IPv4 multicast network as a local link for IPv6. Isolated IPv6 host just runs, it does not need a configured tunnel or IPv4 compatible addresses. MTU size default is 1480 (1500 - IPv4 header size). Router advertisements can change this. Alternative is to use "local IPv4 MTU" minus "local IPv4 header size". Probably not necessary because 1480 is likely to work over most multicast links. Comment multicast may be running over tunnel so 1460 might be better. Frame format shows IPv4 header over an IPv6 header. Proposes New protocol identifier to identify these packets. Comment that this may not be necessary. Link local address. Stateless autoconfig works as normal. Suggest normal 80 bit prefix FE80::. Use zero padded IPv4 address of host as 48 bit token. This seems more consistent than using 96 bit prefix and 32 bit token. Could easily be adapted to 8+8 token. Address Mapping: - Unicast : Neighbor discovery conveys IPv4 address around as link layer address. - Multicast: Use last 3 bytes of IPv6 multicast address as the last 3 bytes of IPv4 (pseudo link layer) multicast address. If no IPv4 multicast support, there is a possible kludge using IPv4 broadcast. - Another proposal (Steve Deering) would be to configure host with IPv6 host with unicast address of IPv6 router and run ND over this tunnel. Issues: - Pad to 64 bit align the IPv6 header - MTU = 1480 - IPv4 TTL - Token Length (32 or 48) - Drop the broadcast kludge - Drop the NBNA note - Enumerate multicast groups for ND - Define scaling limits The working group encouraged the authors to revise the draft and to continue discussion in the ngtrans working group. ---------------------------------------------------------------- Multicast Routing / Thomas Narten ---------------------------------------------------------------- Asked if we know what we are doing with multicast routing. Deering answered that he needs to write a document on how to generically (e.g. protocol independent) handle Multicast routing Deering mentioned that the decision was made to not port DVMRP to IPv6 because the plan it that unicast and multicast routing topologies should be the same. We should concentrate on multicast routing protocols that utilize the unicast routing table. PIM Dense and Sparse mode currently handle IPv4 and IPv6 multicast. Today people should use PIM for IPv6 multicast routing. ---------------------------------------------------------------- Router and Network Renumbering / Geert Jan De Groot & Bob Hinden ---------------------------------------------------------------- Geert Jan De Groot ------------------ We have auto configuration, but can't renumber routers automatically. Routers are still configured manually. Will network really be able to be renumbered. Renumbering is needed. Customers changing ISP's should not result in additional prefix. ISP changing transit provider should have minimal effect on customers (next level provider). Topology changes may make renumbering needed. The number of routing prefixes is the most important issues in the operation of the Internet. Also, Pilot-sites are asking for real address now to avoid having to renumber. Currently the are about 40,000 prefixes. There are 1800 autonomous systems. There are only 1800 routing policies. Ideally there should only one prefix per AS. Need some time of prefix redistribution mechanisms. Also need to work on Pier problem (IP addresses in configuration files, etc.). Bob Hinden ----------- Background - Neighbor Discovery Provides Mechanisms to Assign Prefixes to Nodes and Add / Delete Prefixes for Nodes - Currently Routers Must be Configured with Interface Specific Prefix Information - Missing Piece is how to Configure Routers Automatically Router Renumbering - Internet Wide Router Renumbering o Too Scary o Focus on Site - Functions Needed o Initial Configuration o Assign Prefixes (+ related parameters) to Interfaces o Change Configuration o Change Prefixes on Interfaces o Delete Prefixes on Interfaces o Work after Site Partition (e.g., Healing) Basic Mechanism - Periodic Multicast (~1-5 minutes) of Router Renumbering (RR) Advertisement o All Routers in Site process RR Advertisements o Authentication is Very Desirable - Two Multicast Addresses (with site scope) o Router Renumbering Advertisement Address o Router Renumbering Solicitation Address - Router can Solicit RR Advertisement by sending RR Solicitation to RR Solicitation Multicast Address o When Needs Prefixes or Prefixes timeout o When Partitioned is healed RR Advertisement - Contains One or More Sets of RR Info Each Set Contains: o Operator o "A" Prefix (128 bits) and Prefix Length (8 bits) o "B" Prefix (128 bits) and Prefix Length (8 bits) o Parameters o Lifetime o Precedence o Max Hop Limit o Other ? Operators - Add: On Interfaces that Match "A" Prefix / Length Add "B" Prefix / Length / Parameters - Change: On Interfaces that Match "A" Prefix / Length Change to "B" Prefix / Length / Parameters - Delete: Delete Prefix ("A") (and Parameters) from Interfaces which Match "A" Prefix / Length Misc - RR Advertisement also includes a Sequence Number o Increment Sequence Number when Contents Change o Receivers can ignore Duplicates Issues - Should RR be Used to Do Initial Interface Prefix Assignment? - Would "Current Prefix State" Messages be Simpler than Change State Operators? - Relationship to 8+8 Proposal? Summary - Proposal would Make it very Easy to Add New Global Prefix to Site o Add Operation with Match on Constant Part of Prefix on all Interfaces - Change and Delete also Easy - Supports Individual Interface Changes o Match on Link Local Interface Address with Prefix / Length (128) There was general interest in pursuing this work. An internet draft will be written. ------------------------------------------------- Inter-Domain Routing (IDRP, BGP5, ?) / Bob Hinden ------------------------------------------------- Hinden raised the issue that there was not very much progress on implementations of IDRP for IPv6. He mentioned that he had heard from ISP's that they did not want to deploy IDRP and would prefer an update to BGP. Joel Halpern added that the plan in the routing area was to not do another version of BGP. IGRP was to be the replacement for BGP. Dave Katz suggest that it would be very easy to add options to BGP4 to carry IPv6 interdomain routes. Dimitry Haskin said it would be very easy (two weeks work) to do this in his implementation, where doing IDRP would be a major effort. Working group thought this would be a good thing to pursue. Dimitry and Dave agreed to write up a proposal. ---------------------------------------------------------------- Address Prefix Notation / Alain Durand ---------------------------------------------------------------- Raised issue with how IPv6 addresses with prefixes should be written. Currently in the RIPE registry they are not being written consistently. Examples ::/96 FED0::/80 5F06:B500:/32 This needs to be added to the next version of the addressing architecture document. Will be added to list of changes for this document. ---------------------------------------------------------------- Unspecified Address in Neighbor Discovery / Dan Harrington ---------------------------------------------------------------- Use of unspecified address as source address is only defined for DAD, using multicast destination address (network + link). Should expand ND input packet validation rules to silently drop such packets. Group agreed to change this in next version of ND. ---------------------------------------------------------------- Tag Switching use of Flow Label ---------------------------------------------------------------- No one attended the meeting who wanted to talk about this. The working group said it was important that any proposal for changing the definition of the IPv6 flow label should be done here. The decision to change the semantics of the IPv6 flow label belongs to the IPv6 working group. ---------------------------------------------------------------- Mobile IP Request / Charlie Perkins ---------------------------------------------------------------- Mobile IP for IPv6 would like to be able to send a request to use an anycast cast address to all IPv6 mobile IP home agents. Approach is to tunnel to an anycast address for home agents with the inter packet addressed to the All Home Agents multicast destination with link scope. +---------------------+-----------------+ | Anycast | Multicast | +---------------------+-----------------+ | Subnet prefix + 000 | All Home Agents | With Hop limit = 1 Discussion about requiring all IPv6 routers to support mobile IP. Could also be done by allowing tunnels to be created to anycast address (which is not supported in current draft). The result of this discussion was to modify the tunneling draft to permit tunnels to be set up to anycast addresses to handle this function. ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- --=====================_851161126==_-- ------------------------------------------------------------------------------ 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 Dec 20 21:54:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25319; Fri, 20 Dec 96 21:54:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25313; Fri, 20 Dec 96 21:54:23 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA23901; Fri, 20 Dec 1996 21:46:28 -0800 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA25700 for ; Fri, 20 Dec 1996 21:46:27 -0800 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.7.3/8.7.3) with ESMTP id AAA01642; Sat, 21 Dec 1996 00:43:50 -0500 (EST) Message-Id: <199612210543.AAA01642@brookfield.ans.net> To: bmanning@isi.edu Cc: dhaskin@baynetworks.com (Dimitry Haskin), ipng@sunroof.eng.sun.com, bgp@ans.net Reply-To: curtis@ans.net Subject: (IPng 2639) Re: larger AS/RD space for v6? In-Reply-To: Your message of "Fri, 20 Dec 1996 08:20:12 PST." <199612201620.AA22085@zed.isi.edu> Date: Sat, 21 Dec 1996 00:43:49 -0500 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199612201620.AA22085@zed.isi.edu>, bmanning@isi.edu writes: > > There was a discussion on the IDR list to whether a larger than a 2-byte > > AS/RD number space is needed to for IPv6. The discution was prompted by > > a BGP4+ proposal for v6. I'd like to solicit input from a larger > > IPv6-minded audience on this subgect. > > BGP4+ should be IDRP and use RDIs. > -- > --bill Simple solutions that work are a good thing. IDRP has too much baggage along with the improvements and so its gone absolutely nowhere. Lets just forget IDRP and fix BGP4 so IPv6 can have a deployable exterior routing protocol. Curtis ------------------------------------------------------------------------------ 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 Dec 21 00:39:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25391; Sat, 21 Dec 96 00:39:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25377; Sat, 21 Dec 96 00:39:07 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA01829; Sat, 21 Dec 1996 00:30:53 -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 AAA08437 for ; Sat, 21 Dec 1996 00:30:53 -0800 From: Masataka Ohta Message-Id: <199612210829.RAA01763@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA01763; Sat, 21 Dec 1996 17:29:03 +0900 Subject: (IPng 2640) Re: larger AS/RD space for v6? To: jhalpern@us.newbridge.com (Joel Halpern) Date: Sat, 21 Dec 96 17:29:03 JST Cc: ipng@sunroof.eng.sun.com, dhaskin@BayNetworks.COM, bgp@ans.net In-Reply-To: <9612201923.AA26127@lobster.nni>; from "Joel Halpern" at Dec 20, 96 2:23 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I will note that some people are concernedrelative to the 8+8 proposal > that either 14 bits may not be enough space for the top, or that 45 bits > may not be enough for the full provider heirarchy. While the presence of > heirarchy will allow some reuse of policy identification (AS) space, I > would hate to be too heavily dependent on that. If we need thousands > of top level entities, and absurd numbers of "ISP"s with policy, it would > seem likely to me that at some point we will need more than 16 bits worth > of policy space identifier. > When will we need that is definitely an open question. ??? I'm totally confused. With provider based hierarchical addressing, RFC 1887 or 8+8, the address itself identifies a group of routes. So, why do we need things like ASes? Masataka Ohta ------------------------------------------------------------------------------ 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 Dec 21 05:38:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25662; Sat, 21 Dec 96 05:38:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25656; Sat, 21 Dec 96 05:38:08 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA10724; Sat, 21 Dec 1996 05:30:10 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA01546 for ; Sat, 21 Dec 1996 05:30:12 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQbvba02934; Sat, 21 Dec 1996 08:30:02 -0500 (EST) Message-Id: To: Masataka Ohta Cc: jhalpern@us.newbridge.com (Joel Halpern), ipng@sunroof.eng.sun.com, dhaskin@BayNetworks.COM, bgp@ans.net, mo@UU.NET Subject: (IPng 2641) Re: why do we need ASes?? In-Reply-To: Your message of "Sat, 21 Dec 1996 17:29:03 +0200." <199612210829.RAA01763@necom830.hpcl.titech.ac.jp> Date: Sat, 21 Dec 1996 08:30:02 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk because the AS identifies the injecting administrative domain and policy exchange is based on that. i actually thought hard about this in the 8+8 proposal and you really want to keep an independent identifier for the administrative domain distinct from the topology. "different kind of thing, different kind of name" -mo ------------------------------------------------------------------------------ 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 Dec 21 10:59:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25773; Sat, 21 Dec 96 10:59:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25767; Sat, 21 Dec 96 10:59:31 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA22558; Sat, 21 Dec 1996 10:51:33 -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 KAA27641 for ; Sat, 21 Dec 1996 10:51:35 -0800 Received: from rtpdce02.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA94400; Sat, 21 Dec 1996 13:49:07 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce02.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id NAA35048; Sat, 21 Dec 1996 13:49:05 -0500 Received: from [32.224.57.2] by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21006; Sat, 21 Dec 1996 13:51:14 -0500 Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id JAA00597; Sat, 21 Dec 1996 09:51:10 -0500 Message-Id: <199612211451.JAA00597@hygro.raleigh.ibm.com> To: "Peder Chr. Norgaard" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2642) Re: IPv6 and PPP - discussing randomly chosen interface tokens In-Reply-To: Your message of "Fri, 20 Dec 1996 18:14:27 +0100." Date: Sat, 21 Dec 1996 09:51:10 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Why? Because I cannot see why it is a good idea that addresses on PPP >lines change every time the line goes down. Please recall that >interface tokens in the future IPv6 world with renumbering are not >only used for link-local addresses; they are also intended to form the >basis for the generation of global scope addresses. Should every line >fall-out make it necessary for the communication nodes to feed new >addresses back into DNS? I agree strongly with this. In the absence of a compelling motivation on PPP's part, we should strive to avoid protocols/policies that have a potential for generating spurious DNS updates. DNS updates are *not* cheap, and likely never will be. This is especially true if DNS updates may happen at a moment's notice, which in effect requires DNS cache TTLs to be zero so that nobody ever caches an address that could become invalid at any time. 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 Sun Dec 22 01:03:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26214; Sun, 22 Dec 96 01:03:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26208; Sun, 22 Dec 96 01:03:12 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA23055; Sun, 22 Dec 1996 00:55:15 -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 AAA19690 for ; Sun, 22 Dec 1996 00:55:11 -0800 From: Masataka Ohta Message-Id: <199612220853.RAA03074@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA03074; Sun, 22 Dec 1996 17:53:19 +0900 Subject: (IPng 2643) Re: why do we need ASes?? To: mo@UU.NET (Mike O'Dell) Date: Sun, 22 Dec 96 17:53:19 JST Cc: mohta@necom830.hpcl.titech.ac.jp, jhalpern@us.newbridge.com, ipng@sunroof.eng.sun.com, dhaskin@BayNetworks.COM, bgp@ans.net, mo@UU.NET In-Reply-To: ; from "Mike O'Dell" at Dec 21, 96 8:30 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > because the AS identifies the injecting administrative domain and > policy exchange is based on that. i actually thought hard about > this in the 8+8 proposal and you really want to keep an independent > identifier for the administrative domain distinct from the topology. Are there any AS which is not contiguous today? > "different kind of thing, different kind of name" It seems to me that the difference is in the IP version number. Masataka Ohta ------------------------------------------------------------------------------ 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 Dec 22 06:50:14 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26372; Sun, 22 Dec 96 06:50:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26366; Sun, 22 Dec 96 06:50:02 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA00858; Sun, 22 Dec 1996 06:42:04 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA01128 for ; Sun, 22 Dec 1996 06:42:04 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQbvew11047; Sun, 22 Dec 1996 09:41:59 -0500 (EST) Message-Id: To: Masataka Ohta Cc: mo@UU.NET (Mike O'Dell), jhalpern@us.newbridge.com, ipng@sunroof.eng.sun.com, dhaskin@BayNetworks.COM, bgp@ans.net Subject: (IPng 2644) Re: why do we need ASes?? In-Reply-To: Your message of "Sun, 22 Dec 1996 17:53:19 +0200." <199612220853.RAA03074@necom830.hpcl.titech.ac.jp> Date: Sun, 22 Dec 1996 09:41:59 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, there are discontiguous ASes, there are also confederations which don't necessarily track the address-assignment topology. and it would be useful to have an identifier of an administrative system which is invariant under topology. i'm not arguing that you absolutely cannot make it work without the AS as a distinguised thing, but so much of the existing infrastructure relies up on it it won't be deployable without it, and since it won't be a flash-cut, having the external routing policy machinery use the same set of structures means the conversion is arguably doable. (this gets to the bgp++ vs idrp discussion and i'd prefer to not stand on that ice right now as it heats up) so keeping the external policy machinery relatively independent would seem to be at least prudent, if not theoretically necessary. cheers, -mo ------------------------------------------------------------------------------ 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 Dec 22 23:31:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26705; Sun, 22 Dec 96 23:31:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26699; Sun, 22 Dec 96 23:31:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA17524; Sun, 22 Dec 1996 23:23:36 -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 XAA22564 for ; Sun, 22 Dec 1996 23:23:31 -0800 From: Masataka Ohta Message-Id: <199612230721.QAA04161@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA04161; Mon, 23 Dec 1996 16:21:33 +0900 Subject: (IPng 2645) Re: why do we need ASes?? To: mo@UU.NET (Mike O'Dell) Date: Mon, 23 Dec 96 16:21:31 JST Cc: mohta@necom830.hpcl.titech.ac.jp, mo@UU.NET, jhalpern@us.newbridge.com, ipng@sunroof.eng.sun.com, dhaskin@BayNetworks.COM, bgp@ans.net In-Reply-To: ; from "Mike O'Dell" at Dec 22, 96 9:41 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yes, there are discontiguous ASes, there are also confederations > which don't necessarily track the address-assignment topology. OK. > and it would be useful to have an identifier of an administrative > system which is invariant under topology. The problem of such an identifier is that it is totally insecure, not even weakly secure, unless the identifier is derived from routable part of the address. > i'm not arguing that you absolutely cannot make it work without the AS > as a distinguised thing, but so much of the existing infrastructure > relies up on it it won't be deployable without it, What I'm afrading is that with IPv6 hierarchical addressing such as that of RFC 1887, we need hierarchical ASes perhaps as long as 16 bytes. Or, do you think we don't need local, MAN or country level policy control? > and since it > won't be a flash-cut, having the external routing policy machinery > use the same set of structures means the conversion is arguably doable. If we are having hierarchical ASes, it is a lot better to unify the role of ASes and IP addresses, which is what is done with hierarchical addressing. > so keeping the external policy machinery relatively independent would > seem to be at least prudent, if not theoretically necessary. You seems to be arguing that "Don't renumber ASes, because it means a lot of work.". Exactly like that, people say "Don't renumebr IP addresses". But, renumbering of ASes only affect small number of configuration files. Note that, whatever renumbering scheme of IP addresses you might invent, small number of configuration files, such as glue A's for DNS, must be affected.. As a result, AS numbers are just as stable as IP address prefixes. Masataka Ohta ------------------------------------------------------------------------------ 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 Dec 23 07:13:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27019; Mon, 23 Dec 96 07:13:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27013; Mon, 23 Dec 96 07:13:30 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA14726; Mon, 23 Dec 1996 07:05:32 -0800 Received: from hugin.mainz.dk (Hugin.mainz.dk [130.227.10.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA16159 for ; Mon, 23 Dec 1996 07:05:30 -0800 Date: Mon, 23 Dec 1996 16:05:59 +0100 From: Kim Wohlert Subject: (IPng 2646) 8+8 and TCP connections To: "'ipng@sunroof.Eng.Sun.COM'" Message-Id: Mime-Version: 1.0 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One of the concerns brought up re: Mike O'Dell's 8+8 proposal was how TCP connections would survive changes in the RG. The problem can be divided into two distinct cases 1) rehoming of the site or of an up-stream ISP or 2) cut-over of a multihomed site. For case 1) it can be assumed that this would be a planned event that the site is able to prepare for. The survival of long-lived TCP connections could be ensured by creating an option to be inserted by the router were the RG is about to change, indicating what the new RG will be. The receiving node would then store this information in a cache connected to the information about the socket in question and when the cut-over did occur (indicated by packets with the new RG in the source address arriving), replace the old RG with the new RG in the return address. The option would only be needed during the transition period, so it would only be a rare burden. For the second case, where one link out of a multihomed site fails, this is of cause usually an unplanned event, so the information about possible RGs must be distributed continuously. This can be done with the same type of option as for case 1), but will require all boundary routers for the site to know about each other, and insert the option to indicate the list of possible RGs that could at any time replace the current RG. In this case, the option must be sent with all packets, since teh change in RG may take placea t any time. The above mechanism can probably be implemented as a generalization of the methods described by Jim Bound and Pedro Roque in "Dynamic Reassignment of IP Addresses for TCP and UDP" (). The issue of how the router gets this information in the first place can be solved along the lines presented by (I think) Geert Jan de Groot and Bob Hinden in San Jose. It should be noted that the mechanisms described here pose no additional risk of the connection being hijacked, because the router that inserts the option is also the router that inserts the RG in the first place. - Kim Kim Wohlert |Internet:Kim.Wohlert@mainz.dk erik mainz a/s | Dortheavej 7 | DK-2400 Copenhagen |Phone: +45 38 34 77 88 Denmark |Fax: +45 31 19 16 25 --- "Cast it in stone and it will float like a rock." ------------------------------------------------------------------------------ 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 Dec 23 17:33:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27969; Mon, 23 Dec 96 17:33:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27963; Mon, 23 Dec 96 17:32:51 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA19175; Mon, 23 Dec 1996 17:24:52 -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 RAA10497 for ; Mon, 23 Dec 1996 17:24:50 -0800 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.202.12]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with ESMTP id KAA06686 for ; Tue, 24 Dec 1996 10:24:47 +0900 Received: from mine.aist-nara.ac.jp by mine.aist-nara.ac.jp (8.7.3/2.7W-AIST/1.3) id KAA02522; Mon, 23 Dec 1996 10:19:59 GMT To: ipng@sunroof.eng.sun.com Subject: (IPng 2647) hlim and IF on API Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mew version 1.54 on Emacs 19.28.2, Mule 2.3 Date: Mon, 23 Dec 1996 19:19:59 +0900 Message-Id: <2519.851336399@mine.aist-nara.ac.jp> From: Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have several questions and suggestions concerned with hop-limit and IF selection. (1) Hop Limit IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS are defined on the basic API draft. Are there any strong reasons to separate them? NDP and RIPng requires to set hop-limit 255. But I believe that it is very good idea to set hop-limit 255 for all on-link communication. Are there any problem if the basic IPv6 spec requires it? (2) IF The basic API draft defines IPV6_MULTICAST_IF whereas the advanced API makes it possible to select an IF with sendmsg(). If they conflicts(e.g. select IF_1 with setsockopt() then sendmsg() to IF_2), how should it work? Moreover, if the SO_DONTROUTE option is specified, what will happen? sendmsg() successes only when the destination is link-local-used address or multicast. That is, sendmsg() fails if the destination is off-link since a gateway can't be resolved. This explanation should be contained in the advanced API spec. (1) Hop Limit Delete IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS. Then define IPV6_HOPS which can be used for both unicast and multicast. Require 255 hop-limit if the destination starts with 0xfe80 and 0xff02. (2) IF Delete IPV6_MULTICAST_IF and SO_DONTROUTE. For interface selection, use sendmsg(). If the destination is not link-local-use address nor multicast, sendmsg() returns an error. Comments? --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 Dec 24 08:52:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28548; Tue, 24 Dec 96 08:52:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28542; Tue, 24 Dec 96 08:51:53 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA12816; Tue, 24 Dec 1996 08:43:52 -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 IAA09746 for ; Tue, 24 Dec 1996 08:43:52 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA06533; Tue, 24 Dec 1996 11:30:44 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA00902; Tue, 24 Dec 1996 11:30:42 -0500 Message-Id: <9612241630.AA00902@wasted.zk3.dec.com> To: "Mike O'Dell" Cc: dhaskin@baynetworks.com (Dimitry Haskin), ipng@sunroof.eng.sun.com, bgp@ans.net Subject: (IPng 2648) Re: larger AS/RD space for v6? In-Reply-To: Your message of "Fri, 20 Dec 96 12:47:04 EST." <199612201747.MAA20792@elmo.uu.net> Date: Tue, 24 Dec 96 11:30:42 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, I don't know if more is needed. But preparing to implement your 8+8 proposal I can't see more than 14bits needed for the LSID. Then the rest of bits is a real lot for subscribers. Then in the low order 8bytes we only have 15 for the partition. SHould someone use up that partition I see no reason why the subscriber could not provide some of the subscriber bits to the private topology if needed? This affects how I would implement the transport and dns stuff fyi... /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 Dec 24 09:56:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28571; Tue, 24 Dec 96 09:56:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28565; Tue, 24 Dec 96 09:55:50 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA20054; Tue, 24 Dec 1996 09:47:49 -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 JAA23129 for ; Tue, 24 Dec 1996 09:47:49 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id MAA29288; Tue, 24 Dec 1996 12:37:11 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA13235; Tue, 24 Dec 1996 12:37:09 -0500 Message-Id: <9612241737.AA13235@wasted.zk3.dec.com> To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2649) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" In-Reply-To: Your message of "Fri, 20 Dec 96 17:33:17 -0400." <9612202233.AA10840@ludwigia.raleigh.ibm.com> Date: Tue, 24 Dec 96 12:37:09 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >First, Neither the basic or advanced API spec seems to provide a way >to obtain the Hop Limit on a *received* datagram. I think this is >something we should provide, since some routing protocols may want to >verify that updates they are receiving are from directly attached >neighbors. They could use the same Hop Limit == 255 trick as ND. I >don't really care which document it goes in, though it would seem to >fit with advanced API and ancillary data. I think this is a reasonable request. >Having said that, however, however, it seems OSPFv6 just multicasts to >the link-local address with a Hop Limit of 1, and RIPng doesn't >bother. So maybe this point is moot now. :-( Hmmm may still need it for source routes though from the application. >Now, staring with the first sentence in the introduction: :-) > >> While IPv4 addresses are 32 bits long, IPv6 nodes are identified by ^^^^^ >Shouldn't that say "interfaces"? I think it should. >> 128-bit addresses. The socket interface make the size of an IP > ^^^^ >"makes" thanks... >> u_char s6_addr[16]; /* IPv6 address */ > >Don't some folks get bent out shape when they see "u_char" in a spec? >Why isn't this a u_int8_t? (This comment applies throughout.) Yes. >> The ordering of elements in this structure is specifically designed ^^^^ >s/this/the sockaddr_in6/ >> #define SIN6_LEN > >> struct sockaddr_in6 { >> u_char sin6_len; /* length of this struct */ >> u_char sin6_family; /* AF_INET6 */ >The only place in the draft where sin6_len is mentioned is in this >section. If we want to promote application portability, then we might >want to add "#ifdef SIN6_LEN" code snippets throughout the document >(where appropriate) so that folks on non-4.4 systems do the right >thing with the sin6_len field as they develope code on 4.3-derived >systems. Would that clutter up the document too much? There are only a >few places in the current examples where that is needed I think. Not a big deal... >> 0:0:0:0:0:FFFF. IPv4-mapped addresses are written as follows: >> >> ::FFFF: >> >> These addresses are often generated automatically by the >> gethostbyname() function when the specified host has only IPv4 >> addresses (as described in Section 6.1). >Is this paragraph needed? It seems a bit misleading (is gethostbyname >really the routine that does this, or is this buried elsewhere in the >DNS code?) and doesn't strike me as being particularly relevant to >programmers anyway. Yes it should be done in gethostbyname as DNS does not carry them. It is relevant to programmers supporting a hybrid IPv6 stack which most are today. >> and priority from the packets they receive. The header fields of an >> actively opened TCP connection are set by assigning in the >> sin6_flowinfo field of the destination address sockaddr_in6 structure >> passed in the connect() function. The same technique can be used >I have some concerns with the above. I don't think we really >understand (yet) all the pieces for making Flow Labels work. That is, >it is clear that the kernel will have some say in what Flow Labels get >used (for uniqueness if nothing else). So I don't think we are in a >position to say right now that the user can specify the Flow Label >simply by putting in random values in the field. The OS kernel may >want to restrict who uses what Flow Id. For instance, it might not >want some random user to piggy back its packets on the Flow used by a >video server. The spec does not say this is a must its says it can.... We have much input the user wants this option today.... Its also will be set via RSVP by an application too. But what your saying is handled that it can be set by the kernel too. >> recvfrom(), recvmsg(), and accept() functions. An application may >> specify the flow label and priority to use in transmitted packets of >> a passively accepted TCP connection, by setting the sin6_flowinfo >> field of the address passed to the bind() function. > >I think its premature to say this as well. I don't agree. Applications can use this end-to-end too. >> IPV6_FLOWINFO_FLOWLABEL >> IPV6_FLOWINFO_PRIORITY >>How about defining macros for manipulating these fields? The advanced >>API document is full of such macros. For example, how about changing: >> recv_flow = ntohl(sin6.sin6_flowinfo & IPV6_FLOWINFO_FLOWLABEL); >> recv_prio = ntohl(sin6.sin6_flowinfo & IPV6_FLOWINFO_PRIORITY) >> 24; >to > > recv_flow = ntohl(EXTRACT_FLOW_LABEL(&sin6)); > recv_prio = ntohl(EXTRACT_PRIORITY(&sin6)); I will consult with my co-authors.... >I think this would reduce programming errors me thinks. Not a good reason and I don't think it would..if they can't get what we have right they should not be programmers. >> address of UDP packets and TCP connections, applications often want >> the system select the source address for them. With IPv4, one ^^ >missing "to" thanks >> Be aware that the IPv4 INADDR_xxx constants are all defined in host >> byte order but the IPv6 IN6ADDR_xxx constants and the IPv6 >> in6addr_xxx externals are defined in network byte order. >What other INADDR_xxx addresses are there besides loopback (the only >other one mentioned in the document)? Does it make sense to define >some of the pre-defined link-local multicast groups for instance? Why they are defined in other specs and used? I think this will add clutter to the spec if we start down this path. >> struct sockaddr_in6 sin6; >> . . . >> sin6.sin6_family = AF_INET6; >> sin6.sin6_flowinfo = 0; >> sin6.sin6_port = htons(23); >> sin6.sin6_addr = in6addr_loopback; /* structure assignment */ >> . . . >How about adding "#ifdef SIN6_LEN" code to the example. Well at this point in the snippet the person is doing IPv6 and they are committed... I guess this is OK but nitpicking. >> IPV6_ADD_MEMBERSHIP >> >> Join a multicast group on a specified local interface. If >> the interface index is specified as 0, the kernel chooses the >> local interface by looking up the multicast group in the >> normal IPv6 routing table and using the resulting interface. >The wording of the last sentence seems awfully implementation >dependent (and thus possibly incorrect). Shouldn't the API simply say >the kernel picks an interface in this case? Note this API is called the "BSD ....." and what is stated for BSD above is correct and accurate and has more meaning than ...let the kernel pick one. >> - The second way to set this option is to set the environment >> variable RES_OPTIONS, as in RES_OPTIONS=inet6. This method >> affects any processes that see this environment variable. >Hmm. Which shell are you assuming above? :-) How about adding a "for >example, in my_fave_shell, ..." Geezz more nitpicking... I think what you ask is obvious to any implementor. >Also, I wasn't entirely clear what precedence applied when various >combinations of the "three ways to set RES_USE_INET6" were in >use. It's not too hard to make a guess at what a reasonable ordering >should be, but I think the document should spell this out. We listed three ways on Page 21... Do you just want it abstracted differently? >> When the RES_USE_INET6 option is set, two changes occur: >> >> - gethostbyname(host) first calls gethostbyname2(host, AF_INET6) >> looking for AAAA records, and if this fails it then calls >> gethostbyname2(host, AF_INET) looking for A records. >I'm a bit confused. Is the above saying that gethostname returns A >records only if no AAAA records exist? It depends on the AF_FAMILY argument. I think we specifiy that clearly you get what you ask for. The resolver library handles this. >I think this may be broken. If a host has both v4 and v6 addresses, it >seems to me that gethostbyname() should return both types of >addresses. This is important if some of the addresses aren't >working. When opening TCP connections, for instance, an application is >supposed to try all the addresses until if finds one that work. The >above doesn't permit that. If none of the AAAA records work, the A >records aren't tried (i.e., they weren't returned). No its not. You get records back based on the AF_FAMILY you ask for. One case is if the application on a node is v6 aware besides the address and in that case we will not use v4 addresses to connect to it. There is nothing that prevents an application to consciously build a list of addresses fro both v4-mapped and v6 in the spec. Not that I think this is a good idea. >>> >>> - gethostbyname2(host, AF_INET) always returns IPv4-mapped IPv6 >>> addresses with the h_length member of the hostent structure set >>> to 16. >Does it continue to also supply regular (non IPv4-mapped) AAAA >addresses as well? (I suspect that it does, but it might help to add >a sentence to that effect.) This API is for system level programmers if they can't figure it out then they are just app programmers. I think adding more words will not help. >> struct hostent *gethostbyaddr(const char *src, int len, int af); >> >> One possible source of confusion is the handling of IPv4-mapped IPv6 >> addresses and IPv4-compatible IPv6 addresses. Current thinking >> involves the following logic: >Not what is meant by "current thinking". Is this an open issue we need >to nail down? Not really. This is an "informational RFC". ALso XNET has already started work on adding this to where the real API standards will be specified. Digital and Sun have stated they will work to champion this in XNET and HP and IBM have declined that opportuntity. I suggest you talk to Stephen Wise or others on the AIX team for IPv6 as I think they have implemented the DNS part. Current thinking to me is what we have done at the UNH bake-offs. This info spec is just to give us a target and not going to be a full standard at the IETF. >Also, I found the "current thinking" rules confusing. Is this a >proposal for what gethostbyaddr() should do? If so: Yes. ANd what it does now in over 9 implementations today. >> - If af is AF_INET6, and if len equals 16, and if the IPv6 address >> is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6 >> address, then skip over the first 12 bytes of the IPv6 address, >> set af to AF_INET, and set len to 4. >And then what, query the DNS for a PTR record? I think it might help >to write this out as pseudo-code, or at least enumerated so that its >clear what steps are executed in what circumstances. This code is pretty common to anyone who has implemented it. IN fact in this part of the spec I just let it go and would not implement it this way and just pass the AF_INET6 family down and not change it. I think we need to state this is just one of many cases. This is not going to be standard.... Co-authors we need to fix the spec this is just one way to do it...It assumes that what is passed to the kernel socket layer is v4 and we cannot make that assumption. We just need another case where the v6 af family stays in tact.... thanks thomas... >> The return value from the function is 0 upon success or a nonzero >> error code. The following names are the nonzero error codes from >> getaddrinfo(): >And how do programmers know what (integer) codes map to which (string) >errors? strerror()? See the POSIX spec. >> int getaddrinfo(const char *hostname, const char *servname, >> const struct addrinfo *hints, >> struct addrinfo **res); >What happens if the user supplies hostname and servname, but in the >hints section doesn't specific ai_socktype. Is this legal? What does >the call return? I'm worried about the case where there are both UDP >and TCP ports allocated to the same service name. Will the system pick >one at random? If so, this won't promote portability (i.e., it works >in my machine, I can't imagine why it doesn't on yours). Maybe we >should say that a TCP connection is assumed if both UDP and TCP are >valid and the caller didn't specify. Either that, or return an error. This is a POISX issue.... See your IBM rep for POSIX. >> structures. To return this information to the system the function >> freeaddrinfo() is called: > >In light of the discussion about using free() to return storage >obtained indirectly via another call (to the library), I'm surprised >that we have a freeaddrinfo() but no freenameindex(). This doesn't >seem consistent. Should we then go the whole nine yards and provide >"free" routines for all the routines that return dynamically allocated >storage? We added this to appease the POSIX folks ....when IPv6 goes to XNET I assume this will get discussed. >> int getnameinfo(const struct sockaddr *sa, size_t salen, >> char *host, size_t hostlen, >> char *serv, size_t servlen); >Shouldn't the "char *host" and "char *serv" be "const" as well? No. Those are being returned and cannot be declared as const. >> Note that this function does not know the protocol of the socket >> address structure. Normally this is not a problem because the same >> port is assigned to a given service for both TCP and UDP. But there >> exist historical artifacts that violate this rule (e.g., ports 512, >As others have noted, this is not true. The TCP and UDP port numbering >spaces are independent. I don't have an axe to grind here but.. check your /etc/services file on AIX... artifacts....... biff 512/udp exec 512/tcp >> The function does not >> modify the buffer pointed to by dst if the conversion fails. The >The above appears in at least two places. Is there any reason for this >requirement? It seems like an implementation detail to me. Why would >an application care? Why is that specified in the API? its just a note that we did not step on the dst. why is it bad? >> const char *inet_ntop(int af, const void *src, >> char *dst, size_t size); >> will store the resulting text string. The size argument specifies >> the size of this buffer. The application must specify a non-NULL dst >> argument. For IPv6 addresses, the buffer must be at least 46-octets. >> For IPv4 addresses, the buffer must be at least 16-octets. In order >I don't understand why the size argument is included. Why isn't dst >required to be "big enough" for the af. That's what the program should >do anyway. There are other functions (e.g., if_indextoname(unsigned >int ifindex, char *ifname)) that don't include a size argument. I >don't have strong feelings as to which way is the right way to do >things, but I don't much care for the inconsistency. Is there some >rational I'm missing here? You can use the size to determine the string length instead of AF type where you want to write a common routine. >> For IPv4 addresses, the buffer must be at least 16-octets. In order >> to allow applications to easily declare buffers of the proper size to >> store IPv4 and IPv6 addresses in string form, implementations should >> provide the following constants, made available to applications that >> include : >> >> #define INET_ADDRSTRLEN 16 >> #define INET6_ADDRSTRLEN 46 >Any chance we can generalize that into a macro that takes "af" as an >arg, and returns the number of bytes the af needs? Or has it been >decided that the inet_* routines can't be made to work for types other >than INET and INET6, so trying making the general is pointless? Too many macros for me (i prefer inline code) but will talk to my coauthors. 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 Dec 24 11:16:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28676; Tue, 24 Dec 96 11:16:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28442; Tue, 24 Dec 96 07:49:26 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA07153; Tue, 24 Dec 1996 07:41:26 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA26491 for ; Tue, 24 Dec 1996 07:41:26 -0800 Received: from ietf.ietf.org by ietf.org id aa07381; 24 Dec 96 9:47 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: (IPng 2650) I-D ACTION:draft-ietf-ipngwg-ipv6-tunnel-07.txt Date: Tue, 24 Dec 1996 09:47:33 -0500 Message-Id: <9612240947.aa07381@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-07.txt Pages : 36 Date : 12/23/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-07.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-07.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-07.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: <19961223151217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-tunnel-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961223151217.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 Dec 30 10:39:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00795; Mon, 30 Dec 96 10:39:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00789; Mon, 30 Dec 96 10:38:43 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA20066; Mon, 30 Dec 1996 10:30:32 -0800 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [129.34.139.18]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA27101 for ; Mon, 30 Dec 1996 10:30:32 -0800 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id NAA08558; Mon, 30 Dec 1996 13:30:45 -0500 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by mailhub1.watson.ibm.com (8.8.2/11-26-96) with SMTP id NAA43489; Mon, 30 Dec 1996 13:30:09 -0500 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA133356; Mon, 30 Dec 1996 13:30:08 -0500 From: Charlie Perkins Message-Id: <9612301830.AA133356@hawpub1.watson.ibm.com> To: iesg@ietf.org Cc: ipng@sunroof.eng.sun.com, dbj@cs.cmu.edu Subject: (IPng 2651) Re: Last Call: Generic Packet Tunneling in IPv6 Specification ... In-Reply-To: Your message of Mon, 30 Dec 96 09:32:57 EST. <9612300932.aa17501@ietf.org> Date: Mon, 30 Dec 96 13:30:07 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I looked over the tunnel specification document to determine whether the language for anycast tunnel endpoints will suit the needs for the mobile-IP proposal. What mobile-IP needs is a way to send a packet to all the home agents (a multicast address) on the home network. The ipng working group agreed to allow a multicast packet to be tunneled to the "Subnet router" anycast address, which is formed by appending zeroes to the routing prefix. The tunnel specification does not specifically allow or disallow this behavior. There is some cautionary wording about fragmentation which points out the problem that arises if a packet destined for an anycast address gets fragmented along the way. This should not present any problem for mobile-IP. However, there is one important behavior which I believe has to be specified. When a tunneled packet arrives at a tunnel endpoint which is the "Subnet router" anycast address, the decapsulated packet needs to be transmitted over the correct interface(s). Specifically, the decapsulated packet needs to go out over each interface which correspond to the routing prefix forming the "Subnet router" anycast address. And, when the (decapsulated) hop-limit is 1, the decapsulated packet must ONLY go out on interfaces which correspond to that routing prefix. More generally, going out a different interface of the same "Subnet router" would count as an additional hop (and the hop-limit decremented and handled accordingly). Moreover, in the case when decapsulation yields a multicast packet, the packet must go out over ALL such appropriate interfaces which correspond to the routing prefix, for which there are members of the multicast group. I think it is arguable that the abovementioned behavior is implicit in the supposed handling for the "Subnet router" anycast address. However, perhaps it is better to be sure that implementors do the right thing, by spelling it out in detail somewhere within the tunneling specification. As an unrelated and terribly minor matter, I suggest that in the second sentences in both sections 7.1 and 7.2 it is clarified that procedures (a) and (b) of both sections are meant to apply only to packets which are too big for the tunnel. That could be achieved by adding the single word "such", as follows: The fragmentation of such tunnel packets containing IPv{6,4} original packets is performed as follows: I only bring this up because I found it confusing to understand the referenced text without reading some of the surrounding context, and many people like myself often want to focus on particular parts of specification texts without having to read more than is necessary. Regards, Charlie P. ------------------------------------------------------------------------------ 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 Dec 30 11:04:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00826; Mon, 30 Dec 96 11:04:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00820; Mon, 30 Dec 96 11:03:28 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA22196; Mon, 30 Dec 1996 10:55: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 KAA05930 for ; Mon, 30 Dec 1996 10:55:18 -0800 Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA53870; Mon, 30 Dec 1996 13:52:45 -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 NAA14408; Mon, 30 Dec 1996 13:52:35 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15256; Mon, 30 Dec 1996 13:55:34 -0500 Message-Id: <9612301855.AA15256@ludwigia.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Cc: rja@cisco.com, dkatz@cisco.com Subject: (IPng 2652) draft-ietf-ipngwg-ipv6-router-alert-00.txt Date: Mon, 30 Dec 1996 13:55:34 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've got a question about the assignment of values for router alerts. The text says: > Value: A 2 octet code with the following values: > 0 - Packet contains ICMPv6 Group Membership message. > 1 - Packet contains RSVP message. > 2-255 - Reserved to IANA for future use. What about about the remaining values > 255? Also, it occurs to me that it another numbering system might be useful. For example, for ICMPv6 Group Memberships, how about using a two-byte value of (X,Y), where X is the Next Header value for ICMPv6, and Y is one of either 130 (Group Membership Query), 131 (Group Membership Report), or 132 (Group Membership Reduction). The RSVP case could be handled by (X,Y), where X = Next Header for RSVP, Y = whatever is a subcode for a specific RSVP message type. The down side of this would be that where the current proposal has a single value for ICMPv6, the alternate has 3 different values (or actually 256, since the second byte contains codes that are used only if the first byte is ICMPv6). A single packet would still only carry one of these values, since it only contains one such ICMP type. Routers would also have a choice: recognize all three explicitely, or just look at the first byte -- if Next Header == ICMPv6 -- to decide whether it needs to look at the packet more closely. The main advantage of this alternate numbering scheme would be that there is no need for a separate numbering space for the option values. (The IANA might like this!) Would there be any value in having a numbering scheme like this? > necessary. The value field may be used by an implementation to speed > processing of the packet within the transit router. Unrecognized > value fields shall be silently ignored. I'm not entirely comfortable with the wording that suggests that the value field "may be used by an implementation to speed processing within the transit router". This suggests (in contrast to the authors' intent I suspect) that an implementation can somehow play games with this value in order to speed *its* implementation, as opposed to speeding up *all* implementations that adhere to a standard. The intent is to use this option *only* for standard things (as opposed to proprietary things), right? > the IPv6 Hop-by-Hop Header. The presence of this new option in an > IPv6 packet informs the router to slow-path process this router and ^^^^^^ > handle any control data accordingly. The absence of this option in Don't you mean "packet"? 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 Mon Dec 30 12:29:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00927; Mon, 30 Dec 96 12:29:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00921; Mon, 30 Dec 96 12:29:11 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA29557; Mon, 30 Dec 1996 12:21:01 -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 MAA20736 for ; Mon, 30 Dec 1996 12:20:59 -0800 Received: from rtpdce02.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA58906; Mon, 30 Dec 1996 15:18:11 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce02.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id PAA33550; Mon, 30 Dec 1996 15:18:08 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA16466; Mon, 30 Dec 1996 15:20:50 -0500 Message-Id: <9612302020.AA16466@ludwigia.raleigh.ibm.com> To: Charlie Perkins Cc: iesg@ietf.org, ipng@sunroof.eng.sun.com, dbj@cs.cmu.edu Subject: (IPng 2653) Re: Last Call: Generic Packet Tunneling in IPv6 Specification ... In-Reply-To: Your message of "Mon, 30 Dec 1996 13:30:07 EST." <9612301830.AA133356@hawpub1.watson.ibm.com> Date: Mon, 30 Dec 1996 15:20:50 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, Reading through your message, a whole lot of questions came up in my mind. Let me must throw some things out for further thought. >I looked over the tunnel specification document to determine >whether the language for anycast tunnel endpoints will suit the >needs for the mobile-IP proposal. What mobile-IP needs is a way >to send a packet to all the home agents (a multicast address) on >the home network. The ipng working group agreed to allow a >multicast packet to be tunneled to the "Subnet router" anycast >address, which is formed by appending zeroes to the routing prefix. I think it would be helpful to describe (in a fair amount of detail) just what kind of mechanism mobile IP needs, and how it expects that mechanism to be used. My impression (which may be incorrect) was that mobile IP needed a mechanism whereby a mobile node could send a packet to the "subnet routers" anycast address and have the receiving router resend the packet for mobile IP's purposes (e.g., to the all home agents link-local multicast address). That is, mobile IP has a specific problem and a specific solution in mind, one that is only of use to mobile IP. This is much less general than allowing an arbitrary node (perhaps a mobile node, perhaps not) to tunnel an arbitrary multicast packet to a router's anycast address and have the router decapsulate the packet and send it out on a link. My understanding has been that the latter provides a general (and possibly dangerous) mechanism, and it is not clear that there is WG consensus to allow this allowed (right?). If that is the WG intent, I think the tunneling draft should be a lot more explicit about what is and is not allowed. Having said that, the tunneling draft does say: This document refers in particular to tunnels between two nodes identified by unicast addresses - such tunnels look like "virtual point to point links". The mechanisms described herein apply also to tunnels in which the exit-point nodes are identified by other types of addresses, such as anycast or multicast. These tunnels may look like "virtual point to multipoint links". At the time of writing this document, IPv6 anycast addresses are a subject of ongoing specification and experimental work. I'm surprised to see the above wording regarding multicast. It implies that multicast packets may be tunnelled, and/or that the end point of a tunnel may be a multicast address. Is this in fact something IPv6 supports? I'm not sure I quite understand the scenario where this would be used. >However, there is one important behavior which I believe has to >be specified. When a tunneled packet arrives at a tunnel endpoint >which is the "Subnet router" anycast address, the decapsulated packet >needs to be transmitted over the correct interface(s). Specifically, >the decapsulated packet needs to go out over each interface which >correspond to the routing prefix forming the "Subnet router" >anycast address. I agree, but don't quite follow your comments regarding interfaces (plural). A packet addressed to an anycast address will be delivered to exactly one interface, the interface with that address assigned to it. If the same anycast address is assigned to multiple interfaces (unlikely in the case of the "subnet router" anycast address), the packet would be delivered to one of the interfaces, but which one shouldn't matter to the sender. >And, when the (decapsulated) hop-limit is 1, the >decapsulated packet must ONLY go out on interfaces which correspond >to that routing prefix. The packet should only go out the interface on which it was recieved. It should not go out multiple interfaces. That could cause replication of packets. >More generally, going out a different >interface of the same "Subnet router" would count as an additional >hop (and the hop-limit decremented and handled accordingly). If the packet gets forwarded, its hop count should be decremented according to the normal rules. In particular, if the packet gets forwarded out the same interface it came in on, that should still count as a hop. Why wouldn't you decrement the hop count in this case? >Moreover, in the case when decapsulation yields a multicast packet, >the packet must go out over ALL such appropriate interfaces which >correspond to the routing prefix, for which there are members >of the multicast group. I think the packet should be sent out (only) on the interface (having the assigned anycast address) to which the packet was delivered. >I think it is arguable that the abovementioned behavior is implicit >in the supposed handling for the "Subnet router" anycast address. I wouldn't assume that, since its not written down anywhere. :-) 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 Mon Dec 30 15:12:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01079; Mon, 30 Dec 96 15:12:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01072; Mon, 30 Dec 96 15:12:03 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA11855; Mon, 30 Dec 1996 15:03:53 -0800 Received: from snoopy.agile.com ([198.3.105.68]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA16188; Mon, 30 Dec 1996 15:03:51 -0800 Received: by snoopy.agile.com with Microsoft Exchange (IMC 4.0.837.3) id <01BBF67B.F101ADD0@snoopy.agile.com>; Mon, 30 Dec 1996 18:04:46 -0500 Message-Id: From: "Conta, Alex" To: "'iesg@ietf.org'" , "'owner-ipng@sunroof.Eng.Sun.COM'" Cc: "'ipng@sunroof.Eng.Sun.COM'" , "'dbj@CS.CMU.EDU'" Subject: (IPng 2654) Re: Last Call: Generic Packet Tunneling in IPv6 Specification ... Date: Mon, 30 Dec 1996 18:04:45 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >---------- >From: > owner-ipng@sunroof.Eng.Sun.COM[SMTP:owner-ipng@sunroof.Eng.Sun.COM] >Sent: Monday, December 30, 1996 1:30 PM >To: iesg@ietf.org >Cc: ipng@sunroof.Eng.Sun.COM; dbj@CS.CMU.EDU >Subject: (IPng 2651) Re: Last Call: Generic Packet Tunneling in IPv6 >Specification ... > >I looked over the tunnel specification document to determine >whether the language for anycast tunnel endpoints will suit the >needs for the mobile-IP proposal. What mobile-IP needs is a way >to send a packet to all the home agents (a multicast address) on >the home network. The ipng working group agreed to allow a >multicast packet to be tunneled to the "Subnet router" anycast >address, which is formed by appending zeroes to the routing prefix. Yes Charlie. The agreement in the IPng working group was to make a minor modification >to the document (Generic Packet Tunneling in IPv6) to remove the >restriction >regarding anycast addresses. >More precisely, the agreement was to remove the excluding of anycast >addresses from the addresses that can be used to identify IPv6 tunnel >exit point >nodes, as long as the issue with the use of such addresses, i.e. >fragments of a packet must arrive at the same node to allow a successful reassembly, is well documented. >The tunnel specification does not specifically allow or disallow >this behavior. There is some cautionary wording about fragmentation >which points out the problem that arises if a packet destined for >an anycast address gets fragmented along the way. > This should not present any problem for mobile-IP. The wording complies with the agreement in the IPng Working Group. >However, there is one important behavior which I believe has to >be specified. When a tunneled packet arrives at a tunnel endpoint >which is the "Subnet router" anycast address, the decapsulated packet >needs to be transmitted over the correct interface(s). The decapsulated packet must be transmitted over the correct interface(s) in all cases, regardless of the type of the destination address of the tunnel packet. > Specifically, >the decapsulated packet needs to go out over each interface which >correspond to the routing prefix forming the "Subnet router" >anycast address. Perhaps I misunderstand what you mean here - you seem to imply that the tunnel packet destination address information ("anycast address") is used for forwarding the original packet resulting from decapsulation ("all interfaces"). This is not correct. For clarification: There is no implied relationship between the tunnel packet destination address, and where the resulting original packet is being forwarded after decapsulation. The text in the specifications says: "Upon receiving an IPv6 packet destined to an IPv6 address of a tunnel exit-point node, its IPv6 protocol layer processes the tunnel headers. The strict left-to-right processing rules for extension headers is applied. When processing is complete, control is handed to the next protocol engine, which is identified by the Next Header field value in the last header processed. If this is set to a tunnel protocol value, the tunnel protocol engine discards the tunnel headers and passes the resulting original packet to the Internet or lower layer protocol identified by that value for further processing. For example, in the case the Next Header field has the IPv6 Tunnel Protocol value, the resulting original packet is passed to the IPv6 protocol layer." The original packet resulting from decapsulation is forwarded according to the destination address specified in the original IPv6 header. If the destination address is that of the processing node, the packet is consumed by the node. If not, the packet is transmitted to the appropriate next hop router, if the hop limit decremented by one is a non-zero value (if is zero the packet is discarded). In your specific case, the original packet destination address is a multicast address, and that is the address the original packet (after decapsulation) is forwarded too. > And, when the (decapsulated) hop-limit is 1, the >decapsulated packet must ONLY go out on interfaces which correspond >to that routing prefix. It seems to me that there is an assumption made in the above statement that tunneling gives more meaning to the Hop Limit. The IPv6 tunneling does not apply any additional meaning to the Hop Limit. According to the IPv6 packet forwarding rules, original packets (decapsulated) that have the hop limit 1 before forwarding, are discarded if they must be forwarded to another node - because the Hop Limit is decremented to zero (0). >More generally, going out a different >interface of the same "Subnet router" would count as an additional >hop (and the hop-limit decremented and handled accordingly). >Moreover, in the case when decapsulation yields a multicast packet, >the packet must go out over ALL such appropriate interfaces which >correspond to the routing prefix, for which there are members >of the multicast group. Yes. >I think it is arguable that the abovementioned behavior is implicit >in the supposed handling for the "Subnet router" anycast address. >However, perhaps it is better to be sure that implementors do the >right thing, by spelling it out in detail somewhere within the >tunneling specification. The IPv6 forwarding rules are clearly specified by RFC1883. Duplicating information from other RFCs in the tunneling document was, as a general rule, avoided. I thought that the reference to the forwarding rules in RFC 1883 was made obvious enough without going to extremes. >As an unrelated and terribly minor matter, I suggest that in the >second sentences in both sections 7.1 and 7.2 it is clarified that >procedures (a) and (b) of both sections are meant to apply only >to packets which are too big for the tunnel. That could be >achieved by adding the single word "such", as follows: > The fragmentation of such tunnel packets containing > IPv{6,4} original packets is performed as follows: I am sensitive to text readability improvements. Thanks for the suggestion. Thank you, Alex > ------------------------------------------------------------------------------ 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 Dec 30 16:26:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01118; Mon, 30 Dec 96 16:26:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01111; Mon, 30 Dec 96 16:26:14 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA17339; Mon, 30 Dec 1996 16:18:05 -0800 Received: from snoopy.agile.com ([198.3.105.68]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA26854; Mon, 30 Dec 1996 16:18:02 -0800 Received: by snoopy.agile.com with Microsoft Exchange (IMC 4.0.837.3) id <01BBF686.4EF0E000@snoopy.agile.com>; Mon, 30 Dec 1996 19:18:59 -0500 Message-Id: From: "Conta, Alex" To: "'Charlie Perkins'" , "'owner-ipng@sunroof.Eng.Sun.COM'" Cc: "'iesg@ietf.org'" , "'ipng@sunroof.Eng.Sun.COM'" , "'dbj@cs.cmu.edu'" Subject: (IPng 2655) Re: Last Call: Generic Packet Tunneling in IPv6 Specification ... Date: Mon, 30 Dec 1996 19:18:58 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >---------- >From: > owner-ipng@sunroof.Eng.Sun.COM[SMTP:owner-ipng@sunroof.Eng.Sun.COM] >Sent: Monday, December 30, 1996 2:20 PM >To: Charlie Perkins >Cc: iesg@ietf.org; ipng@sunroof.Eng.Sun.COM; dbj@cs.cmu.edu >Subject: (IPng 2653) Re: Last Call: Generic Packet Tunneling in IPv6 >Specification ... > >Charlie, > >Reading through your message, a whole lot of questions came up in my >mind. Let me must throw some things out for further thought. > >>I looked over the tunnel specification document to determine >>whether the language for anycast tunnel endpoints will suit the >>needs for the mobile-IP proposal. What mobile-IP needs is a way >>to send a packet to all the home agents (a multicast address) on >>the home network. The ipng working group agreed to allow a >>multicast packet to be tunneled to the "Subnet router" anycast >>address, which is formed by appending zeroes to the routing prefix. > >I think it would be helpful to describe (in a fair amount of detail) >just what kind of mechanism mobile IP needs, and how it expects that >mechanism to be used. My impression (which may be incorrect) was that >mobile IP needed a mechanism whereby a mobile node could send a packet >to the "subnet routers" anycast address and have the receiving router >resend the packet for mobile IP's purposes (e.g., to the all home >agents link-local multicast address). That is, mobile IP has a >specific problem and a specific solution in mind, one that is only of >use to mobile IP. This is indeed a solution specific to Mobile IPv6. The agreement in the IPng working group was to do the minimum necessary to remove restrictions that would be an impediment to implementing such a Mobile IP mechanism. The document was changed according to the agreement. As far as documenting the Mobile IPv6 mechanism, I do not see that as being the scope of the tunneling document. ... >Having said that, the tunneling draft does say: > > This document refers in particular to tunnels between two >nodes > identified by unicast addresses - such tunnels look like >"virtual > point to point links". The mechanisms described herein apply also >to > tunnels in which the exit-point nodes are identified by other >types > of addresses, such as anycast or multicast. These tunnels may >look > like "virtual point to multipoint links". At the time of writing >this > document, IPv6 anycast addresses are a subject of >ongoing > specification and experimental work. > >I'm surprised to see the above wording regarding multicast. It implies >that multicast packets may be tunnelled, Yes. >and/or that the end point of >a tunnel may be a multicast address. Is this in fact something IPv6 >supports? I'm not sure I quite understand the scenario where this >would be used. The tunneling document text underlines that the rules applied to encapsulating, decapsulating, and controlling the number of encapsulations applies generically to (all) IPv6 tunnels, regardless of the type of address that identifies the tunnel exit-point node. The opinion that scenarios for using tunnels that have exit-point nodes identified by multicast addresses are difficult to imagine is shared ... It is conceivable though, that if such tunnels find a use, they may need additional rules, which are an "unknown" at this time. The document is just limiting itself to saying that, and what is understood, that such tunnels may look like "virtual point to multipoint links". >>However, there is one important behavior which I believe has to >>be specified. When a tunneled packet arrives at a tunnel endpoint >>which is the "Subnet router" anycast address, the decapsulated packet >>needs to be transmitted over the correct interface(s). Specifically, >>the decapsulated packet needs to go out over each interface which >>correspond to the routing prefix forming the "Subnet router" >>anycast address. > >I agree, but don't quite follow your comments regarding interfaces >(plural). A packet addressed to an anycast address will be delivered >to exactly one interface, the interface with that address assigned to >it. If the same anycast address is assigned to multiple interfaces >(unlikely in the case of the "subnet router" anycast address), the >packet would be delivered to one of the interfaces, but which one >shouldn't matter to the sender. > >>And, when the (decapsulated) hop-limit is 1, the >>decapsulated packet must ONLY go out on interfaces which correspond >>to that routing prefix. > >The packet should only go out the interface on which it was >recieved. It should not go out multiple interfaces. That could cause >replication of packets. I think the original packet resulting from decapsulation may go out on any of the interfaces of the tunnel exit point node, and may go out on multiple interfaces. The interface is chosen based on the information carried by the original packet headers - main, and routing extension header. The main header, and routing header in the original packet are both processed according to RFC 1883. If the destination address is a multicast address, and multicast routing is enabled, than the original packet is forwarded on those interfaces on which there are downstream group members - careful here to not send the packet back on the link it came on. >>More generally, going out a different >>interface of the same "Subnet router" would count as an additional >>hop (and the hop-limit decremented and handled accordingly). > >If the packet gets forwarded, its hop count should be decremented >according to the normal rules. In particular, if the packet gets >forwarded out the same interface it came in on, that should still >count as a hop. Why wouldn't you decrement the hop count in this case? > >>Moreover, in the case when decapsulation yields a multicast packet, >>the packet must go out over ALL such appropriate interfaces which >>correspond to the routing prefix, for which there are members >>of the multicast group. > >I think the packet should be sent out (only) on the interface (having >the assigned anycast address) to which the packet was delivered. Were would this rule be taken from ?... The general rule is that the tunnel header destination address and the original header destination address are completely independent, and therefore where to forward the original packet resulting from decapsulation does not depend on the tunnel header destination address. The general rule is that the original packet is forwarded after decapsulation according to the routing information carried by the original headers, which may imply forwarding on multiple interfaces in case of multicasting. >>I think it is arguable that the abovementioned behavior is implicit >>in the supposed handling for the "Subnet router" anycast address. > >I wouldn't assume that, since its not written down anywhere. :-) > >Thomas Alex > ------------------------------------------------------------------------------ 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 Dec 30 17:50:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01160; Mon, 30 Dec 96 17:50:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01153; Mon, 30 Dec 96 17:49:44 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA22721; Mon, 30 Dec 1996 17:41:35 -0800 Received: from snoopy.agile.com ([198.3.105.68]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA06534; Mon, 30 Dec 1996 17:41:33 -0800 Received: by snoopy.agile.com with Microsoft Exchange (IMC 4.0.837.3) id <01BBF691.F9AEE4A0@snoopy.agile.com>; Mon, 30 Dec 1996 20:42:30 -0500 Message-Id: From: "Conta, Alex" To: "'iesg@ietf.org'" , "'\"'owner-ipng@sunroof.Eng.Sun.COM'\"@sunroof.Eng.Sun.COM'" <"'owner-ipng@sunroof.Eng.Sun.COM'"@sunroof.eng.sun.com>, "'owner-ipng@sunroof.Eng.Sun.COM'" Cc: "'ipng@sunroof.Eng.Sun.COM'" , "'dbj@CS.CMU.EDU'" Subject: (IPng 2656) Re: Last Call: Generic Packet Tunneling in IPv6 Specification ... Date: Mon, 30 Dec 1996 20:42:28 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a reformatted reply - IPng 2654 - to the IPng 2651 message. Sorry for the inconvenience. I am learning what works differently in Microsoft Exchange Email. Happy New Year, Alex >>---------- >>From: >> owner-ipng@sunroof.Eng.Sun.COM[SMTP:owner-ipng@sunroof.Eng.Sun.COM] >>Sent: Monday, December 30, 1996 1:30 PM >>To: iesg@ietf.org >>Cc: ipng@sunroof.Eng.Sun.COM; dbj@CS.CMU.EDU >>Subject: (IPng 2651) Re: Last Call: Generic Packet Tunneling in IPv6 >>Specification ... >> >>I looked over the tunnel specification document to determine >>whether the language for anycast tunnel endpoints will suit the >>needs for the mobile-IP proposal. What mobile-IP needs is a way >>to send a packet to all the home agents (a multicast address) on >>the home network. The ipng working group agreed to allow a >>multicast packet to be tunneled to the "Subnet router" anycast >>address, which is formed by appending zeroes to the routing prefix. > >Yes Charlie. > >The agreement in the IPng working group was to make a minor >modification >to the document (Generic Packet Tunneling in IPv6) to remove the >restriction >regarding anycast addresses. > >More precisely, the agreement was to remove the excluding of anycast >addresses from the addresses that can be used to identify IPv6 tunnel >exit point nodes, as long as the issue with the use of such addresses, >i.e. >fragments of a packet must arrive at the same node to allow a >successful >reassembly, is well documented. > >>The tunnel specification does not specifically allow or disallow >>this behavior. There is some cautionary wording about fragmentation >>which points out the problem that arises if a packet destined for >>an anycast address gets fragmented along the way. >> This should not present any problem for mobile-IP. > >The wording complies with the agreement in the IPng Working Group. >>However, there is one important behavior which I believe has to >>be specified. When a tunneled packet arrives at a tunnel endpoint >>which is the "Subnet router" anycast address, the decapsulated packet >>needs to be transmitted over the correct interface(s). > >The decapsulated packet must be transmitted over the correct >interface(s) in all cases, regardless of the type of the destination >address of the >tunnel packet. > >> Specifically, >>the decapsulated packet needs to go out over each interface which >>correspond to the routing prefix forming the "Subnet router" >>anycast address. > >Perhaps I misunderstand what you mean here - you seem to imply that the >tunnel packet destination address information ("anycast address") is >used for forwarding the original packet resulting from decapsulation >("all >interfaces"). This is not correct. > >For clarification: > >There is no implied relationship between the tunnel packet destination >address, and where the resulting original packet is being forwarded >after >decapsulation. > >The text in the specifications says: > > "Upon receiving an IPv6 packet destined to an IPv6 address of a > tunnel exit-point node, its IPv6 protocol layer processes >the tunnel > headers. The strict left-to-right processing rules for >extension > headers is applied. When processing is complete, control is handed >to > the next protocol engine, which is identified by the Next >Header > field value in the last header processed. If this is set to a >tunnel > protocol value, the tunnel protocol engine discards the >tunnel > headers and passes the resulting original packet to the Internet >or > lower layer protocol identified by that value for further >processing. > For example, in the case the Next Header field has the IPv6 >Tunnel > Protocol value, the resulting original packet is passed to the >IPv6 > protocol layer." > >The original packet resulting from decapsulation is forwarded according >to the destination address specified in the original IPv6 header. If >the >destination address is that of the processing node, the packet is >consumed >by the node. If not, the packet is transmitted to the appropriate next >hop router, >if the hop limit decremented by one is a non-zero value (if is zero the >packet is >discarded). > >In your specific case, the original packet destination address is a >multicast address, and that is the address the original packet >(after decapsulation) is forwarded to. > >> And, when the (decapsulated) hop-limit is 1, the >>decapsulated packet must ONLY go out on interfaces which correspond >>to that routing prefix. > >It seems to me that there is an assumption made in the above statement >that tunneling gives more meaning to the Hop Limit. The IPv6 >tunneling does >not apply any additional meaning to the Hop Limit. According to the >IPv6 >packet forwarding rules, original packets (decapsulated) that have the >hop >limit 1 before forwarding, are discarded if they must be forwarded to >another node - >because the Hop Limit is decremented to zero (0). > >>More generally, going out a different >>interface of the same "Subnet router" would count as an additional >>hop (and the hop-limit decremented and handled accordingly). >>Moreover, in the case when decapsulation yields a multicast packet, >>the packet must go out over ALL such appropriate interfaces which >>correspond to the routing prefix, for which there are members >>of the multicast group. > >Yes. > >>I think it is arguable that the abovementioned behavior is implicit >>in the supposed handling for the "Subnet router" anycast address. >>However, perhaps it is better to be sure that implementors do the >>right thing, by spelling it out in detail somewhere within the >>tunneling specification. > >The IPv6 forwarding rules are clearly specified by RFC1883. Duplicating > >information from other RFCs in the tunneling document was, as a general > >rule, avoided. I thought that the reference to the forwarding rules in >RFC 1883 was made obvious enough without going to extremes. > >>As an unrelated and terribly minor matter, I suggest that in the >>second sentences in both sections 7.1 and 7.2 it is clarified that >>procedures (a) and (b) of both sections are meant to apply only >>to packets which are too big for the tunnel. That could be >>achieved by adding the single word "such", as follows: > >> The fragmentation of such tunnel packets containing >> IPv{6,4} original packets is performed as follows: > >I am sensitive to text readability improvements. Thanks for the >suggestion. > >Thank you, >Alex >> >------------------------------------------------------------------------ >------ >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 Mon Dec 30 18:00:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01172; Mon, 30 Dec 96 18:00:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01166; Mon, 30 Dec 96 18:00:22 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA23208; Mon, 30 Dec 1996 17:52:13 -0800 Received: from snoopy.agile.com ([198.3.105.68]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA07565 for ; Mon, 30 Dec 1996 17:52:11 -0800 Received: by snoopy.agile.com with Microsoft Exchange (IMC 4.0.837.3) id <01BBF693.77520530@snoopy.agile.com>; Mon, 30 Dec 1996 20:53:10 -0500 Message-Id: From: "Conta, Alex" To: "'iesg@ietf.org'" , "'ipng@sunroof.Eng.Sun.COM'" , "'dbj@CS.CMU.EDU'" Cc: "Conta, Alex" Subject: (IPng 2657) FW: Returned mail: User unknown Date: Mon, 30 Dec 1996 20:53:09 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >This is a reformatted reply - IPng 2654 - to the IPng 2651 message. > >Sorry for the inconvenience. I am learning what works differently in >Microsoft Exchange Email. > >Happy New Year, >Alex >>---------- >>From: >> owner-ipng@sunroof.Eng.Sun.COM[SMTP:owner-ipng@sunroof.Eng.Sun.COM] >>Sent: Monday, December 30, 1996 1:30 PM >>To: iesg@ietf.org >>Cc: ipng@sunroof.Eng.Sun.COM; dbj@CS.CMU.EDU >>Subject: (IPng 2651) Re: Last Call: Generic Packet Tunneling in IPv6 >>Specification ... >> >>I looked over the tunnel specification document to determine >>whether the language for anycast tunnel endpoints will suit the >>needs for the mobile-IP proposal. What mobile-IP needs is a way >>to send a packet to all the home agents (a multicast address) on >>the home network. The ipng working group agreed to allow a >>multicast packet to be tunneled to the "Subnet router" anycast >>address, which is formed by appending zeroes to the routing prefix. >> >Yes Charlie. > >The agreement in the IPng working group was to make a minor >modification >to the document (Generic Packet Tunneling in IPv6) to remove the >restriction >regarding anycast addresses. > >More precisely, the agreement was to remove the excluding of anycast >addresses from the addresses that can be used to identify IPv6 tunnel >exit point nodes, as long as the issue with the use of such addresses, >i.e. >fragments of a packet must arrive at the same node to allow a >successful >reassembly, is well documented. > >>The tunnel specification does not specifically allow or disallow >>this behavior. There is some cautionary wording about fragmentation >>which points out the problem that arises if a packet destined for >>an anycast address gets fragmented along the way. >> This should not present any problem for mobile-IP. > >The wording complies with the agreement in the IPng Working Group. >>However, there is one important behavior which I believe has to >>be specified. When a tunneled packet arrives at a tunnel endpoint >>which is the "Subnet router" anycast address, the decapsulated packet >>needs to be transmitted over the correct interface(s). >The decapsulated packet must be transmitted over the correct >iterface(s) in all cases, regardless of the type of the destination >address of the tunnel packet. > >> Specifically, >>the decapsulated packet needs to go out over each interface which >>correspond to the routing prefix forming the "Subnet router" >>anycast address. >> >Perhaps I misunderstand what you mean here - you seem to imply that the >tunnel packet destination address information ("anycast address") is >used for forwarding the original packet resulting from decapsulation >("all interfaces"). This does not seem correct. >For clarification: > >There is no implied relationship between the tunnel packet destination >address, and where the resulting original packet is being forwarded >after >decapsulation. >The text in the specifications says: > > "Upon receiving an IPv6 packet destined to an IPv6 address of a > tunnel exit-point node, its IPv6 protocol layer processes > the tunnel headers. The strict left-to-right processing rules >for > extension headers is applied. When processing is complete, control > is handed to the next protocol engine, which is identified by >the Next > Header field value in the last header processed. If this is set to >a > tunnel protocol value, the tunnel protocol engine discards the > tunnel headers and passes the resulting original packet to the >Internet or > lower layer protocol identified by that value for further >processing. > For example, in the case the Next Header field has the IPv6 >Tunnel > Protocol value, the resulting original packet is passed to the IPv6 > protocol layer." > >The original packet resulting from decapsulation is forwarded according >to the destination address specified in the original IPv6 header. If >the destination address is that of the processing node, the packet is >consumed by the node. If not, the packet is transmitted to the >appropriate next >hop router, if the hop limit decremented by one is a non-zero value (if >is zero the >packet is discarded). > >In your specific case, the original packet destination address is a >multicast address, and that is the address the original packet >(after decapsulation) is forwarded to. > >> And, when the (decapsulated) hop-limit is 1, the >>decapsulated packet must ONLY go out on interfaces which correspond >>to that routing prefix. > >It seems to me that there is an assumption made in the above statement >that tunneling gives more meaning to the Hop Limit. The IPv6 >tunneling does not apply any additional meaning to the Hop Limit. >According to the >IPv6 packet forwarding rules, original packets (decapsulated) that have >the >hop limit 1 before forwarding, are discarded if they must be forwarded >to >another node - because the Hop Limit is decremented to zero (0). > >>More generally, going out a different >>interface of the same "Subnet router" would count as an additional >>hop (and the hop-limit decremented and handled accordingly). >>Moreover, in the case when decapsulation yields a multicast packet, >>the packet must go out over ALL such appropriate interfaces which >>correspond to the routing prefix, for which there are members >>of the multicast group. > >Yes. > >>I think it is arguable that the abovementioned behavior is implicit >>in the supposed handling for the "Subnet router" anycast address. >>However, perhaps it is better to be sure that implementors do the >>right thing, by spelling it out in detail somewhere within the >>tunneling specification. >> >The IPv6 forwarding rules are clearly specified by RFC1883. Duplicating >information from other RFCs in the tunneling document was, as a general >rule, avoided. I thought that the reference to the forwarding rules in >RFC 1883 was made obvious enough without going to extremes. > >>As an unrelated and terribly minor matter, I suggest that in the >>second sentences in both sections 7.1 and 7.2 it is clarified that >>procedures (a) and (b) of both sections are meant to apply only >>to packets which are too big for the tunnel. That could be >>achieved by adding the single word "such", as follows: > >> The fragmentation of such tunnel packets containing >> IPv{6,4} original packets is performed as follows: >> >I am sensitive to text readability improvements. Thanks for the >suggestion. > >Thank you, >Alex >------ > > ------------------------------------------------------------------------------ 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 Dec 30 19:17:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01213; Mon, 30 Dec 96 19:17:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01207; Mon, 30 Dec 96 19:17:31 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA26891; Mon, 30 Dec 1996 19:09:21 -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 TAA15570 for ; Mon, 30 Dec 1996 19:09:14 -0800 Received: from rtpdce02.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA30292; Mon, 30 Dec 1996 22:06:29 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce02.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id WAA35752; Mon, 30 Dec 1996 22:06:26 -0500 Received: from [32.224.57.74] by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA17886; Mon, 30 Dec 1996 22:09:18 -0500 Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id VAA00570; Mon, 30 Dec 1996 21:38:39 -0500 Message-Id: <199612310238.VAA00570@hygro.raleigh.ibm.com> To: "Conta, Alex" Cc: "'Charlie Perkins'" , "'iesg@ietf.org'" , "'ipng@sunroof.Eng.Sun.COM'" , "'dbj@cs.cmu.edu'" Subject: (IPng 2658) Re: Last Call: Generic Packet Tunneling in IPv6 Specification ... In-Reply-To: Your message of "Mon, 30 Dec 1996 19:18:58 EST." Date: Mon, 30 Dec 1996 21:38:39 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, > This is indeed a solution specific to Mobile IPv6. The agreement in > the IPng working group was to do the minimum necessary to remove > restrictions that would be an impediment to implementing such a > Mobile IP mechanism. >The document was changed according to the agreement. > As far as documenting the Mobile IPv6 mechanism, I do not see that > as being the scope of the tunneling document. I didn't mean to suggest that the tunneling draft do this. Rather, I was attempting to prod Charlie into describing more precisely what mobile IP was doing, since his message seemed to imply that he expected the tunneling draft to support a more general tunneling mechanism than I think there is support for. I think that point needs clarification. >>and/or that the end point of >>a tunnel may be a multicast address. Is this in fact something IPv6 >>supports? I'm not sure I quite understand the scenario where this >>would be used. > The tunneling document text underlines that the rules applied to > encapsulating, decapsulating, and controlling the number of > encapsulations applies generically to (all) IPv6 tunnels, regardless > of the type of address that identifies the tunnel exit-point node. The reason I am surprised to see multicast and tunneling given an OK is that the IPv6 base spec disallows the use of multicast addresses with a routing header, presumably because it interferes with a base assumption multicast routers make when forwarding multicast packets, i.e., the source address of the packet implies something about the path the packet followed before reaching that router. Tunneled packets can break that assumption just as the routing header does. So my question is, why the inconsistency? > The opinion that scenarios for using tunnels that have exit-point > nodes identified by multicast addresses are difficult to imagine is > shared ... It is conceivable though, that if such tunnels find a > use, they may need additional rules, which are an "unknown" at this > time. The document is just limiting itself to saying that, and what > is understood, that such tunnels may look like "virtual point to > multipoint links". Wouldn't it be better then to simply say that the document deals only with unicast tunnels and that multicast is beyond the document's scope. By mentioning it (even briefly) some folks may be led to believe that this is a feature that routers generally support. >>The packet should only go out the interface on which it was >>recieved. It should not go out multiple interfaces. That could cause >>replication of packets. > I think the original packet resulting from decapsulation may go out > on any of the interfaces of the tunnel exit point node, and may go > out on multiple interfaces. Yes, you are right, in the case where the inner header has a multicast destination. I spoke too generally. In Charlie's note, he was also saying interfaces (plural) in the context of unicast packets, based on some sort of prefix match. I think my argument still applies in that context. >>I think the packet should be sent out (only) on the interface (having >>the assigned anycast address) to which the packet was delivered. > The general rule is that the tunnel header destination address and > the original header destination address are completely independent, > and therefore where to forward the original packet resulting from > decapsulation does not depend on the tunnel header destination > address. I think that in the context of mobile IP, the idea would be to have the anycast router (re)send the tunneled packet to the link-local all-home agents multicast address. Since a router has many interfaces, care must be taken to insure that the packet gets resent out on the proper link, i.e., the link where the mobile node attaches to when it is at home. That would be an interface with the "subnet router" anycast address assigned to it. 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 Mon Dec 30 23:19:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01292; Mon, 30 Dec 96 23:19:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01286; Mon, 30 Dec 96 23:18:55 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA09300; Mon, 30 Dec 1996 23:10:45 -0800 Received: from wizard.gsfc.nasa.gov (wizard.gsfc.nasa.gov [128.183.115.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id XAA07019 for ; Mon, 30 Dec 1996 23:10:44 -0800 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA13556; Tue, 31 Dec 96 02:10:24 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9612310710.AA13556@wizard.gsfc.nasa.gov> Subject: (IPng 2659) Re: 8+8 (further discussion) To: rjp@pdd.3com.com (Rob Pickering) Date: Tue, 31 Dec 1996 02:10:24 -0500 (EST) Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <8094.199612121837@ganymede.PDD.3Com.com> from "Rob Pickering" at Dec 12, 96 09:41:58 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Mike's current draft is no good for protection against the piracy, > > because it can't lookup DNS with ID part only. > > Mike's draft doesn't talk at all about reverse lookup (PTR) records > which would in any case be necessary. If you > arrange to provide PTR records for all RG:ESD pairs that a host has > e.g. > > host.dom.ain AAAA : > host.dom.ain AAAA : This is similar to something I proposed to the IPng list in March of 1995. I've included my original message at the bottom of this message, but I'll adapt it here for the 8+8 discussion (and variants). A multi-homed site might have something like the following DNS setup: My_Site IN RG xxx-LSID-Provider1_ID-Site_ID_for_Provider1 My_Site IN RG xxx-LSID-Provider2_ID-Site_ID_for_Provider2 which would represent two different providers for My_Site (this particular example assumes that both providers are in the same LSID). Non-Internet-connected routing domains could use the Site Local Use prefix. Then a host at My_Site might have the following AAAA records: host IN AAAA My_Site PTP1_ID-EID host IN AAAA My_Site PTP2_ID-EID host IN AAAA My_Site PTP3_ID-EID which assumes that the host has 3 interfaces and one IPv6 address per interface for this particular example. Each address would be 64 bits long (128 - length of My_Site prefix which is 64 bits). These site-specific addresses would be invariant with a change of provider. Then, when someone queried the DNS for the host's AAAA entries, instead of simply returning a set of 128-bit AAAA entries for the host, it would return the set of 3 64-bit site-specific addresses for the host, i.e. the PTP_ID + EID. In an additional section, it would return the list of RG entries for My_Site, in this case the 2 64-bit Site RG prefixes representing Provider1 and Provider2. Upon receiving the DNS reply, the requesting host would simply combine the AAAA and RG parts to form the various full 128-bit IPv6 addresses for the host (which would have 6 possible addresses in this example), or use the information in other meaningful ways, such as provider selection. It also might be desirable to have a preference value on the RG record to order the preference of Site Providers, similar to the preference value on MX records. This would not only significantly reduce the possible size of a DNS reply (3*8 + 2*8 = 40 octets versus 2*3*16 = 96 octets for this simple case), but should also be a great help in facilitating change of provider or exchange, and in supporting multi-homed routing domains. I didn't initially push that hard for inclusion of such an idea in the IPv6 DNS spec, but the more I think about it, the more I believe such a facility is really needed even in the early deployment stages of IPv6, to decouple the site portion of an IPv6 address from the routing goop portion of an IPv6 address. > and > > ..IP6.INT. PTR host.dom.ain. > ..IP6.INT. PTR host.dom.ain. I didn't originally consider PTR records, but my inclination is that it's probably not a good idea to include the RG (or PTP info) in the inverse mapping, so this should probably be: Reversed_EID.IP6.INT. PTR host.My.Domain. If we really want to include the RG, then it should at least be via indirection using some new syntax, perhaps something like: Reversed_EID.Reversed_PTP1_ID.@My_Site.IP6.INT. PTR host.My.Domain. Reversed_EID.Reversed_PTP2_ID.@My_Site.IP6.INT. PTR host.My.Domain. Reversed_EID.Reversed_PTP3_ID.@My_Site.IP6.INT. PTR host.My.Domain. Since My_Site has 2 Providers and thus 2 RG entries, the above would actually generate the equivalent of 6 PTR records, one for each of the 6 possible IPv6 addresses for host.My.Domain. > and a packet exchange is going on with : as the remote address. The > route via dies and a host unreachable is received. The stack > then does a DNS query for ..IP6.INT and gets host.dom.ain, > which then forward resolves to the two AAAA records. : is > ruled out because we know it is dead, so we substitute : > and continue the conversation. I assume you meant the new RG unreachable ICMPv6 error rather than just a host unreachable. It would also be nice to be able to revert back to the "preferred" RG when it came back up, but I'm not sure how you would implement this. Perhaps you could do like Path MTU Discovery and periodically send out some type of ICMPv6 probe message to see if the "preferred" RG had come back up. > This has some security as it will only use full addresses which are > in the list of AAAA records for the host. > > -- > Rob Pickering Finally, I'm still weighing in my own mind the pros and cons of the Mike O'Dell 8+8 proposal, which I think of as 8+2+6 (Public_RG+Private_RG+EID), versus the Masataka Ohta 8+8 proposal, which I think of as 6+2+8 (Public_RG+Private_RG+EID). I do like the ability with Masataka's proposal to do PTR lookups based solely on the EID. It seems intuitive to me that such PTR lookups shouldn't have anything to do with any of the routing goop (either public or private). Since Mike didn't address PTR lookups in his 8+8 proposal, I can't really fairly assess what he might have in mind for performing PTR lookups. However, the concepts and ideas in his overall proposal I generally found favorable (including the idea of dynamically inserting the source routing goop at the Site Boundary Router), although the details still need to be hashed out further. I can make the same general statement about Masataka's 8+8 proposal, noting that the two proposals have much in common. In Mike's proposal, I'm not sure I like the idea of any hard boundaries in the Public RG part, and don't see the necessity for it, although it could be used initially as guidance for the initial allocation of LSIDs, to initially limit the number of routes in the global Default Free Zone to at most 2^13 (or 2^14), plus the intra-LSID routes of course. As routers become more capable over time, I suspect that there may be advantages to having finer routing granularity at the top level. One of the disadvantages Masataka listed with Mike's 8+8 proposal had to do with mobility. One possible simple kludge to deal with this would be to reserve either PTP (subnet) 0 or PTP 0x7FFF for mobile hosts. This would make all mobile hosts have a constant ESD regardless of where they happened to roam. This would limit the number of mobile host to 2^48 or over 281 trillion hosts, but I think it will be quite a while before we bump into that limit. Having said that, as indicated earlier, my current leaning is toward an 8 byte EID as espoused by Masataka, although perhaps not the exact breakdown as in Masataka's proposal (once again I don't like the idea of completely hard boundaries plus 3 bytes for country NICs seems excessive). As others have noted, there are a number of similarities between Mike's and Masataka's proposals, and I feel it should be possible to synthesize a merged proposal from the two. As the tradeoffs are discussed further, hopefully consensus can be reached. I think one of the determining factors is whether or not the EID is all that is needed to do a PTR lookup. I'm currently leaning that way personally, but am still open to other alternatives, depending on the costs involved. -Bill Original message to IPng list regarding IPv6 DNS issue: -------------------------------------------------------------------------------- From: bill@wizard.gsfc.nasa.gov (Bill Fink) Subject: Re: (IPng) New IPv6 DNS Draft To: ipng@sunroof.Eng.Sun.COM Date: Tue, 28 Mar 1995 00:00:59 -0500 (EST) Was any thought given to decoupling the site portion of an IPv6 address from the exchange or provider portion of an IPv6 address? I am envisioning something like the following DNS setup: My_Site IN PREFIX 010-Registry_ID-Provider1_ID-Site_ID_for_Provider1 64 My_Site IN PREFIX 010-Registry_ID-Provider2_ID-Site_ID_for_Provider2 64 which would represent two different providers for My_Site, where the length of the Site Prefix for My_Site is 64 bits. Non-Internet-connected routing domains could use the Site Local Use prefix. Then a host foo at My_Site might have the following AAAA records: foo IN AAAA My_Site:Subnet1_ID-Interface1_ID foo IN AAAA My_Site:Subnet2_ID-Interface2_ID foo IN AAAA My_Site:Subnet3_ID-Interface3_ID which assumes that foo has 3 interfaces and one IPv6 address per interface for this example. Each address would be 64 bits long (128 - length of My_Site prefix which is 64 bits). These site-specific addresses would be invariant with a change of provider. Then, when someone queried the DNS for host foo's AAAA entries, instead of simply returning a set of 128-bit AAAA entries for host foo, it would return the set of 3 64-bit site-specific addresses for host foo, i.e. the Subnet_ID + Interface_ID (right justified in the smallest number of octets that will hold the address, in this case 8 octets). In an additional section, it would return the list of Site Prefixes for My_Site, in this case the 2 64-bit Site Prefixes representing Provider1 and Provider2 (left justified in the smallest number of octets that will hold the address, in this case 8 octets). Upon receiving the DNS reply, the requesting host would simply combine the AAAA and PREFIX parts to form the various full 128-bit IPv6 addresses for host foo (which would have 6 possible addresses in this example), or use the information in other meaningful ways, such as provider selection. This would not only significantly reduce the possible size of a DNS reply (3*8 + 2*8 = 40 octets versus 2*3*16 = 96 octets for this simple case), but should also be a great help in facilitating change of provider or exchange, and in supporting multi-homed routing domains. -Bill ------------------------------------------------------------------------------ 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 Dec 31 06:31:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01378; Tue, 31 Dec 96 06:31:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01372; Tue, 31 Dec 96 06:31:15 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA24270; Tue, 31 Dec 1996 06:23:05 -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 GAA13614 for ; Tue, 31 Dec 1996 06:23:00 -0800 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA37182; Tue, 31 Dec 1996 09:20:27 -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 JAA84116; Tue, 31 Dec 1996 09:21:15 -0500 Received: from [32.224.57.23] by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA11724; Tue, 31 Dec 1996 09:23:19 -0500 Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id JAA01102; Tue, 31 Dec 1996 09:18:38 -0500 Message-Id: <199612311418.JAA01102@hygro.raleigh.ibm.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2660) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" In-Reply-To: Your message of "Tue, 24 Dec 1996 12:37:09 EST." <9612241737.AA13235@wasted.zk3.dec.com> Date: Tue, 31 Dec 1996 09:18:37 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> IPV6_ADD_MEMBERSHIP >>> >>> Join a multicast group on a specified local interface. If >>> the interface index is specified as 0, the kernel chooses the >>> local interface by looking up the multicast group in the >>> normal IPv6 routing table and using the resulting interface. >>The wording of the last sentence seems awfully implementation >>dependent (and thus possibly incorrect). Shouldn't the API simply say >>the kernel picks an interface in this case? >Note this API is called the "BSD ....." and what is stated for BSD above >is correct and accurate and has more meaning than ...let the kernel pick >one. I don't think this is a BSD/non-BSD issue. The current wording suggests that one picks the outbound interface based on what's in the routing tables. What if the destination is a link-local multicast address, and the node has mulitiple interfaces? The above implies that the kernel will need to have a route entry for that group. I could imagine an alternate implementation that just keeps a pointer to a "default" interface through which all multicast packets are forwarded, without having an explicit multicast route in its tables. I don't think we are having a disagreement on what should happen. I just think the wording is a little to specific about one way of implementing the functionality. My suggestion on wording would be: Join a multicast group on a specified local interface. If the interface index is specified as 0, the kernel chooses an appropriate local interface. >>> - The second way to set this option is to set the environment >>> variable RES_OPTIONS, as in RES_OPTIONS=inet6. This method >>> affects any processes that see this environment variable. >>Hmm. Which shell are you assuming above? :-) How about adding a "for >>example, in my_fave_shell, ..." >Geezz more nitpicking... I think what you ask is obvious to any >implementor. Sorry, IMO not every programmer is familiar with every shell... >>Also, I wasn't entirely clear what precedence applied when various >>combinations of the "three ways to set RES_USE_INET6" were in >>use. It's not too hard to make a guess at what a reasonable ordering >>should be, but I think the document should spell this out. >We listed three ways on Page 21... Do you just want it abstracted >differently? I think it should be made clear which rule has precedence when more than one of the methods is used simultaneously (and in conflicting ways). For example, does the setting in /etc/resolv.conf override a setting of the environment variable? If the user says RES_OPTIONS=, but /etc/resolv.conf sets it to USE_INIT6, what happens? >>> When the RES_USE_INET6 option is set, two changes occur: >>> >>> - gethostbyname(host) first calls gethostbyname2(host, AF_INET6) >>> looking for AAAA records, and if this fails it then calls >>> gethostbyname2(host, AF_INET) looking for A records. >>I'm a bit confused. Is the above saying that gethostname returns A >>records only if no AAAA records exist? >It depends on the AF_FAMILY argument. I think we specifiy that clearly >you get what you ask for. The resolver library handles this. To further clarify, the draft says: > The commonly used function gethostbyname() remains unchanged as does > the hostent structure to which it returns a pointer. Existing > applications that call this function continue to receive only IPv4 > addresses that are the result of a query in the DNS for A records. Then, later it says: > When the RES_USE_INET6 option is set, two changes occur: > > - gethostbyname(host) first calls gethostbyname2(host, AF_INET6) > looking for AAAA records, and if this fails it then calls > gethostbyname2(host, AF_INET) looking for A records. > > - gethostbyname2(host, AF_INET) always returns IPv4-mapped IPv6 > addresses with the h_length member of the hostent structure set > to 16. Thus, I conclude that gethostbyname() *does* return AAAA records (if RES_USE_INET6 is set). Note that the above text doesn't specifically say that AAAA records are returned, it says that gethostname2() is called. It would be more clear to also state that AAAA records are returned in this case. Note that this also conflicts (somewhat) with the first statement. If, in fact, setting RES_USE_INET6 does result in gethostbyname() returning AAAA records, this would seem to break the requirement that existing IPv4 applications continue working unchanged. The user might set the RES_OPTIONS environment variable, and then attempt to run an application that cannot handle AAAA records. Is this really the intent of the draft? >>I think this may be broken. If a host has both v4 and v6 addresses, it >>seems to me that gethostbyname() should return both types of >>addresses. This is important if some of the addresses aren't >>working. When opening TCP connections, for instance, an application is >>supposed to try all the addresses until if finds one that work. The >>above doesn't permit that. If none of the AAAA records work, the A >>records aren't tried (i.e., they weren't returned). >No its not. You get records back based on the AF_FAMILY you ask for. Not entirely true (based on my understanding of what happens). You get back records based on *both* the AF_FAMILY and whether or not AAAA records happen to exist. You only get back A records if no AAAA records are exist. >One case is if the application on a node is v6 aware besides the address >and in that case we will not use v4 addresses to connect to it. That's OK. >There is nothing that prevents an application to consciously build a >list of addresses fro both v4-mapped and v6 in the spec. Not that I >think this is a good idea. I agree. But my understanding of the above behavior of gethostbyname() is that it allows an application to make one call (without specfying the AF) and get back either A or AAAA records. However, the way the function is currently defined, there are circumstances where AAAA records are returned, but A records are not, even though A records exist. I would have expected *both* to be returned (always) and then let the application choose which ones it uses. >>And how do programmers know what (integer) codes map to which (string) >>errors? strerror()? >See the POSIX spec. Well, the same thing could have been said about the entire getaddrinfo() routine, but lot's of text is included in the draft. :-) IMO, an additional sentence would be helpful. >>As others have noted, this is not true. The TCP and UDP port numbering >>spaces are independent. >I don't have an axe to grind here but.. check your /etc/services file on >AIX... >artifacts....... >biff 512/udp >exec 512/tcp I think we're in agreement. My comment was meant to say that the text in the current draft needs changing. >>> The function does not >>> modify the buffer pointed to by dst if the conversion fails. The >>The above appears in at least two places. Is there any reason for this >>requirement? It seems like an implementation detail to me. Why would >>an application care? Why is that specified in the API? >its just a note that we did not step on the dst. why is it bad? By saying it, an application can assume the buffer will not be modified. Thus, it *requires* that the routine be implemented in such a way. This seems like a gratuitous restriction on the library implementor, with little (no?) benefit to the application. So why make it a requirement? Removing the text doesn't prevent the library from implementing it to have the above semantics. I just don't see the rational for *requiring* that it be implemented that way. >>> const char *inet_ntop(int af, const void *src, >>> char *dst, size_t size); >>> will store the resulting text string. The size argument specifies >>> the size of this buffer. The application must specify a non-NULL dst >>> argument. For IPv6 addresses, the buffer must be at least 46-octets. >>> For IPv4 addresses, the buffer must be at least 16-octets. In order >>I don't understand why the size argument is included. Why isn't dst >>required to be "big enough" for the af. That's what the program should >>do anyway. There are other functions (e.g., if_indextoname(unsigned >>int ifindex, char *ifname)) that don't include a size argument. I >>don't have strong feelings as to which way is the right way to do >>things, but I don't much care for the inconsistency. Is there some >>rational I'm missing here? >You can use the size to determine the string length instead of AF type >where you want to write a common routine. I guess I don't quite follow that. If you are writing a "common routine", you have to understand the AF being passed in order to convert the internal representation to a printable form (and indeed, to even know how many bytes the internal representation of the address is). Or do you expect inet_ntop to try to convert AF types that it doesn't understand? If the routine understands the AF, the size argument seems redundent. 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 Tue Dec 31 07:31:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01403; Tue, 31 Dec 96 07:31:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01397; Tue, 31 Dec 96 07:31:00 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA27392; Tue, 31 Dec 1996 07:22:49 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA22164 for ; Tue, 31 Dec 1996 07:22:49 -0800 Received: from inner.net (beavis.ipv6.nrl.navy.mil [132.250.90.8]) by inner.net (8.8.2/42) with ESMTP id PAA04593 for ; Tue, 31 Dec 1996 15:22:41 GMT Message-Id: <199612311522.PAA04593@inner.net> To: ipng@sunroof.eng.sun.com Subject: (IPng 2661) Last call on BSD Basic API X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Tue, 31 Dec 1996 10:22:34 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would like to see section 6.6 of the basic API (the inet6_isipv4mapped() function) replaced with the macro set in section 2.8 of the advanced API draft. -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 Tue Dec 31 09:05:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01488; Tue, 31 Dec 96 09:05:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01482; Tue, 31 Dec 96 09:05:06 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA02889; Tue, 31 Dec 1996 08:56:55 -0800 Received: from snoopy.agile.com ([198.3.105.68]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA05796 for ; Tue, 31 Dec 1996 08:56:55 -0800 Received: by snoopy.agile.com with Microsoft Exchange (IMC 4.0.837.3) id <01BBF711.DADAAED0@snoopy.agile.com>; Tue, 31 Dec 1996 11:57:54 -0500 Message-Id: From: "Conta, Alex" To: "'narten@raleigh.ibm.com'" Cc: "'Charlie Perkins'" , "'iesg@ietf.org'" , "'ipng@sunroof.Eng.Sun.COM'" , "'dbj@cs.cmu.edu'" Subject: (IPng 2662) Re: Last Call: Generic Packet Tunneling in IPv6 Specification ... Date: Tue, 31 Dec 1996 11:57:52 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >---------- >From: narten@raleigh.ibm.com[SMTP:narten@raleigh.ibm.com] >Sent: Monday, December 30, 1996 9:38 PM >To: Conta, Alex >Cc: 'Charlie Perkins'; 'iesg@ietf.org'; 'ipng@sunroof.Eng.Sun.COM'; >'dbj@cs.cmu.edu' >Subject: Re: (IPng 2655) Re: Last Call: Generic Packet Tunneling in >IPv6 Specification ... > >Alex, > ... > >The reason I am surprised to see multicast and tunneling given an OK >is that the IPv6 base spec disallows the use of multicast addresses >with a routing header, presumably because it interferes with a base >assumption multicast routers make when forwarding multicast packets, >i.e., the source address of the packet implies something about the >path the packet followed before reaching that router. Tunneled packets >can break that assumption just as the routing header does. So my >question is, why the inconsistency? Indeed multicast addresses are discouraged with routing headers. But using a routing header never changes the source address of a packet, so I am not following the direction of the rationale you have mentioned. My interpretation of the restriction is that the routing information carried by the routing header has to be consistent in terms of significance, and how it is handled by routers. From both respects, unicast and multicast addresses are different. Additionally, the reverse path on a bi-directional path, may pose additional problems. Therefore I understand why mixing the two type of addresses in a routing header is prohibited. However, along the same train of thought, I think it may make sense to have a routing header in which all addresses are multicast on a unidirectional path - an intergalactic communication in which groups of routers are identified by multicast addresses (-:.... Back to the document we discuss, I think that the association or similitude between IPv6 routing headers and IPv6 tunnels is taken a little too far. The IPv6 tunnels use only one source and one destination address, which is dissimilar from routing headers which add/specify multiple distinct destinations. Furthermore, and of less importance, IPv6 tunnels we discuss are by default unidirectional, so the reverse path does not pose a similar problem with a routing header reversing. Therefore Thomas, I think that the approach in making the statements in the specification is correct - stress the generality of the mechanisms to all addresses, and also stress that the current experience and focus is mostly with point to point tunnels. >> The opinion that scenarios for using tunnels that have exit-point >> nodes identified by multicast addresses are difficult to imagine is >> shared ... It is conceivable though, that if such tunnels find a >> use, they may need additional rules, which are an "unknown" at this >> time. The document is just limiting itself to saying that, and what >> is understood, that such tunnels may look like "virtual point to >> multipoint links". > >Wouldn't it be better then to simply say that the document deals only >with unicast tunnels and that multicast is beyond the document's >scope. Again, the mechanisms apply to all addresses. > By mentioning it (even briefly) some folks may be led to >believe that this is a feature that routers generally support. I would say that such an interpretation of the text would be farfetched... and followed at this time by a (brief) disappointment. > .... >> The general rule is that the tunnel header destination address and >> the original header destination address are completely independent, >> and therefore where to forward the original packet resulting from >> decapsulation does not depend on the tunnel header destination >> address. > >I think that in the context of mobile IP, the idea would be to have >the anycast router (re)send the tunneled packet to the link-local >all-home agents multicast address. Since a router has many interfaces, >care must be taken to insure that the packet gets resent out on the >proper link, i.e., the link where the mobile node attaches to when it >is at home. That would be an interface with the "subnet router" >anycast address assigned to it. > >Thomas Yes. Absolutely. Alex > ------------------------------------------------------------------------------ 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 Dec 31 10:41:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01554; Tue, 31 Dec 96 10:41:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01548; Tue, 31 Dec 96 10:41:15 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA09439; Tue, 31 Dec 1996 10:33:04 -0800 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [129.34.139.18]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA20280 for ; Tue, 31 Dec 1996 10:33:04 -0800 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id NAA17954; Tue, 31 Dec 1996 13:33:34 -0500 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by mailhub1.watson.ibm.com (8.8.2/11-26-96) with SMTP id NAA67110; Tue, 31 Dec 1996 13:32:58 -0500 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA27485; Tue, 31 Dec 1996 13:32:57 -0500 From: Charlie Perkins Message-Id: <9612311832.AA27485@hawpub1.watson.ibm.com> To: iesg@ietf.org Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2663) Re: Last Call: Generic Packet Tunneling in IPv6 Specification ... In-Reply-To: Your message of Mon, 30 Dec 96 09:32:57 EST. <9612300932.aa17501@ietf.org> Date: Tue, 31 Dec 96 13:32:56 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The following clarification is necessary after my note yesterday about using an anycast tunnel destination. =============== Discontiguous subnets =============== When I wrote the note, I was under the possibly erroneous impression that discontiguous subnets were allowable in IPv6. This explains my attempt to be careful, and to request that a decapsulated packet be sent out over "all interfaces" that match a routing prefix. This will never be necessary if there are no discontiguous subnets. ========================================================= Moreover, what I tried to do was to frame the specific requirement for mobile IP in a way that was able to be generalized in the future, as the ways that tunnels might be used for encapsulating multicast packets become better understood. I think it is fair to say right now that issues remain. The specific requirement for mobile IP is as follows. We need to deliver a multicast packet to all home agents on a home network. That packet should not go to any other networks. Let's assume for now that the home network is contiguous, so that any multicast packet issued from any interface on the home network will reach all the multicast group members on the home network. Suppose we tunnel the multicast packet, using the "Subnet routers" anycast address as the tunnel destination. I think we can assume that such a tunneled multicast packet would often (usually?) be received by a router in the anycast group, but from an interface not on the home network. I wanted to make the following model: 1) When decapsulating, the inner packet "seems" as if it were received from the interface on the home network, since it was delivered to a destination address on the home network. In other words, the inner packet does NOT "seem" as if it was received from the same interface as the encapsulated packet was received from. 2) Given (1), if a multicast address is the destination of the inner packet, and the multicast packet was sent with (hop limit == 1), then the multicast packet CANNOT be "forwarded" across the router to be issued from any other interface that does not reside on the home network. I think that the above model is reasonable and conforms to a consistent analysis of what encapsulation might be supposed to provide. I also think that it's the best interpretation for controlling the hop limit. In the particular case of mobile IP, it is important that the packet addressed to "all home agents" be sent out _ONLY_ on the designated home network. If the router were connected to different networks, each with home agents serving different populations of mobile nodes, unexpected responses might occur. ================================================================== I hope my proposal for handling hop limits in such a way to tightly control distribution of mobile IP multicast packets to the home network is considered acceptable. It has the virtue of fitting nicely in a generalizable framework for handling other kinds of encapsulated packets with (hop limit == 1) sent to the "Subnet routers" anycast address. Otherwise, I am open to suggestion. As a last resort, we could be very, very particular to specify a unique behavior in the case when a packet is tunneled to the "Subnet routers" anycast address. The router would be expected to decapsulate that packet, and then perform the following algorithm: 1) If the address is "all home agents", and 2) If the protocol is UDP, and 3) If the port is 434, then 4) Then, send the packet out to the home network associated with the anycast "Subnet routers" address. I thought that it would be better to frame the processing as consistent with somewhat more general handling of encapsulated multicast packets, but I am quite willing to go along with the collective wisdom of the working group in this matter. In order to be as clear as possible about handling the hop limit, I should express my current understanding of how such a hop limit is supposed to be handled during tunneling. Say that a process on the mobile node wishes to send a multicast packet to home agents on its home network. Then 1) The packet is built, specifying hop limit == 1. 2) The multicast packet is encapsulated, causing the hop limit to be decremented to zero. 3) The encapsulated packet is transmitted, and the hop limit of the inner packet remains zero until it arrives at the tunnel endpoint. 4) The decapsulator unwraps the inner multicast packet, and sends it out from the proper interface (still with hop limit == 0). 5) No forwarding of the multicast packet can occur. In the context of the above understanding on my part, I quote from Alex's (reformatted) note, and ask for further elaboration in light of the needs I have detailed earlier in this (long) note. ======================================================================== >>> == me >> == Tom > == Alex Message-Id: From: "Conta, Alex" To: "'Charlie Perkins'" , "'owner-ipng@sunroof.Eng.Sun.COM'" Cc: "'iesg@ietf.org'" , "'ipng@sunroof.Eng.Sun.COM'" , Subject: (IPng 2655) Re: Last Call: Generic Packet Tunneling in IPv6 Specification ... Date: Mon, 30 Dec 1996 19:18:58 -0500 >>> And, when the (decapsulated) hop-limit is 1, the >>> decapsulated packet must ONLY go out on interfaces which correspond >>> to that routing prefix. > >> The packet should only go out the interface on which it was >> recieved. It should not go out multiple interfaces. That could cause >> replication of packets. > > I think the original packet resulting from decapsulation may go out on > any of the interfaces of the tunnel exit point node, and may go out on > multiple interfaces. The interface is chosen based on the information > carried by the original packet headers - main, and routing extension header. > The main header, and routing header in the original packet are both > processed according to RFC 1883. If the destination address is a multicast > address, and multicast routing is enabled, than the original packet is > forwarded on those interfaces on which there are downstream group members > - careful here to not send the packet back on the link it came on. The problem I have with this is that there are likely to be group members for the "all home agents" multicast address on each network attached to the anycast recipient, and yet only one home network should be selected for dissemination (when hop limit == 1). In fact, I'm not even sure it's relevant which interface the encapsulated packet arrived on. The combination of the anycast destination and the hop limit are the relevant factors here, and seemingly in other cases involving such tunneling operations. Regards, Charlie P. ------------------------------------------------------------------------------ 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 Dec 31 11:43:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01594; Tue, 31 Dec 96 11:43:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01588; Tue, 31 Dec 96 11:42:59 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA14126; Tue, 31 Dec 1996 11:34:49 -0800 Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA04232 for ; Tue, 31 Dec 1996 11:34:48 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id LAA14743; Tue, 31 Dec 1996 11:34:48 -0800 (PST) for Posted-Date: Tue, 31 Dec 1996 11:34:48 -0800 (PST) Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (SMI-8.6/SMI-SVR4) with ESMTP id LAA18871; Tue, 31 Dec 1996 11:34:45 -0800 for Received: from naxos.engeast (naxos [192.32.174.140]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id OAA22041; Tue, 31 Dec 1996 14:34:46 -0500 for Date: Tue, 31 Dec 1996 14:34:46 -0500 From: wling@BayNetworks.COM (Wenken Ling) Message-Id: <199612311934.OAA22041@pobox.engeast.BayNetworks.COM> To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk index ipng ------------------------------------------------------------------------------ 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 Dec 31 12:09:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01638; Tue, 31 Dec 96 12:09:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01632; Tue, 31 Dec 96 12:09:22 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA16161; Tue, 31 Dec 1996 12:01:12 -0800 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [129.34.139.18]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA08015 for ; Tue, 31 Dec 1996 12:01:11 -0800 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id PAA09466; Tue, 31 Dec 1996 15:01:24 -0500 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by mailhub1.watson.ibm.com (8.8.2/11-26-96) with SMTP id PAA50834; Tue, 31 Dec 1996 15:00:47 -0500 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA90023; Tue, 31 Dec 1996 15:00:46 -0500 From: Charlie Perkins Message-Id: <9612312000.AA90023@hawpub1.watson.ibm.com> To: ipng@sunroof.eng.sun.com, mobile-ip@SmallWorks.COM Cc: dbj@cs.cmu.edu Subject: (IPng 2664) Discussion about new direction for mobile IP Date: Tue, 31 Dec 96 15:00:45 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave Johnson and I have been puzzling lately over how mobile IPv6 can handle ingress filtering by border routers. For IPv4, there is a concerted effort going on now within the mobile-IP group to solve this problem. Results are supposed to be forthcoming before the next IETF meeting, and will likely involve reverse tunneling along with some new controls. Since recent history indicates that such filtering will be common in the future Internet, I think that we can expect similar operations for IPv6 routers. The bottom line is that expecting the mobile node to use its home address as the source IPv6 address when delivering packets to correspondent nodes is asking for trouble. If this is true, our current mobile IP has to change. Some time ago, a proposal was floated by Fumio Teraoka to do mobility by a "source rebinding" procedure. We had a number of objections to his proposal, based on the need for way too many authentications and amount of overhead in each packet. However, taken more abstractly, the ideas of rebinding the source address versus "rebinding" (say, by way of a routing header) the destination address are dual (as has been noted by Christian Huitema and others). Thus, we (Dave and I) have been drawn to reconsider the merits of source rebinding. It is, of course, essential in this regard to remember that a mobile node can use the methods of stateless or stateful autoconfiguration to obtain a topologically significant, but temporary, "care-of address" (to use our existing terminology). What we propose to change is the way that the care-of address is used. Briefly, we would like to send a new kind of Binding Update to the correspondent node, so that it translates the source address of received packets from the mobile node's care-of address into the mobile node's home address. This care-of address could, symmetrically, be used as the destination address of packets sent from the correspondent node to the mobile node. All of the connection state information (e.g., in the correspondent node's PCBs) would still be kept in terms of the mobile node's care-of address. The translation would occur as part of the operation of the IPv6-layer destination-cache lookup for the mobile node's home address. One benefit of the above, is that routing headers are no longer needed. In fact, if life were sufficiently good and correspondent nodes could be counted on to maintain all such source rebinding information in nonvolatile storage, such a scheme is practically minimal as far as packet overhead is concerned. However, if the correspondent node loses track of the source rebinding information for the mobile node, it will start to get perfectly good packets that seem to emanate from the mobile node's care-of address. If that (rare) occurrence would be acceptable, then life is good. This note can be considered over and done with. ======================================================================== If, on the other hand, the mobile node needs to protect against such losses at the correspondent node, then we have to design more protocol. There are several possibilities: 1) We can require the mobile node to indicate, in each packet sent to the correspondent node, that the source address is not the "real" source address. Then if the correspondent does not have a binding, it returns ICMP to the source address of the packet, and the mobile node (after receiving the ICMP) knows to reissue the source rebinding information. 1a) We can have a bit in the header. 1b) We design a new destination option for the forward indication by the mobile node. 2) The correspondent node can be required to use routing headers anyway. Then, the mobile node will know that if it gets a datagram without a routing header, something is wrong. This strategy fails when the mobile node cannot expect to get an answer from the correspondent node. Thus, it is really not acceptable. If (1), it would be REALLY NICE to have a bit in the header for this indication. Especially before they get solidly used up. Perhaps one of the bits earmarked for private use by ISPs in the last IETF could be allocated for this use (the "source address should actually be bound to something else" bit). Otherwise, if the mobile node has to use a destination option for this purpose, the typical case will require enough padding to make this an 8-byte overhead, by the rules for aligning options. Note that the asymmetric 8-byte overhead is still better than the asymmetric 24-byte overhead required by current mobile IPv6, because routing headers take 24 bytes (minimum). ======================================================================== There are some other issues that need to be worked out, but I think they are minor (involving, for instance, address lifetime and multihoming at the mobile node). At least I think we can solve them. The purpose of this note is to float this change in direction for consideration by the working groups, and ask for comments. It seems a shame to take on such a major change at this late date, when we are practically done with the protocol. However, the need is great, given the ingress filtering we can expect. To mitigate the impact of the change, I will observe that we will actually be able to use quite a bit of the existing protocol mechanism that already exists in the current Internet Drafts. Your comments are earnestly solicited. Thanks in advance, Charlie P. ------------------------------------------------------------------------------ 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